We did write that @ KnowNow.  To do so, we added an API to nsd at the C
level (which may be in the 3.4 codebase; it was submitted for
consideration [Ns_PersistentMark()/Ns_PersistentClose()]), which allows
a module to "take control" of a  socket previously attached to a
connection thread.  We then use SEDA pattern (worker/queue) pattern to
serve these sockets, this time in C++.

Then we made sure we could serve loads of mostly-idle  sockets by
wrapping the appropriate large-scale socket APIs for the platforms
(e.g., Windows I/O completion ports).

And, of course, we had to provide APIs for sending stuff down those
sockets in formats that the far end could handle well.

Not a whole lot different from what you'd do if you were doing a video
server or other streaming server, really.

Oh, until we provided a scheme for re-establishing sessions without
losing asynchronous events when connections -- or nodes in clusters --
fail.

Pretty fair amount of code, but it's really easy to use once you've
bought it from us :-)

-- ReC
-----Original Message-----
From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf
Of Bas Scheffers
Sent: Monday, March 27, 2006 4:30 AM
To: [email protected]
Subject: Re: [AOLSERVER] Can Aolserver do Comet

To repeat Dossy: wow, they came with a cool new name for something old!
:)

That said: in principle, AOLserver is perfectly able to do this as it
has the ability to just keep the connection open for as long as you like
and stream the data. You should be thinking of a registered proc or .tcl
file using ns_write.

But... Every connection would take up a thread, even if it is idle.
Having 1000 simultanious users might be a bit of an issue for any
standard web server.

Say you have a chatroom application. In an ideal world you would be
using non-blocking IO for this; all the clients are connected and a list
of all the connections subscribed to the chat channel is kept. Someone
posts (using AJAX) to the channel and the handling thread simply steps
through all the connections and sends the message to each client.

An architecture like that would scale very well, but AOLserver couldn't
do it out of the box. I am not sure how much effort it would be the
write it.
You are probably looking at writing a module that does all of it and
exposes some Tcl commands to send messages to clients.

Hope that helps!

Bas.

Hamilton Chua said:
> I read a recent article about something that could be the next buzz 
> word after Ajax and Mashups.
>
> http://www.irishdev.com/NewsArticle.aspx?id=2166
>
> What I would like to find out more about what the article is talking 
> about "event driven IO" in the context of AOLServer.
>
> Does anyone know of a module in aolserver that supports this or are 
> there currently plans to build this "abstraction".
>
> Thanks !
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to 
> <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in 
> the email message. You can leave the
> Subject: field of your email blank.
>


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the
email message. You can leave the Subject: field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to