[comp.protocols.tcp-ip] BSD sockets question

wayne@ultra.com (Wayne Hathaway) (12/08/90)

Sorry to bother the TCP/IP group with a BSD-sockets-specific question, 
but it really does relate to protocol behavior.

Anyway, my question is the following:  For connected stream sockets,
are there ANY semantic differences between shutdown(2) and close()?
If so, can somebody please explain them?  (For example, if multiple
processes are sharing a connected socket, only the LAST close() will
have an effect; is this true with shutdown(2)?  Is "data in the pipe"
treated any differently?  Etc ...)

Oh, when I say "shutdown(2)" I mean the shutdown() system call with
a "how" parameter of "2," meaning shutdown both read and write; I am
NOT alluding to section 2 of the manual.

Thanks muchly!

    Wayne Hathaway               domain: wayne@Ultra.COM
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134           direct: Hey, you!

PS:  For that matter, can anybody explain what shutdown does with a
     connected DATAGRAM socket?  Thnx again.

gwilliam@SH.CS.NET (George Williams) (12/19/90)

    Date:    7 Dec 90 17:23:24 GMT
    From:    Wayne Hathaway <usc!zaphod.mps.ohio-state.edu!mips!ultra!wayne@ucs
	      d.edu>
    Subject: BSD sockets question

    Sorry to bother the TCP/IP group with a BSD-sockets-specific question, 
    but it really does relate to protocol behavior.

    Anyway, my question is the following:  For connected stream sockets,
    are there ANY semantic differences between shutdown(2)
>> Generates a TCP level abort. Sent out of band or expedited.
>> Can bypass 'close' and 'data'. Especially in LAN environments.

    and close()?
>> Allows for graceful shutdown i.e. only one half ( sending TCB ) of
>> connection is deleted. Sent on normal data flow, so does not bypass
>> data in transient. Process allowed to receive data already in the
>> pipe.

    If so, can somebody please explain them?  (For example, if multiple
    processes are sharing a connected socket, only the LAST close() will
    have an effect;
>> Really each close has an affect on the socket level. A trick used in
>> BSD UNIX is to obtain a new socket desciptor, pass the options to 
>> a newly forked child, and go back to listening on the original socket
>> for new connection requests. When you close the origional or 'well
>> known port' as you indicated above the (LAST); service is gone or
>> no longer available. There are variation on this scenario due to
>> implementation and system specifics but the rules are essentially the same.
>> In this manner you can achieve concurrency within a single server process.

>> Note: I recall working with some interfaces ( don't now if BSD ) derivatives
>>       or not that turned shutdown into a close for the receiving process.
>>       Don't recall if this was/is a bug or a feature...yes, I know someone
>>       out there is gonna tell me RTFRFC -:)..

   is this true with shutdown(2)?  Is "data in the pipe"
    treated any differently?  Etc ...)
>> Shutdown would be issued when an entire server or process goes away,
>> removing a 'well known port' due to administative or disruptive (error)
>> processing.

    Oh, when I say "shutdown(2)" I mean the shutdown() system call with
    a "how" parameter of "2," meaning shutdown both read and write; I am
    NOT alluding to section 2 of the manual.

    Thanks muchly!

        Wayne Hathaway               domain: wayne@Ultra.COM
        Ultra Network Technologies     uucp: ...!ames!ultra!wayne
        101 Daggett Drive             phone: 408-922-0100 x132
        San Jose, CA 95134           direct: Hey, you!

    PS:  For that matter, can anybody explain what shutdown does with a
         connected DATAGRAM socket?  Thnx again.