Socket holding pattern

[Gordon]

I've written a non-forking server using IO::Socket / IO::Select
based on Cookbook recipe 17.3. I need the ability to "quietly"
restart the server without dropping the connections. Currently
I'm using the hackish method of removing the 'use'd modules and
reloading them but that doesn't allow the core code to be
reloaded and I would prefer to have a clean start/stop anyway.

If I setup a separate 'holding' server on an alternate port,
does anyone know of a way to switch the connections over to it?
I would like to plug the connections into this holding server
while the main server reboots, then reconnect them.

Any tips/pointers/advice would be greatly appreciated. Thanks.

 

[Anno Siegel]

I've written a non-forking server using IO::Socket / IO::Select
based on Cookbook recipe 17.3. I need the ability to "quietly"
restart the server without dropping the connections. Currently
I'm using the hackish method of removing the 'use'd modules and
reloading them but that doesn't allow the core code to be
reloaded and I would prefer to have a clean start/stop anyway.

If I setup a separate 'holding' server on an alternate port,
does anyone know of a way to switch the connections over to it?
I would like to plug the connections into this holding server
while the main server reboots, then reconnect them.

If the duration of each connection is limited, an "overlapping restart"
is a possibility.

On a signal (or something), the server forks and execs a new copy.
It also ceases to accept new connections, but continues serving
the old ones. When the last connection is gone, it dies. All
new requests are served by the new process.

If you have unlimited connection time, and can't afford to break
long-lasting ones, this simple scheme won't work. Sketchy as it
is, it may well not work for other reasons.

Anno

 

[Gordon]

If the duration of each connection is limited, an "overlapping restart"
is a possibility.

On a signal (or something), the server forks and execs a new copy.
It also ceases to accept new connections, but continues serving
the old ones. When the last connection is gone, it dies. All
new requests are served by the new process.

If you have unlimited connection time, and can't afford to break
long-lasting ones, this simple scheme won't work. Sketchy as it
is, it may well not work for other reasons.

Anno

Yeah, this is for unlimited connection times - it's a mud server.

-gordon

 

[Gordon]

If the duration of each connection is limited, an "overlapping restart"

is a possibility.

On a signal (or something), the server forks and execs a new copy.
It also ceases to accept new connections, but continues serving
the old ones. When the last connection is gone, it dies. All
new requests are served by the new process.

If you have unlimited connection time, and can't afford to break
long-lasting ones, this simple scheme won't work. Sketchy as it
is, it may well not work for other reasons.

Anno

Thanks for the message, it's actually for unlimited connections
though. It's a mud / online game server.

-gordon

 

[Anno Siegel]

Thanks for the message, it's actually for unlimited connections
though. It's a mud / online game server.

I'd still go a long way to avoid having to hand over multiple
connections from one process to another. Apart from the technicalities
of doing that, you may run into compatibility problems when the
new server must handle connections that were established under the
old one.

You could just leave the old server running (until the next
system reboot -- nothing survives that anyway). Bug the players
still logged in on the old server with messages ("New features!
Log out and back in to use them!") until they do.

Another possibility is to open the relevant file handles (sockets)
so that they are immune to close-on-exec. (Set $^F to something
huge while they are opened). The old server process would have
to tell the new one which file descriptors are in use, so the new
one can take them over. Besides the compatibility issues already
mentioned, there may be synchronization problems when both processes
hold file handles to active connections.

Anno

 

[Uri Guttman]

AS> Another possibility is to open the relevant file handles (sockets)
AS> so that they are immune to close-on-exec. (Set $^F to something
AS> huge while they are opened). The old server process would have
AS> to tell the new one which file descriptors are in use, so the new
AS> one can take them over. Besides the compatibility issues already
AS> mentioned, there may be synchronization problems when both processes
AS> hold file handles to active connections.

it can be much harder than that too. most servers of this type (long
lived connections) keep state about each connection so that has to be
stored in a place away from the socket itself. if that data is in
objects and you reload that class, who knows what will happen to those
objects? the newly loaded code would always need to know it is fresh and
reload those objects and such. this idea of reloading code on the fly
and keeping connections is not for the feint of heart nor the weak in
coding and design skills.

and i agree, since this is only for a mud, who cares? kick all the
players and let them reconnect.

uri

 

[Anno Siegel]

[...]

and i agree, since this is only for a mud, who cares? kick all the
players and let them reconnect.

"Only" a mud? What are you talking about? Break a player in action
and you have made an enemy for life!

Anno

 

[Uri Guttman]

AS> [...]

AS> "Only" a mud? What are you talking about? Break a player in action
AS> and you have made an enemy for life!

it won't be the first one i have ever made, nor the last!

uri