Re: 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.)

Comment on Re: UDP server with IO::Socket::INET

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]
Re^3: UDP server with IO::Socket::INET by rowdog (Curate) on Mar 03, 2010 at 14:12 UTC
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]
Re^4: UDP server with IO::Socket::INET by ikegami (Patriarch) on Mar 03, 2010 at 15:42 UTC
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]
Re^5: UDP server with IO::Socket::INET by rowdog (Curate) on Mar 04, 2010 at 11:24 UTC
Re^6: UDP server with IO::Socket::INET by ikegami (Patriarch) on Mar 04, 2010 at 19:37 UTC
Some notes below your chosen depth have not been shown here
Re^3: UDP server with IO::Socket::INET by Khen1950fx (Canon) on Mar 03, 2010 at 08:56 UTC
Try Net::Connection::Sniffer. It supports what you are trying to do.	[reply]
Re^3: UDP server with IO::Socket::INET by ikegami (Patriarch) on Mar 03, 2010 at 15:32 UTC
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]


Think about Loose Coupling
	PerlMonks