[Xitami] LRWP

[Ewen McNeill]

In message <011c01c1d91b$85c96fc0$dd31200a@JAZZ>, "Norman Makoto Su" writes:
>Would you mind explaining what you mean by "just open multiple connections"?
>I'm not sure why its all in one process-- don't you have to run multiple LRWP
>peers (each which have their own memory space, etc)?  I think I'm
>misunderstanding something.

The original question was whether a LRWP peer could handle multiple
requests simultaneously (ie, overlapping), to which my response was
"just open multiple connections" (there is only one request at a time per
connection).

You can achieve the multiple connections by running multiple instances
of the LRWP peer (ie, multiple processes), and that'll work fine.  But
if the LRWP instances need to share data then they'll have to do it via
a database (common technique), or via shared memory, a private
connection, etc.

If you want to avoid the overhead of reading/writing to a database, and
the hassle of shared memory code (particularly portable shared memory
code), then you could simply write a LRWP peer that opens multiple
sockets connected to Xitami, and registers itself on each one.  As far
as Xitami is concerned it's multiple LRWP peers, and they'll be used in
a round-robin fashion (or in a first-available fashion; depending on how
Xitami is configured).

There are basically three ways to handle the "multiple
connections/requests in one process" situation:
- OS level threading (kernel or system library threading)
- select()-style loops
- SMT

While you can do select()-style loops by hand, the design will rapidly
drive you nuts if it is of any size.  SMT allows you to abstract the
design further, and gives you "thread-like" execution of the
select()-style loop handling.

The important thing to remember is that as far as Xitami is concerned,
LRWP peers are just a socket connection to it, that has registered.  It
doesn't know anything else about them, and it doesn't care.  It just
sends them requests to be handled across the socket, one request per
socket.

Ewen

-- 
Ewen McNeill, Technical Consultant, iMatix Corporation  www.imatix.com