- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have a socket defined as follows:
lwip_setsockopt(SSocket, SOL_SOCKET, SO_RCVTIMEO, &recv_timeout, sizeof(recv_timeout));
lwip_setsockopt(SSocket, IPPROTO_TCP, TCP_NODELAY, &recv_timeout, sizeof(recv_timeout));
It seems that sometimes, when we call
recvLen = lwip_recvfrom( SSocket, receive_buf, sizeof( receive_buf ), MSG_PEEK, NULL, NULL );
we do not always see data that should be on the socket. We have wiresharked the connection to make sure that the data is present. We see our request go out, and quickly see the response come back (100ms or so), but lwip_recvfrom can take up to three seconds before it reports that there is something on the socket.
Has anyone else experienced this? Does the BCM43362 do internal packet stacking because our packets are fairly small (<60 bytes)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I figured it out. The problem is actually the opposite. lwIP does not stack packets when calling lwip_recvfrom. We have a periodic packet, and a non periodic packet. The receive expects a response from the periodic packet, but everytime we send the non period packet, the response caused by that packet adds one more packet to read onto the receive buffer. Since lwip does not stack packets, we need to do extra reads to catch up, essentially always reading as many packets as available, otherwise we will be backing up by one packet everytime we send a non periodic packet, which pushes out our perceived received time by one more read window each time.