Home > Archive > PERL Miscellaneous > September 2004 > Socket holding pattern
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Socket holding pattern
|
|
| Gordon 2004-09-08, 4:01 pm |
| 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 2004-09-08, 8:56 pm |
| Gordon <clemmons@gmail.com> wrote in comp.lang.perl.misc:
> 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 2004-09-09, 8:56 am |
| > 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 2004-09-09, 8:56 am |
| Gordon <clemmons@gmail.com> wrote in comp.lang.perl.misc:
>
> 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 2004-09-09, 3:58 pm |
| >>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
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
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
| |
| Gordon 2004-09-10, 8:56 pm |
| > Gordon <clemmons@gmail.com> wrote in comp.lang.perl.misc:
>
>
>
> 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
| |
| Anno Siegel 2004-09-10, 8:56 pm |
| Uri Guttman <uri@stemsystems.com> wrote in comp.lang.perl.misc:
[...]
[color=darkred]
> 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 2004-09-11, 3:56 am |
| >>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> Uri Guttman <uri@stemsystems.com> wrote in comp.lang.perl.misc:[color=darkred]
AS> [...]
[color=darkred]
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
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
|
|
|
|
|