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:
>>
>>> Florian Weimer <fweimer@redhat.com> writes:
>>>
>>> [...]
>>>
>>>>> Given the above, could please somebody clarify what is the actual
>>>>> intended behavior of shutdown(..., SHUT_WR) on GLIBC/Linux nowadays?
>>>>
>>>> Thanks for raising the issue.  I posted a patch to libc-alpha.
>>>>
>>>> What you saw is the expected behavior for the mainline Linux kernel.
>>>> Since this is what distributions ship, I think it makes sense to
>>>> document it.
>>>
>>> Thanks! While we are at this part of the manual, I've found that:
>>>
>>> "When you have finished using a socket, you can simply close its file
>>>  descriptor with close; see Opening and Closing Files. If there is still
>>>  data waiting to be transmitted over the connection, normally close tries
>>>  to complete this transmission. You can control this behavior using the
>>>  SO_LINGER socket option to specify a timeout period; see Socket
>>>  Options."
>>>
>>> has its own problem.
>>>
>>> It looks like SO_LINGER is disabled by default in Linux, so "_normally_"
>>> in "normally lose tries to complete this transmission" is probably
>>> wrong.
>>
>> Good point.  Do you think that “normally close tries to deliver data to
>> the peer in the background” captures the Linux behavior more
>> accurately?
>
> I have no opinion, as I really encounter weird behavior on my system. To
> me it looks like this part of GLIBC manual currently describes sane BSD
> approach, while Linux simply gone wild, at least for me (I loose data on
> program exit no matter how I do closing, and shutdown(...,SHUT_WR) only
> makes it worse, even if I put long pause after it before exit()).

Maybe it's related to the full-duplex problem I tried to describe?

>>> As for the actual behavior, is close()/shutdown() on sockets is more
>>> Linux kernel question than GLIBC one? I.e., is GLIBC only a thin wrapper
>>> over calls to kernel and does nothing special by itself? If so, do you
>>> have some reference where I could get information on behavior details
>>> and/or check relevant discussions? Just ask in generic Linux kernel
>>> mailing list?
>>
>> It's only a very thin wrapper, and the transmission/blocking behavior in
>> particular is not changed at all.
>
> Shouldn't GLIBC manual then rather have some very generic description,
> and then tell the details are system-specific?

I think it's not wrong to focus on Linux and TCP/IP these days.

> I now even think that your original patch to the manual could be too
> much, as neither Linux manual page (shame), nor POSIX (somewhat
> expected) specify any details about the topic:
>
> "
> SHUTDOWN(2)               Linux Programmer's Manual              SHUTDOWN(2)
>
> [...]
>       
>       The shutdown() call causes all or part of a full-duplex connection on
>       the socket associated with sockfd to be shut down.  If how is
>       SHUT_RD, further receptions will be disallowed.  If how is SHUT_WR,
>       further transmissions will be disallowed.  If how is SHUT_RDWR,
>       further receptions and transmissions will be disallowed.
> "

Well, we could improve the (non-POSIX) manual pages, too.

Thanks,
Florian