Author Topic: Does UDP Listener wait for APP_ACCEPT before filling buffers with next UDP Msg?  (Read 2936 times)

Offline thamanjd

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Does a UDP Listener wait for APP_ACCEPT to be returned before allowing reception of another UDP packet on that socket?

Ive got a UDP Listener listening for UDP packets on a socket. Inside the Listener i'm passing the pointer to the data and the data length to a subroutine and i think that subroutine in turn passes it to a couple of other subroutines. Eventually it comes back out of those subroutines and exists the listener with "return APP_ACCEPT;"

Maybe this sounds dumb but... none of the parameters being passed by the Listener function are being overwritten by another udp packet coming in while i'm analysing the last one are there? I imagine uTasker waits for the APP_ACCEPT from the Listener before allowing another packet to be received.

I havn't had any problems. Just want to make sure.

John Dowdell

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3068
    • View Profile
    • uTasker
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