title: UDP Packets, Seen by Wireshark, Dropped by (do not even reach) WSARecvFrom
body: <p>I have quite a bewildering problem.<br>
  I'm using a big C++ library for handling some proprietary protocol over UDP on Windows XP/7. It listens on one port throughout the run of the program, and waits for connections from distant peers.</p>
  
  <p>Most of the time, this works well. However, due to some problems I'd experienced, I've decided to add a simple debug print directly after the call to <code>WSARecvFrom</code> (the win32 function used in the library to recv datagrams from my socket of interest, and tell what IP and port they came from).<br>
  Strangely enough, in some cases, I've discovered packets are dropped at the <strong>OS level</strong> (i.e. I see them in Wireshark, they have the right dst-port, all checksums are correct - but they never appear in the debug prints I've implanted into the code).</p>
  
  <p>Now, I'm fully of the fact (people tend to mention a bit too often) that "UDP doesn't guarantee delivery" - but this is not relevant, as the packets <strong>are</strong> received by the machine - I see them in Wireshark.<br>
  Also, I'm familiar with OS buffers and the potential to fill up, but here comes the weird part...</p>
  
  <p>I've done some research trying to find out which packets are dropped exactly. What I've discovered, is that all dropped packets share two things in common (though <em>some</em>, but definitely not <em>most</em>, of the packets that <em>aren't</em> dropped share these as well):</p>
  
  <ol>
  <li>They are small. Many of the packets in the protocol are large, close to MTU - but all packets that are dropped are under 100 bytes (gross).</li>
  <li>They are always one of two: a SYN-equivalent (i.e. the first packet a peer sends to us in order to initiate communications) or a FIN-equivalent (i.e. a packet a peer sends when it is no longer interested in talking to us).</li>
  </ol>
  
  <p>Can either one of these two qualities affect the OS buffers, and cause packets to be randomly (or even more interesting - selectively) dropped?<br>
  Any light shed on this strange issue would be very appreciated.</p>
  
  <p>Many thanks.</p>
  
  <hr>
  
  <p><strong>EDIT (24/10/12):</strong></p>
  
  <p>I think I may have missed an important detail. It seems that the packets dropped before arrival share something else in common: They (and I'm starting to believe, <em>only</em> they) are sent to the server by "new" peers, i.e. peers that it <strong>hasn't tried to contact before</strong>.</p>
  
  <p>For example, if a syn-equivalent packet arrives from a peer* we've never seen before, it will not be seen by <code>WSARecvFrom</code>. However, if we have sent a syn-equivalent packet to that peer <strong>ourselves</strong> (even if it didn't reply at the time), and now it sends <strong>us</strong> a syn-equivalent, we will see it.</p>
  
  <p>(*) I'm not sure whether this is a <em>peer</em> we haven't seen (i.e. ip:port) or just a <em>port</em> we haven't seen before.</p>
  
  <p>Does this help?<br>
  Is this some kind of WinSock option I've never heard of? (as I stated above, the code is not mine, so it may be using socket options I'm not aware of)</p>
  
  <p>Thanks again!</p>