RE: [PATCH] rsocket: Return ECONNRESET when socket in recv is disconnected

Sreedhar Kodali
2014-10-13T03:51:45Z

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.