NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/unix/sysv386/16356

Text File | 1992-11-09 | 1.6 KB | 36 lines

Newsgroups: comp.unix.sysv386
Path: sparky!uunet!ukma!asuvax!ennews!anasaz!duane
From: [e-mail] (Duane Morse)
Subject: TCP/IP t_close/close blocks when data is outstanding -- any relief?
Organization: Anasazi, Inc.  Phoenix, Arizona USA
Date: Tue, 10 Nov 1992 02:00:15 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet News)
Lines: 25

Under the latest release of 386/IX, we have found that t_close (under
TLI) and close (under Berkeley sockets) both block the calling processes
for about 2 minutes if there's data waiting to be sent or acknowledged.
In our test scenario, we unplug one machine from the Ethernet LAN after
having established a connection from another machine.  If we send data
after the connection has been dropped and then decide to close the
connection, the program blocks.

The sockets version is using the SO_LINGER option with 0 as the timeout,
and I've tried an ioctl(fd, I_FLUSH, FLUSHW) on the TLI version before
calling t_close, all to no avail.

The TLI version of the same test software also blocks under NCR's Sys V R 4
OS on a 3433 and under SCO Unix unless I use the I_FLUSH trick, in which
case they don't block.  I haven't worked on the sockets version long enough
on those platforms to perform the same test.

Has anyone encountered this problem under 386/IX and figured out how
to get around it?  The primary application using TCP/IP at our company
is supposed to be non-blocking because it handles multiple connections,
and it's very rude for it to block when trying to close a connection.
--

Duane Morse    e-mail: [e-mail]
[phone]