WINC1500 recv() function - Need some clarifications

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#define SOCKET_BUFFER_MAX_LENGTH							1400
/*!< 
	Maximum allowed size for a socket data buffer. Used with @ref send socket 
	function to ensure that the buffer sent is within the allowed range. 
*/

Does this limitation also apply to the recv() function? If I specify the receive buffer to be 4KB, for example, and a remote peer wants to send 2800 bytes of data, am I going to get multiple SOCKET_MSG_RECV socket event callbacks or only one when the entire message is arrived?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Based on Real World observation, you may receive all the data in one callback *or* it may take several callbacks. Note that one single posted 'recv()' can result in multiple back-to-back callbacks. The payload size per-callback will be no more than the posted receive buffer size but you may, on rare occasions, see more than one callback if the WINC has buffered more than your buffer size worth of data at the time you service the interrupt.

 

You cannot stall the callbacks and you *must* consume the data within the callback otherwise it is lost. There's no API to query the length of available Rx data and to read only what you need. You get it all whether you're ready for it or not.

 

This is the single most annoying misfeature of the WINC1500 API.

Steve

Maverick Embedded Technologies Ltd. Home of wAVR and Maven.

wAVR: WiFi AVR ISP/PDI/uPDI Programmer.

Maven: WiFi ARM Cortex-M Debugger/Programmer

https://www.maverick-embedded.co...

Last Edited: Wed. Feb 28, 2018 - 11:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve, thanks for the reply. I have since implemented the traditional circular buffer scheme to handle all the SOCKET_MSG_RECV events for each socket. I also emailed my local FAE asking about the behavior of the recv() and buffer size in general, this is what he wrote me back:

It is possible to call the send function more than once successively without waiting for the SOCKET_MSG_SEND because it will be queued inside WINC1500 buffer and data will not be over written. 
WINC1500 implements a sliding window protocol and it is possible to send multiple packets without waiting for an acknowledgement. 
This can be done until the error SOCK_ERR_BUFFER_FULL is received in the send/recv function return when no more free buffer socket is available. 
When this happens, wait for a defined time duration before trying to transmit data.

The Data buffer in the WINC1500 is shared across different sockets. 
So, we cannot tell you the size of the buffers, as the way it is used up depends on lot of other 
(and external) things. 
In ATWINC1500, the max payload for a TCP packet is 1460 bytes (MAIN_WIFI_M2M_BUFFER_SIZE) 
and the WINC1500 can receive the same. 
For transmission, the max size is limited by SOCKET_BUFFER_MAX_LENGTH which is 1400 bytes.

 

So my understanding is that it would be wasteful to define a receive buffer larger than 1460.