Hi Jason,
Thanks for your explanation - I got it. On the other mail thread
I have just requested Sean to mark this as R-Sockets limitation or
behavioral difference so users wouldn't confuse when they try
to compare with TCP.
Thank You.
- Sreedhar
On 2014-10-10 23:15, Jason Gunthorpe wrote:
On Fri, Oct 10, 2014 at 10:37:34AM +0530, Sreedhar Kodali wrote:
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
'Orderly shutdown' is any call of close() when there is no data in the
recv queue, or shutdown(SHUT_WR).
http://stackoverflow.com/questions/5879560/how-can-i-cause-an-econnreset-in-recv-from-a-client
This accepted answer is not correct, close on its own does not
generate ECONNRESET.
This is trivally shown with strace and a bit of python:
server:
import socket
s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.bind(("127.0.0.1",9090))
s.listen(1)
conn, addr = s.accept()
conn.recv(1024)
client:
import socket
s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("127.0.0.1",9090))
s.close()
Result:
[..]
accept(3, {sa_family=AF_INET, sin_port=htons(41284),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
recvfrom(4, "", 1024, 0, NULL, NULL) = 0
ECONNRESET signals a special condition that it seems rsockets cannot
detect, as it doesn't have the one sided close semantics of TCP.
Jason
--
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
