[lwip-devel] [task #14395] recv of short buffer should eventually time out

[Joel Cunningham]

Follow-up Comment #5, task #14395 (project lwip):

I've done some auditing of this behavior in LwIP and wanted to share a couple
of things:

My port has LWIP_SO_RCVTIMEO enabled and for sockets that don't set
SO_RCVTIMEO, it uses 0 for a timeout, thus providing the behavior of returning
whatever is in the conn->recvmbox and not blocking.  The push flag doesn't
matter in this case either, meaning we don't wait if PSH is not set.  If I had
SO_RCVTIMEO set to a non-zero value, I think it block waiting to satisfy the
full amount

My understanding of BSD semantics is that a recv() call always returns if
there is data available without blocking.  SO_RCVTIMEO controls blocking when
no data was available and returns EWOULDBLOCK when timing out

Man page for Linux recv summarizes:

If no messages are available at the socket, the receive calls wait for a
message to arrive, unless the socket is nonblocking (see fcntl(2)), in which
case the value -1 is returned and the external variable errno is set to EAGAIN
or EWOULDBLOCK. The receive calls normally return any data available, up to
the requested amount, rather than waiting for receipt of the full amount
requested. 

https://linux.die.net/man/2/recv 

Also, in Steven's TCP/IP Illustrated Vol. 1: The Protocols, it has this to say
about receiver side handling of PSH:

"Berkeley-derived implementations ignore a received PUSH flag because they
normally never delay the delivery of received data to the application"

So in summary, I see the BSD behavior if LWIP_SO_RCVTIMEO is enabled and
application never use SO_RCVTIMEO, otherwise it has non-standard behavior

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?14395>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/