Hi All:

Sorry in advance if this has been asked before, I've only been
looking at modules for a couple of weeks, but I checked
everywhere I could think of and I'm still looking for some answers.

I have a relatively high powered device on a network with a TCP
debug/status port. Users can telnet to this port, enter their credentials,
and tell the device to start spewing data at them. This particular
device outputs XML. Multiple users can connect to the device
simultaneously and each user has a different profile (list of events
they subscribe to). I'd like to put an apache web server on the network
and code up a module to create a web front end.

So far, this is what I'm thinking:
- User enters credentials, the module opens a socket to the device,
 passes along credentials, and holds the request_rec connection to
 the browser open ("comet" style streaming).
- Device passes back some administrative preamble and starts to stream
 data to the module, the module passes the chunks of xml to a filter
 which applies an XSLT transform to JS <script> chunks and the
 browser updates

If this is a plausible direction to go in, then my issue comes about when
a user wants to change their profile. On the browser, I open a 'back door'
XmlHttpRequest and send it, along with the session ID of the user. The
module must then find that session's connection to the device, signal the
module somehow, and tell it to pass the client request along to the device.

How would you guys go about coordinating the IPC here? A socket to the
device and a listening socket to listen for subscription changes on a
select?
Seems like a lot of overhead per user, plus I'd have to coordinate the
listening sockets to be on unique ports for each client, which would require
perhaps shared memory or the server pool. Perhaps shared memory and
signals? This is very MPM specific, though. It would also be nice to move
from a prefork MPM to the Event MPM to support more simultaneous users
in the future without a total overhaul.

Any input is appreciated. Thanks!

-Chris

Reply via email to