Hi John
Sockets are a software concept and the point here is the way that the Ethernet buffer is handled. The UDP (and TCP) listener is a callback routine which is passed a pointer to the frame in the Ethernet input buffer and the valid frame's length. While the callback routine is handling the data it will remain stable and not be overwritten by further Ethernet activity - this is true also then when you are debugging when the buffer is required to remain stable for a long time.
Depending on the processor used there will be a number of Ethernet RX buffers available. These 'belong' either to the Ethernet controller or the software. Originally they belong to the Ethernet controller and it may copy received data to them. Once an Ethernet frame has been completely received, the ownership moves to the software and the Ethernet controller may not use the buffer again until the software frees it. The Ethernet task first allows the buffers to be handled by the protocol handlers (like IP and UDP), which perform the listener callbacks. Only when this process is complete is the Ethernet buffer ownership passed back to the Ethernet controller (see fnFreeBuffer() in Ethernet.c).
Of course, if you are debugging, all RX Ethernet buffers will probably get full quickly and then there will be no space for more receptions - this will result in overruns. Overruns do not actually overwrite and existing frames but instead the new frames are lost. This can also happen in a network with lots of data being received quickly (eg. broadcast frames) if the processor can not process the frames as fast as they are arriving. In this case fast processors have advantages as do Ethernet controller with more space for higher quantities of Ethernet buffers.
Regards
Mark
