title: Why does sending consecutive UDP messages cause messages to arrive late?
body: <p>I've written a server python script in Windows 7 to send Ethernet UDP packets to a UNIX system running a C client receiving program that sends the message back to the server. However, sometimes (not always) a message in the last port (and always the last port) that python sends to won't arrive until the next batch of 4 messages is sent. This causes the timing of the message received for the last port incorrect to when it was sent, and <strong>I cannot have two messages back to back on the same port</strong>. </p>
  
  <p>I have been able to verify this in <code>Wireshark</code> by locating two messages that arrived around the same time because the one that wasn't received was processed with the other. I have also checked the timing right after the <code>recv()</code> function and it shows a long delay and then a short delay because it basically had two packets received.</p>
  
  <p><strong>Things I have done to try to fix this</strong>, but has help me explain the problem or how to solve it: I can add a delay in between each sendto() and I will successfully send and receive all messages with correct timing but I want the test to work the way I've written it below; I've increased the priority of the receive thread thinking that my Ethernet receive was not getting signal to pick up the package or that some process was taking too long, but this didn't work and 20ms should be WAY more than necessary to process the data; I have removed ports C and D, then port B misses messages (Only having one port doesn't caause issues), I thought reducing the number of ports would improve timing; Sending to a dummy PORTE immediately after PORTD lets me receive all of the messages with correct timing (I assume the problem is transferred to PORTE); I have also reproduced the python script in a UNIX environment and C code and have had the same issue, pointing me to a receiving issue; I've also set my recv function to time out every 1ms hoping that it could recover somehow even though the timing would be off a bit, but I still saw messages back to back. I've also checked that no UDP packets have been dropped and that the buffer is large enough to hold those 4 messages. Any new ideas would help.</p>
  
  <p>This is the core of the code, the python script will send 4 packets. One 20 byte message to a corresponding waiting thread in C and delay for 20ms</p>
  
  <p>A representation of the python code looks something like </p>
  
  <pre><code>msg_cnt = 5000 
  while cnt &lt; msg_cnt:
     UDPsocket.sendto(data, (IP, PORTA))
     UDPsocket.sendto(data, (IP, PORTB))
     UDPsocket.sendto(data, (IP, PORTC))
     UDPsocket.sendto(data, (IP, PORTD))
  
     time.sleep(.02)
     cnt++
  </code></pre>
  
  <p>The C code has 4 threads waiting to receive on their corresponding ports. Essentially each thread should receive its packet, process it, and send back to the server. This process should take less than 20ms before the next set of messages arrive</p>
  
  <pre><code>void * receiveEthernetThread(){
       uint8_t ethRxBuff[1024];
       if((byteCnt = recv(socketForPort, ethRxBuff, 1024, 0)) &lt; 0){
           perror("recv")
       }else{
          //Process Data, cannot have back to back messages on the same port
          //Send back to the server
       }
  }
  </code></pre>