Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^2: UDP server with IO::Socket::INET

by jarmund (Initiate)
on Mar 03, 2010 at 05:19 UTC ( [id://826340]=note: print w/replies, xml ) Need Help??


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

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.

Replies are listed 'Best First'.
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.

      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

        If this was my project, I would definitely use an explicit disconnection.

        That said, ICMP does provide "Destination Unreachable" which could be used to detect clients that are MIA. Of course, using ICMP for this would be a lot of work for very little practical gain, which is why I recommended multicast.

Re^3: UDP server with IO::Socket::INET
by Khen1950fx (Canon) on Mar 03, 2010 at 08:56 UTC
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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://826340]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (1)
As of 2024-07-23 05:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.