This personality is designed to handle multiple connections all within one process. It should only be used with protocols that are guaranteed to be able to respond quickly on a packet by packet basis. If determining a response could take a while or an unknown period of time, all other connections established will block until the response completes. If this condition might ever occur, this personality should probably not be used.

This takes some nice features of Net::Server (like the server listen socket setup, configuration file processing, safe signal handling, convenient inet style STDIN/STDOUT handling, logging features, deamonization and pid tracking, and restartability -SIGHUP) and some nice features of IO::Multiplex (automatic buffered IO and per-file-handle objects) and combines them for an easy-to-use interace.

See examples/samplechat.pl distributed with Net::Server for a simple chat server that uses several of these features.

The *_hook methods mentioned above are meant to be overridden with your own subroutines if you desire to provide additional functionality.

The loop() method of Net::Server has been overridden to run the loop routine of IO::Multiplex instead. The Net::Server methods may access the IO::Multiplex object at $self->{mux} if desired. The IO::Multiplex methods may access the Net::Server object at $self->{net_server} if desired.

This hook only gets called in conjunction with the check_for_dequeue setting. It will run every check_for_dequeue seconds. Since no forking is done, this hook should run fast in order to prevent blocking the rest of the processing.

To utilize the optional timeout feature of IO::Multiplex, you need to specify a timeout by using the set_timeout method.

$self->{net_server}->{mux}->set_timeout($fh, $seconds_from_now);

$fh may be either a client socket or a listen socket file descriptor within the mux. $seconds_from_now may be fractional to achieve more precise timeouts. This is used in conjunction with mux_timeout, which you should define yourself.

The main loop() routine will call $obj->mux_timeout($mux, $fh) when the timeout specified in set_timeout is reached where $fh is the same as the one specified in set_timeout() and $obj is its corresponding object (either the unique client specific object or the main listen callback object) and $mux is the main IO::Multiplex object itself.

Callback objects should support the following interface. You do not have to provide all of these methods, just provide the ones you are interested in. These are just like the IO::Multiplex hooks except that STDOUT is tied to the corresponding client socket handle for your convenience and to more closely emulate the Net::Server model. However, unlike some other Net::Server personalities, you should never read directly from STDIN yourself. You should define one or more of the following methods:

(OPTIONAL) Run once when the client first connects if the allow_deny passes. Note that the $self->{net_server}->{server} property hash may be modified by future connections through Net::Server. Any values within it that this object may need to use later should be copied within its own object at this point.

If you need to use the IO::Multiplex style set_timeout / mux_timeout interface, you cannot use the Net::Server style check_for_dequeue / run_dequeue interface. It will not work if the check_for_dequeue option is specified. The run_dequeue method is just a compatibility interface to comply with the Net::Server::Fork style run_dequeue but is implemented in terms of the IO::Multiplex style set_timeout and mux_timeout methods.