Hi Sean,
I am fine with your conclusion. But since R-Sockets emulates socket
functionality on top of RDMA, it would be helpful if this behavioral
difference between TCP and R-Sockets is captured as part of the user
documentation.
Thank You.
- Sreedhar
On 2014-10-10 11:04, Hefty, Sean wrote:
Upon successful completion, recv() shall return the length of the
message in bytes. If no messages are available to be received and the
peer has performed an orderly shutdown, recv() shall return 0.
Otherwise, -1 shall be returned and errno set to indicate the error.
Errors
The recv() function shall fail if:
ECONNRESET
A connection was forcibly closed by a peer.
==========
So the current behavior of returning 0 is wrong as there was no
orderly
shutdown performed on the other end before a close() is issued [
http://stackoverflow.com/questions/5879560/how-can-i-cause-an-econnreset-
in-recv-from-a-client
The patch is incorrect then. It always returns ECONNRESET. Rsockets
does not distinguish between the app calling shutdown versus close.
Because everything is in user space, the disconnect message itself
comes from the app. The rclose call invokes rshutdown, otherwise the
remote side will may never know that the peer is gone (which can
happen if the app exits without calling rclose).
I'm inclined to just leave the current behavior as is. I don't see
why a real app would care if close performed an orderly shutdown or
not, as this errors on the side of acting better than expected.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
