Re: Help: shutdown(..., SHUT_WR) on TCP sockets

[Florian Weimer <fweimer at redhat dot com>]

* Sergey Organov:

> Florian Weimer <fweimer@redhat.com> writes:
>
>> * Sergey Organov:
>>
>>> Maybe, but honestly, I fail to see how adding 'shutdown(fd, SHUT_WR)'
>>> anywhere before 'close(fd)' can do things worse from the POV of data
>>> delivery to the other end.
>>>
>>> What I observe is that either:
>>>
>>> sleep(1);
>>> close(fd);
>>> exit(0);
>>>
>>> or:
>>>
>>> sleep(1);
>>> shutdown(fd, SHUT_WR);
>>> close(fd);
>>> exit(0);
>>>
>>> deliver all the data, while:
>>>
>>> shutdown(fd, SHUT_WR);
>>> sleep(1);
>>> close(fd);
>>> exit(0);
>>>
>>> cuts some of the data (read() returns 0 on the other end indicating
>>> closed socket).
>>
>> Wait, you get less data with the last sequence?  And you do not write to
>> fd after the shutdown call?
>
> Yes, and this is single-threaded application so I'm very sure I don't
> write anything myself.
>
> However, as I already mentioned, ioctl(fd, TIOCOUTQ, &v) gives 0 before
> shutdown() and 1 right  after shutdown(), that suggests shutdown()
> itself writes something. Dunno if it's expected.

It needs to queue the FIN segment, for the connection teardown
handshake.

>>> Another mystery is that 'ioctl(fd, TIOCOUTQ, &v)' gives 0 in all the
>>> above cases when put at the beginning of the above sequences[*],
>>> indicating that there are no pended data, so there should be nothing to
>>> loose in the first place, one way or another.
>>
>> Yes, I agree that data loss should not happen in these cases.
>
> It looks like shutdown() does something that is transferred to receiver
> and makes it drop some amount of recently received data that receiving
> application didn't read yet. I.e., it's probably receiving end that
> drops the data?

Do you see any RST segments in packet captures?  As I said, RST is not
expected to be ordered with respect to data delivery, so if an RST
segment is generated, then it would explain the data loss.

Thanks,
Florian