Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^8: UDP connection

by BrowserUk (Pope)
on May 04, 2012 at 01:41 UTC ( #968843=note: print w/ replies, xml ) Need Help??


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

I haven't seen the OP describe traffic originating from ports 53036, 53037, 53038, 53039.

Geez Louise. Re-read the OPs post but concentrate on a single pair of ports:

  1. The server listens on 4 ports 8020 ....
  2. The client sends the first heartbeat from ports: 53036, ... to ports 8020, ..., This repeats in every 10 seconds.
  3. When server ... [it] replies from ports 8020, ... to ports 53036, ....
  4. If ... the server ... sends them to ports 53036, ....

Graphically:

step | Action | Server | direction | client -----+--------+--------+-----------+------- 1 | Listen | 8020 | | -----+--------+--------+-----------+------- 2 | h'beat | 8020 | <-------- | 53036 Client 53036 originates; S +erver 8020 receives. -----+--------+--------+-----------+------- 3 | resp | 8020 | --------> | 53036 Server 8020 originates; cl +ient 53036 receives. -----+--------+--------+-----------+------- 4 | data | 8020 | --------> | 53036 Server 8020 originates; cl +ient 53036 receives. -----+--------+--------+-----------+-------

4 ports at the server, 4 ports at the client; 4 bi-directional conversations. There is no ambiguity.


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?


Comment on Re^8: UDP connection
Download Code
Re^9: UDP connection
by JavaFan (Canon) on May 04, 2012 at 11:24 UTC
    You are correct. I must have misread the numbers.

    However, there is no problem. Here are a sample server and client that do bidirection communication over 4 socket pairs. The server waits for an initial heartbeat from the client, then starts sending data, and it will stop sending data if it hasn't seen a heartbeat for 10 seconds. There's of course lots of room for improvement, but it does show bidirectional communication is not a problem.

    First, the server:

    #!/usr/bin/perl use 5.010; use strict; use warnings; use IO::Socket; my $INTERVAL = 10; my $MAX_BUFSIZE = 512; my $NO_CONTACT = 0; my $SENDING = 1; my $LOST_CONTACT = 2; my $server = '192.168.0.1'; my @server_ports = (8020, 8019, 8008, 8003); my @sockets = map { my $socket = IO::Socket::INET::->new( LocalPort => $_, LocalAddr => $server, Proto => 'udp', ) or die $!; $socket; } @server_ports; my @states = ($NO_CONTACT) x @sockets; my @heartbeats = (0) x @sockets; my @counts = (0) x @sockets; my $Rbits = ""; my $Ebits = ""; vec($Rbits, fileno($_), 1) = 1 for @sockets; vec($Ebits, fileno($_), 1) = 1 for @sockets; while (1) { select(my $rbits = $Rbits, undef, my $ebits = $Ebits, 1); for (my $i = 0; $i < @sockets; $i ++) { my $socket = $sockets[$i]; my $fileno = fileno($socket); my $state = $states[$i]; my $heartbeat = $heartbeats[$i]; if (vec($ebits, $fileno, 1)) { say "Got an error on channel $i. I'm out of here"; exit 1; } if (vec($rbits, $fileno, 1)) { my $sender = $socket->recv(my $buffer, $MAX_BUFSIZE); if (length $buffer) { my ($port, $remote) = sockaddr_in($sender); $remote = inet_ntoa($remote); say "Got HB from $remote:$port"; $heartbeat = $heartbeats[$i] = time; if ($state == $NO_CONTACT) { # # Upgrade the socket now we know the remote # vec($Rbits, fileno($socket), 1) = 0; vec($Ebits, fileno($socket), 1) = 0; undef $sockets[$i]; undef $socket; $socket = $sockets[$i] = IO::Socket::INET::->new( LocalPort => $server_ports[$i], LocalAddr => $server, PeerAddr => $remote, PeerPort => $port, Proto => 'udp', ) or die $!; vec($Rbits, fileno($socket), 1) = 1; vec($Ebits, fileno($socket), 1) = 1; $state = $states[$i] = $SENDING; } } } # # Out of time? # if ($state == $SENDING && $heartbeat + $INTERVAL < time) { say "Channel $i is dead. Bye!"; exit 1; } # # Send data? # if ($state == $SENDING) { foreach (1 .. int rand 10) { my $count = ++$counts[$i]; say "Send packet $count on channel $i"; $socket->send($count); } } } } __END__
    And the client:
    #!/usr/bin/perl use 5.010; use strict; use warnings; use autodie; use IO::Socket; my $server = '192.168.0.1'; my $client = '192.168.0.12'; my @server_ports = ( 8020, 8019, 8008, 8003); my @client_ports = (53036, 53037, 53038, 53039); my $INTERVAL = 10; my $MAX_BUFSIZE = 512; my @sockets; for (my $i = 0; $i < @server_ports; $i ++) { $sockets[$i] = IO::Socket::INET::->new( LocalPort => $client_ports[$i], LocalAddr => $client, PeerPort => $server_ports[$i], PeerAddr => $server, Proto => 'udp', ) or die $!; } my $Rbits = ""; my $Ebits = ""; vec($Rbits, fileno($_), 1) = 1 for @sockets; vec($Ebits, fileno($_), 1) = 1 for @sockets; # # Now loop. If there's data to read, read it. If it's time to send a # heartbeat, do so. # my @heartbeats = (0) x @sockets; while (1) { for (my $i = 0; $i < @sockets; $i++) { if (time >= $heartbeats[$i] + $INTERVAL - 1) { # # Initialize contact, or keep alive # say "Send HB on channel $i"; $sockets[$i]->send("HB"); $heartbeats[$i] = time; } } select(my $rbits = $Rbits, undef, my $ebits = $Ebits, 1); for (my $i = 0; $i < @sockets; $i++) { my $socket = $sockets[$i]; my $fileno = fileno($socket); if (vec($ebits, $fileno, 1)) { say "Got an error on channel $i. I'm out of here"; exit 1; } if (vec($rbits, $fileno, 1)) { # # Read messages, if any # $socket->recv(my $buffer, $MAX_BUFSIZE); next unless length $buffer; say "Received packet $buffer on channel $i"; } } } __END__
      You are correct. I must have misread the numbers.

      It happens. Thank you for acknowledging it.

      However, there is no problem. Here are a sample server and client that do bidirection communication over 4 socket pairs.

      Hm. There are still problems you are not dealing with. I'm not talk ing about error handling or niceties here.

      1. Your server is not acknowledging (responding to) the clients heartbeats per the OPs description:
        And once it receives a "heartbeat" (a byte containing "01") it sends a response to the IP and port the hb came from (byte containing "25").

        It may sound a minor omission, but (I believe) it does complicate the design of the client (and server) somewhat.

      2. Your server is using the receipt of the heartbeat as a trigger for the start of server to client data flow.

        In the OPs description:

        • the hexdumps are only sent after the initial heartbeat.

          (Obviously, how else would the server know there was a client to send to:)

        • But they are not triggered by the heartbeat!

          He goes on to say:

          If there are test results ready on the server it sends them to ....

          Which suggests, though it doesn't actually state -- and he never came back to answer the question -- that the sending of the hexdumps is initiated by the server, when they become available; provided that is within 10 seconds of a heartbeat.

      The significance of those (perhaps apparently small) differences, is that your client treats all inbound communications as data. The OP cannot do this as he has also to distinguish between the heartbeat response and the actual data.

      The single byte packet size of the response should make that easy... except when you take the uncertain timing of the availability of the hexdump data into consideration.

      Here is the black hole in the timing scenario I was trying resolve with the OP, which your client does not -- and (I believe) as written, cannot -- resolve:

      time ascending relative ... 0.000 At this point, a client has (just) sent a HB, and the server has ac +knowledged it. The server had no data to send ... 9.99999... seconds expire The server discovers that it has hexdump to send and starts transmitt +ing ... 10.000 The client sends it next heartbeat and awaits the response.

      The hexdump doesn't have to be large, a single packet coming available (at exactly the wrong time) will trigger the problem. The client is expecting a single byte response. The server hasn't seen the heartbeat, so it isn't going to send it until (at least) after it finishes sending the current packet. If, after sending the heartbeat, the client went into a read state for the single byte response, it will get the first byte of the data packet, and the rest will be discarded. This is the exact scenario that the OP described in his first post.

      Using blocking reads -- as would normally be used in conjunction with threads as indicated by the OP -- the client cannot be in a read state in anticipation of the arrival of a data packet that could come at any time; and also send a regular heartbeat, because you cannot send() via socket, if that socket is currently in a recv() state. (At the same end!)

      Using select obviates that, by avoiding entering the read state until it knows (by polling) that data is ready to be read. But that alone does not completely close the window for failure.

      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.

      Whilst the window for such a failure is small; such are the nature of communications protocol failures.

      The usual solution(s) to this problem include:

      1. Have the client send the heartbeat at twice the frequency of the servers timeout.
      2. Have the server declare a timeout of half what it will actually accept.
      3. Have the server reset the timeout whenever it sends -- be it heartbeat ack; or data packet -- rather than when it receives.

      And it was these details I was trying to establish with the OP before he got scared away by our ...um... discussion.


      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?

        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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (5)
As of 2014-09-18 02:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (104 votes), past polls