superfrink has asked for the wisdom of the Perl Monks concerning the following question:

I'm writting a server that will have many client connections. I was going to use Net::Server::Multiplex but I also want to talk to a message queue ( Spread ). Spred requires polling. N:S:M will deal will all of my client-server I/O (and the listening socket) but not with polling the messages queue.

Any ideas where I should put the polling of Spread? I thought about putting it at the end of each I/O function in the Multiplex system (new connection, recieve data, etc). I also thought about using a timer and signal handler but I don't think it's desireable to have the signal handler get too long (polling, reading the message queue and, then dealing with the message.)

The idea is that the server's function is done by many daemons that poll the message queue system. I'm writting an interface to that system which will listen on a TCP socket and map requests over this network interface to request-messages on the Spread Message Queue. The responses will come back over the message queue and my program will send the results back over the network.

Thanks, Chad
  • Comment on Using Net::Server::Multiplex and polling Spread

Replies are listed 'Best First'.
Re: Using Net::Server::Multiplex and polling Spread
by perrin (Chancellor) on Jul 04, 2004 at 01:36 UTC
    So, does the request that the client sends in get re-sent via Spread and then the client sits and wiats for the response? If that's the case, Net::Server::Multiplex seems like a bad fit.

    I would suggest looking at a multi-process server model instead, and stealing some ideas from the Worker module in Spread::Queue.

      So, does the request that the client sends in get re-sent via Spread and then the client sits and wiats for the response? If that's the case, Net::Server::Multiplex seems like a bad fit.

      The client connections will be long lived. They will not be for a single request like say a HTTP request. The logic of the system is a state machine that changes based on input from the clients. When the state changes more than just the client who's input caused the change will be notified.

      There will be many state machines in both instances and logic (eg groups of clients). I was going to allow them to be running process and have one network interface process to keep the client-server interface simple (also clean for firewalls).

      Spread::Queue::Worker looks like it would be great for single requests but it still replies to the Spread system. (Reading a message from Spread blocks and the process should be able to deal with input from clients even if no Spread messages are ready. That's why it was going to poll Spread for messages while using the mutiplexing net I/O.)
        It does sound like you have to do your own event loop then, if you want to be able to catch Spread events even when there is no action to or from the clients. I don't see any obvious way to make this work with Net::Server::Multiplex. Maybe POE would be more appropriate.
Re: Using Net::Server::Multiplex and polling Spread
by NetWallah (Canon) on Jul 04, 2004 at 17:58 UTC
    It sounds like you are trying to accomodate 2 different protocols into a single program.

    You can simplify your solution space by declaring one of them to be primary - in this case, it sounds like you want to use N:S:M as primary. This becomes your primary program (Server). Now, if you write a N:S:M client that talks the SPread protocol (which I know nothing about), it looks just like a client to N:S:M, and is dedicated to speaking Spread.

        Earth first! (We'll rob the other planets later)