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

[Sergey Organov <sorganov at gmail dot com>]

Florian Weimer <fweimer@redhat.com> writes:

> * 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.

I didn't even try to capture/analyze packets at the time of debugging,
as I didn't know what to expect and had no time to learn.

I'll try to get time to repeat the tests and do some tcpdumps, paying
special attention to RSTs.

Thanks,

-- Sergey