This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Help: shutdown(..., SHUT_WR) on TCP sockets
- From: Florian Weimer <fweimer at redhat dot com>
- To: Sergey Organov <sorganov at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Mon, 08 Jul 2019 15:19:31 +0200
- Subject: Re: Help: shutdown(..., SHUT_WR) on TCP sockets
- References: <qblfrh$4m4i$1@blaine.gmane.org> <87woippfuu.fsf@oldenburg2.str.redhat.com> <87a7flxlvp.fsf@javad.com> <87ef4xnlnv.fsf@oldenburg2.str.redhat.com> <87woipuld0.fsf@javad.com> <87sgt9i5s5.fsf@oldenburg2.str.redhat.com> <87k1elp36e.fsf@javad.com>
* 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?
That should definitely not happen.
> 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. There has
to be something else that triggers an RST segment, or perhaps there is a
middlebox with a broken TCP implementation.
Thanks,
Florian