Now, now...that is unfair. I was referring to writing in pure Perl vs pure
Java.
Of course, C apis and pre-written daemon integration makes the glue
language a moot point (and favors Perl actually).
BTW, is select() is still broken in Win32 Perl? It was 6 months ago (I
suspect because IO operates differently on win32) so you'd limit your
platform too.
Later,
Gunther
At 06:21 PM 6/12/00 +0000, Shane Nay wrote:
>(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.
>
>--
>
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
