[MUD-Dev] Re: Quick socket question

[Jon Leonard]

On Sat, Nov 07, 1998 at 03:06:42PM -0600, Dr. Cat wrote:

[socket reuse problems]

> I don't know how hard getting it going on SYSV 
> would have been, but I know my O'Reilly "Using C on the Unix system" is 
> so old that it says Berkeley Unixes have sockets and SYSV don't!  Surely 
> SYSV has to have sockets now, what with this "internet" thing having 
> gotten so popular since this book was written - don't they?

SYSV got sockets as a standard feature in SYSVR4.  You need to link with
some extra libraries, which should be listed in the man pages.
It's -lsocket -lnsl or something like that.

> Anyway, I got a couple compatibility problems involving select() and 
> accept() worked out, but I've noticed the return of a problem we 
> sometimes had under Linux with the old DragonSpires server, which is the 
> ancestor of the Furcadia server code.  After the game is shut down or the 
> server code crashes, and it tries to restart, it fails to bind the port 
> for the next 15-20 minutes.  This is an improvement over the Linux of 4 
> years ago, which apparently didn't have a timeout for this case and would 
> leave the game unaccessible for hours, days, or potentially forever until 
> I could successfully beg the uncooperative sysadmin of that system for a 
> reboot!  Still, I'd like to fix this problem if I can.

I've seen the problem, but my current code doesn't exhibit it.  I've
been able to successfully restart the DevMUD server in 2 or 3 seconds,
and on my old server I've actually started up a new MUD on the same
socket that the old one still had players connected to.

That is, the following sequence is possible:

Open socket
Players connect to socket
Server shuts down main socket, but doesn't kick players off
New server opens main socket with same port number
Players connect to socket, and get the new server

After that different players are connected to two different muds,
both nominally using the same port.

> I thought at first it was because I wasn't closing the socket when the 
> accept() problem I was having crashed it.  But I did a proper operator 
> shutdown, which takes the bound socket and does shutdown(mastsock, 2)
> and close(mastsock) before existing.  Do I need to do anything more on 
> closing to make sure the port is freed up, even if there's some 
> recalcitrant user's machine out there still desperately trying to talk to 
> it?  Or is there a setsockopt option I need to set differently?  Or is 
> there a sysadmin tweak to change that timeout value?  If anyone's dealt 
> with this issue under Linux before (or any other Unix that has the same 
> issue) I'd appreciate a pointer.  :X)

I think that it's one of the miscellanious socket options, maybe SO_LINGER?
Since I'm not seeing it anymore, it isn't bothering me.

You're welcome to look at my code either:

(DevMUD prototype)
http://frost.slimy.com/devmud/prototypes/proto_1/modules/socket/

(Better documented code)
http://slimy.com/~jleonard/src/ipc.html

The differences between your code and what I did might be enlightening.

Both sets of source code are in the public domain.

Jon Leonard