[comp.protocols.tcp-ip] tcp-ip problems on the AT&T 6386

ceide@bbn.com (Chantal Eide) (08/04/89)

We have an ATT 6386 using Interlan's TCP/IP implementation (version?).
We are having some difficulties:
 
1. getsockname() makes a socket unusable if called after listen()
 
        /* works */                             /* does not work */
        s = socket(...)                         s = socket(...)
        bind(s, ...)                            bind(s, ...)
        getsockname(s, ...)                     listen(s, ...)
        listen(s, ...)                          getsockname(s, ...)
                                                /* s is now unusable */
   Any insights anyone?

2. Closing a tcp connection immediately flushes data still in the "pipe".
   Our application sends a bunch of data, then calls close.  The
   documentation states that by default sockets are set to "linger" for 45
   seconds.  We even tried explicitely setting linger on [with
   setsockopt(s, ... SO_LINGER) (or whatever)], to no avail.  Has anyone
   dealt with this before?

hwajin@wrs.wrs.com (Hwajin Bae) (08/08/89)

In article <1921@currant.bbn.com> ceide@bbn.com (Chantal Eide) writes:
>1. getsockname() makes a socket unusable if called after listen()
> 
>        /* works */                             /* does not work */
>        s = socket(...)                         s = socket(...)
>        bind(s, ...)                            bind(s, ...)
>        getsockname(s, ...)                     listen(s, ...)
>        listen(s, ...)                          getsockname(s, ...)
>                                                /* s is now unusable */
>   Any insights anyone?

The socket implementations for most system V.3 OS's are emulations of
sockets over either TLI (Transport Library Interface) or TPI (Transport 
Provider Interface -- AT&T's specification for STREAMS multiplexing
module in the kernel to service TLI calls, etc.).  TPI state machine
does not allow certain things to happen -- for example,
T_OPTMGMT is not allowed after a connection has been established.
If the 'getsockname' is implemented on top of TLI and use TLI functions
in the order that doesn't conform to the TPI state machine, you will
get an error message.  What kind of error message do you get?
BTW, using internal socket data structure one can retrieve the socket
address immediately if socket calls all implementation directly on top
of TPI module as stream-head interfaces -- it doesn't even have to
go through TPI at all.  So it's my guess that your socket library may
be implemented on top of TLI in some incorrect way in terms of state
transition.

>2. Closing a tcp connection immediately flushes data still in the "pipe".
>   Our application sends a bunch of data, then calls close.  The
>   documentation states that by default sockets are set to "linger" for 45
>   seconds.  We even tried explicitely setting linger on [with
>   setsockopt(s, ... SO_LINGER) (or whatever)], to no avail.  Has anyone
>   dealt with this before?

SO_LINGER option get be set with linger time of zero (l_linger) to effective
tell TCP not to linger -- like 4.2 BSD SO_DONTLINGER option.

-- 
Hwajin Bae
hwajin@wrs.com
...!{uunet, rtech, sun}!wrs!hwajin
Wind River Systems, 1350 Ocean Ave, Emeryville, CA 94608