(Somehow I missed Gunther's message, maybe I had a system out for a little
while, I'm replying to Roger, but really replying to Gunther)
On Mon, 12 Jun 2000, you wrote:
> Gunther Birznieks <[EMAIL PROTECTED]> wrote:
> > 2. Would you write a chat engine in Perl? I wouldn't! (Well, actually I did
> > 5 years ago but I am certainly not proud of that code).
Hmm..., yes I would. At this point, long before I would write it in Java. You
know why? Not because of anything in perl necessarily, but actually what you
can do with perl. You see, a perl XS module can take advantage of anything
inside of C. If I were to write a new version of the chat engine I wrote, I
wouldn't do it this way. In fact I started re-writing it based on a sigqueues,
and CORBA. Corba pre-fetch of everything running around, dump into memory,
sigqueues pick up request from client via httpd protocol (obviously not port
80, this is a special purpose HTTPD engine). Stream out based on pre-fetched
CORBA content. I started writing it, but got distracted by the fact that I ran
out of money :-), happens to the best of us.
Java can talk to Corba natively, so the application side talks to the corba
server, and dumps/retrieves it's messages into there. Two threads involved in
the special purpose httpd engine. One that fetches content from the CORBA
engine, the other that streams out to clients based on sigqueus (Similar to
phhttpd, but much simpler). The locking issues on the Corba content is so
yucky I don't even want to discuss it (That's sort of where I left off). I ran
some benchmarks, and the httpd engine could handle over 1000 requests per
second per server. The corba fetch was really trivial, so the only "problem"
was the communication between the applications and omniORB (Corba Object
Request Broker, really good piece of software BTW, best ORB out there in terms
of speed)
>
> I did, just a few months ago, and it's working very nicely.
>
> > The thing about a real-time chat engine is the same issue as #1, it is
> > really inefficient resource-wise to flush messages to a persistent data
> > store or even using IPC shared memory in Perl in order to allow all the
> > Perl processes to share a common list of chat messages even if only for the
> > last 5 minutes worth of chat.
>
> So don't do it like that :) My chat engine is a single-threaded,
> select()-based plain Perl daemon (no apache there) that takes http
> connections on a non-standard port, directly from the browser, and keeps
> them open for as long as the browser will. It speaks http on one end,
> and uses the irc-server-to-server protocol to talk to an ircd on the
> other.
Well, yes that's the easiest way to do it with perl. The other way is to write
some XS modules which plug into an sigqueue engine, and handle it that way.
Honestly though, if you're going to be writing XS modules to talk to signal
queues, you might as well write the damn thing in c :-).
> Technically, yeah, select() is arguably ugly, but if you wrap it around
> OO classes for the various kinds of buffers and connections, it's all
> quite manageable.
Select might be ugly, but it's how nearly every realtime system works. So if
you want a realtime system you need to look into select, poll (ugh), and
sigqueues.
> Chat connections are very low bandwith, and a single-threaded design
> tends to be memory effective, so I'd expect this setup to handle a few
> hundred simultaneous users easily. If you want more, use a standard irc
> daemon as a hub, and connect several such perl servers to it; if you
> want to have a java applet client too, it can talk directly to the irc
> server.
Nothing could be more true. Single thread is the ONLY way to go..., anything
other than that is a massive waste of trying to implement.
Thanks,
Shane.
--
