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

Florian Weimer fweimer@redhat.com
Mon Jul 8 14:23:00 GMT 2019


* 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



More information about the Libc-help mailing list