[net.unix-wizards] releasing internet ports...

jon@msunix.UUCP (04/22/86)

Hello,

I just have a simple question, it doesn't really affect my program,
but I'm curious as to the reasons behind its behavior.

I am writing this multiuser blackjack game in my spare time using
sockets in the Internet address family (Sun-2/120, Sun 2.0 UNIX).
The interprocess communication seems to work fine, all I have to do
is figure out how to arrange six people in a semicircle on a 24x80
screen and figure out what to do when a person is dealt four eights
and splits pairs three times, but that's another story...

I'm in this mode where I'm adding little features, relinking, and then
firing up the server (dealer) and getting a client (player) to connect.
I fool around with the client for a while, then I exit.  I then send
the server a signal to kill it.  The server catches the signal and closes
its open file descriptors, then exits.  If I try to fire up the server
soon after that, it dies on the bind, with "address already in use".
If I wait a couple minutes before retrying, it runs fine.  My question
is, is there like a timeout in the spec for tcp/ip that says a port
is released x amount of time after the last socket bound to it dies, or
something like that?  Should I be making another system call before I
exit or something?  Perhaps someone could point me to a section in
a tcp/ip spec.  Oh, yes, I don't really have much of a formal CS
education, so explanations in simple terms would be appreciated.


"If we did it like everyone else,		Jonathan Hue
what would differentiate us from		Via Video Inc.
every other company in Silicon Valley?"	  sun!sunncal\
						      >!leadsv!msunix!jon
"A profit?"				amdcad!cae780/

parrish@edn-vax.arpa (Jimmy Parrish) (04/28/86)

What you want to do is use the setsockopt call with the parameter
SO_REUSEADDR as in setsockopt(s,SOL_SOCKET,SO_REUSEADDR,0,0); .
This allows you to bypass the timeout condition you are experiencing.

Jimmy Parrish

dave@smaug (Dave Cornutt) (05/22/86)

Summary: TCP port timeout problem
Line eater: yes

In response to the query about TCP port reuse on a Sun station:

>I'm in this mode where I'm adding little features, relinking, and then
>firing up the server (dealer) and getting a client (player) to connect.
>I fool around with the client for a while, then I exit.  I then send
>the server a signal to kill it.  The server catches the signal and closes
>its open file descriptors, then exits.  If I try to fire up the server
>soon after that, it dies on the bind, with "address already in use".
>If I wait a couple minutes before retrying, it runs fine.  My question
>is, is there like a timeout in the spec for tcp/ip that says a port
>is released x amount of time after the last socket bound to it dies, or
>something like that?  Should I be making another system call before I
>exit or something?  Perhaps someone could point me to a section in
>a tcp/ip spec.  Oh, yes, I don't really have much of a formal CS
>education, so explanations in simple terms would be appreciated.

I tried this on our several Sun-2's and 3's that we have laying around here.
All of these run Sun UN*X 3.0, and none of them seem to have this problem,
so maybe they fixed it.  Try installing this if you can and see if it helps.
If you can't get 3.0, you should check two things: (1) Make sure you ex-
plicitly close the file descriptors for the sockets.  You've probably 
already done this, but I just thought I'd mention it. (2) Try using a
"shutdown" call on the socket before closing it, for example:

	shutdown(socketdesc,2);
	close(socketdesc);

>The interprocess communication seems to work fine, all I have to do
>is figure out how to arrange six people in a semicircle on a 24x80
>screen and figure out what to do when a person is dealt four eights
>and splits pairs three times, but that's another story...

Throw the bum out.  He's got to be dealing from low memory. :-)


Dave Cornutt
Gould Computer Systems 
Ft. Lauderdale, FL

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."