Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^11: UDP connection

by JavaFan (Canon)
on May 04, 2012 at 22:11 UTC ( [id://968997]=note: print w/replies, xml ) Need Help??


in reply to Re^10: UDP connection
in thread UDP connection

Well, only the OP can answer all those questions.

I did ignore the single byte response on purpose; my main goal was to show bidirectional communication was possible, and there's no two processes trying to get a hold on the same socket.

As I understood the situation, everything the server sends is a hexdump, except the very first byte. Note that my client wasn't writing anything to a file; that, and leaving off the first byte I left as an exercise to the user. Not sending anything (or just only the single byte) after receiving the first heartbeat doesn't seem to complicate anything, IMO. Now, I am assuming (and I may be incorrect in that), an acknowledge is send only after the first heartbeat (in which it's safe, and easy, to just ignore the first response). I agree it becomes more complicated if the client cannot distinguish between heartbeat responses and hexdumps. But it may very well be that the nature of the hexdumps send is such that there will not be a hexdump consisting of a single byte with value 25.

If the 10 second timeout at the server occurs exactly whilst the client is in the process of receiving the latest packet -- and is therefore unable to transmit its next heartbeat -- the server will (may) conclude that the client has 'gone away' and discard (fail to send) any subsequent data until the client re-heartbeats. And that leads to data loss, which the OP explicitly denounced.
Yes, that's why my client sends a heartbeat every 9 seconds. ;-) (This is similar to solution 1) The select loop times out every second, after which at most 1 packet is read before checking the time, and a heartbeat is send if we're 9 seconds or more after sending the previous heartbeat (and this is easily tweakable). In theory, the client could be so busy that the process is swapped out for a full second. Or even more than 10 seconds, not having any opportunity at all to send a heartbeat.

Have the server reset the timeout whenever it sends -- be it heartbeat ack; or data packet -- rather than when it receives.
I'm not sure that would work. Say, the server has more data to send every second. If it would reset the timeout each second, it would never notice the client going away as the timeout keeps being pushed further back.

Replies are listed 'Best First'.
Re^12: UDP connection
by BrowserUk (Patriarch) on May 04, 2012 at 22:56 UTC
    my main goal was to show bidirectional communication was possible,

    Bidirectional communication was never in question (by me).

    My questions/concerns related to concurrent bidirectional comms (at the same endpoint), which AFAIK is impossible on any platform.

    Of course, this never arises with the select loop mechanism, as there is only one thread of execution and it is either waiting; or processing a can_read state; or processing a can_write state; or an error state.

    But with either a multi-threaded, or multi-process solution on multi-core hardware, it can be attempted -- as exampled by the idea that the client run one thread/process for doing the heartbeat and another for receiving the data -- and needs to be handled.

    It can be handled (with threading at least), but unless the OP comes back and fills in a few of the blanks, there's probably little point in further pursuing the possibilities.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?

      I'm sorry for ignoring the node for so long. I took some days off from work for an exam -.- I've read the whole discussion and I'd like to thank you for your replies.

      As above mentioned the UDP packet size is never bigger than 65535 bytes, and the read won't last 10 secs either.

      While sending out the hexdump the server will notice the heartbeat and will send a response after it sent the data. The server will always respond to the heartbeat. Also we know for sure, that there is no hexdump which contains only one byte. They have several types and the smallest is around 20 bytes.

      The server can do with some delay in receiving the heartbeat. For testing it's fine to set up the timer to send heartbeat in every 9.9 secs.

      "The sending of the hexdumps is initiated by the server, when they become available; provided that is within 10 seconds of a heartbeat." It's possible that we start the server and there is no hexdump ready. So it is possible that we have to wait for several minutes for the first hexdump to come. The client continues to send the heartbeats regardless of it receives no data.

      I hope I've answered everything that wasn't clear.

        Try this:

        #! perl -slw use strict; use threads; use IO::Socket; $|++; use constant SERVER => '127.0.0.1'; use constant MAXIN => 65536; my $noBlock = 1; my @svrs = map{ IO::Socket::INET->new( Proto => 'udp', PeerHost => SERVER, PeerPort => $_ ) or die $!; } 8003, 8008, 8019, 8020; for my $svr ( @svrs ) { async { open my $lsn, '<&', fileno( $svr ) or die "$!,/ $^E"; ioctl( $lsn, 0x8004667e, \$noBlock ); while( 1 ) { select'','','',0.1; recv( $lsn, my $in, MAXIN, 0 ); next unless length $in; next if length( $in ) == 1 and ord( $in ) == 25; print "<$in"; } }->detach; } while( sleep 5 ) { $_->send( chr( 1 ) ) for @svrs; }

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2024-03-28 21:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found