Why Is Socket.BeginReceive Losing Packets From UDP

The following code waits for data over UDP. I have a test function that sends 1000 packets (datagrams?) of 500 bytes each. Each time I run the test function, the receiver gets only the first few dozen packets but drops the rest. I looked at the incoming network data using Wireshark and I see all 1000 packets are actually received, but just don't make it to may app's code.[code]If I add a small delay after each call to Send, more packets make it through; however since Wireshark says that they were all received anyways, it seems that the problem is in my receive code. I should mention that UdpListen is running on a separate thread.Any idea why I am dropping packets? I also tried UdpClient. BeginReceive/ EndReceive but had the same problem. A second issue that bothers me is the global nature of the receive buffer when using Sockets and I am not sure if I don't process incoming packets quickly enough that the buffer will be overwritten.

Based on the various, somewhat conflicting suggestions from replies to this and other posts, I made some changes to my code. Thanks to all who chimed in various bits; I now get all my packets from dial-up to Fast Ethernet. As you can see, it was my code at fault and not the fact that UDP drops packets (in fact I have not seen more than a tiny percentage of packets being dropped or out of order since my fixes). Differences:

1) Replaced BeginReceive()/EndReceive() with BeginReceiveFrom()/EndReceiveFrom(). By itself this had no notible effect though.

2) Chaining BeginReceiveFrom() calls instead of waiting for the async handle to set. Not sure if any benefit here.

3) Explicitly set the Socket.ReceiveBufferSize to 500000 which is enough for 1 second worth of my data at Fast Ethernet speed. Turns out this is a different buffer than the one passed to BeginReceiveFrom(). This had the biggest benefit.

4) I also modified my send routine to wait a couple of ms after having sent a certain number of bytes to throttle based on expected bandwidth. This had a big benefit for my receiving code even though Wireshark said all my data still made it across even without this delay.

I did NOT end up using a separate processing thread because, as I understand it, each call to BeginReceiveFrom will invoke my callback on a new worker thread. This means that I can have more than one callback running at the same time. It also means that once I call BeginReceiveFrom I have time to do my stuff (as long as I don't take too long and exaust the available worker threads).[code]What is not shown above is the error handling and dealing with UDP data being out of order or missing.I think this handles my issue, but if anybody still sees anything wrong with the above (or something I could do better) I would love to hear about it.