Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Socket problem? Port stuck in TIME_WAIT?

307 views
Skip to first unread message

Mary McDonald

unread,
Feb 8, 1995, 7:41:51 PM2/8/95
to
We are currently porting a SunOS application to Solaris that
consists of two processes that communicate over a socket. When the
processes are killed, the port number cannot be reused for a while.

Doing a "netstat -a" shows that the port is in a TIME_WAIT state.
After a few minutes, the port number can be reused. We suspect that
the order in which the two processes close the socket might be a
factor.

As it stands right now, we don't want to use a new port every time
the processes run.

This did not happen under SunOS. It is driving our automated tests
nuts that run and kill these processes over and over.

Has anyone else seen this? Is there some socket option I can set to
get around this?


Thanks for your help..Mary

CGS

unread,
Feb 9, 1995, 11:38:40 AM2/9/95
to
Mary McDonald (ma...@gazette.patch.tandem.com) wrote:
: We are currently porting a SunOS application to Solaris that


: Thanks for your help..Mary


Mary,

I have had this problem under both 4.1.x and Solaris 2.x. When our map
server dies abnormally ( core dumps :-> ) its socket remains busy for one
minute. The server behaves the same way under 4.1.x. I have not found any
solution for this problem (the server must stay at a known port number
and RPC is TOO slow), and I would really be interested in any fixes.

Good luck, Jeff.


P.S. We have recently moved to 2.3 (Parallax took for ever to release
drivers for their video card) and have begun to see serval extra bytes
slipping into the data stream of two connected sockets. Seams to happen
when during periods when clients are sending large packets in large
numbers per second. Is anyone else having similar problems ?

TauTron

unread,
Feb 14, 1995, 9:33:58 AM2/14/95
to

I ran into the same problem. Setting the SO_REUSEADDR option
on the socket solved it:

int reuse_opt = 1;

if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *)&reuse_opt,
sizeof (reuse_opt)) < 0)
{
perror ("sock-fail");
}

(Tom Steger [ste...@tautron.com] )

Pat Niemeyer

unread,
Feb 14, 1995, 5:44:28 PM2/14/95
to
ma...@gazette.patch.tandem.com (Mary McDonald) writes:

>We are currently porting a SunOS application to Solaris that
>consists of two processes that communicate over a socket. When the
>processes are killed, the port number cannot be reused for a while.

>Doing a "netstat -a" shows that the port is in a TIME_WAIT state.
>After a few minutes, the port number can be reused. We suspect that
>the order in which the two processes close the socket might be a
>factor.


I have been having the same experience.
I only seems to happen when the server side disconnects before the client.

If your client can do the hanging up it should be ok.

I have tried everything else that I could think of, including using
the shutdown(3n) command...

Someone else posted about the reuse-address stuff, I don't think you should
have to do this though. I believe it is a bug.


Pat

Tim Carlson

unread,
Feb 16, 1995, 6:37:11 PM2/16/95
to
>ma...@gazette.patch.tandem.com (Mary McDonald) writes:
>
>>We are currently porting a SunOS application to Solaris that
>>consists of two processes that communicate over a socket. When the
>>processes are killed, the port number cannot be reused for a while.
>


We solved this problem by using setsockopt to set SO_REUSEADDR which
makes the socket available the next time you need to bind to it.
Apparently this is part of the TCP protocol.

-Tim Carlson
tcar...@qualcomm.com


Jonathan Hue

unread,
Feb 19, 1995, 1:29:37 AM2/19/95
to
tcar...@qualcomm.com (Tim Carlson) writes:
>>>consists of two processes that communicate over a socket. When the
>>>processes are killed, the port number cannot be reused for a while.
>We solved this problem by using setsockopt to set SO_REUSEADDR which
>makes the socket available the next time you need to bind to it.
>Apparently this is part of the TCP protocol.

It's the 2MSL (maximum segment lifetime) wait.

For questions like this, I highly recommend W. Richard Stevens' book
"TCP/IP Illustrated, Volume 1: The Protocols". The 2MSL wait is
described on page 242 of this book. It is probably also covered in
his book "UNIX Network Programming", another book I highly recommend.

-Jonathan h...@island.com

0 new messages