in reply to UDP server with IO::Socket::INET

something that sends the contents of $datatoship to everyone (or anyone) that is connected to $socket

UDP is connectionless. Depending on how you look at it, you're never connected with anyone, or you're always connected with every IP address.

Perhaps you mean "everyone that has previously sent some connect request", in which case you need to keep track of everyone that sent you a connect request (and didn't send you a disconnect request), and send the message to each of those individually. What a connect request might resemble is up to you. It could be as simple as sending a message with the string "connect".

Not relevant to your current dilemma, but you talked of a UDP stream. However, UDP is not a streaming protocol. Each Datagram is independent. They are not necessarily received in the same order as they are sent (unlike streaming protocols like TCP).

Finally, you might need to know that UDP is an unreliable protocol. That means you aren't notified if the delivery of the packet was successful. (Conversely, TCP is a reliable protocol. Communication might not be successful, but you'll know if it wasn't.)

Replies are listed 'Best First'.
Re^2: UDP server with IO::Socket::INET
by jarmund (Initiate) on Mar 03, 2010 at 05:19 UTC
    Well, i guess i could have every client that "connects" send a "yup, i'm here"-packet. However, would this mean that every client would have to send something to the server every time they want to receive something? Also, yes. My choice of words was inapropriate, since the data isn't really a stream. It's just so many small packets that it makes more sense to me to look at it as a stream, rather than packets, hehe. And as for reliability, it's not really important. The data to be sent is calculated very often, due to changes, so reception of all of them is far from critical, as long as a majority of them is received. Also, the data will only be sent over a LAN anyway.
[reply]

      I don't see any (easy) way to get around having to have your clients let the server know they want to receive data. I suppose you can have the clients just close the socket when they're tired of listening and the server could remove them when the send fails but you still need some way to know which clients to send to.

      Since you're on a LAN, I suppose you could send to the broadcast address and let the clients listen when they want to. If you are dealing with a sane OS you might want to check out IO::Socket::Multicast.

[reply]

        the server could remove them when the send fails

        That won't work. The send won't fail if the receiver stops receiving. You need some explicit disconnection mechanism.

        • send doesn't wait for the datagram to be sent and acknowledged, so at best you'd know if a past send failed.
        • There's no connection to keep track of a past send failures.
        • There's no acknowledgment sent by the remote end to say it didn't fail.

        The send will only fail if there's a local error (e.g. bad argument, no more resources, etc)

        Kudos for IO::Socket::Multicast, though

[reply]
[d/l]
[reply]

      However, would this mean that every client would have to send something to the server every time they want to receive something?

      No, just once. Well, maybe once in a while. The server should forget connects that it has received a long time ago to avoid sending to a machine that didn't properly disconnect, but that's no longer interested.

[reply]

In Section Seekers of Perl Wisdom