Very interesting. After only reading your nutshell descriptions, to me
what would seem like a nice way of handling this is lightweight plumbing
in C and the bulk in Tcl. Example:
Create a socket driver that, on connection to it's IP/port, gets an
interpreter thread and in it runs the procedure configured for it, ie:
proc smtp {in out from_addr args} {smtp code}
When the proc exits, the connection closes and, just like HTTP, the
interpreter is cleaned up a bit and put back in the pool.
This would make it easy to implement any protocol you want, possibly using
expect. It could make nsd a very interesting core for building any
client/server apps.
Just my $0.02!
Bas.
Zoran Vasiljevic said:
> Hi!
>
> I would like to start a discussion which will eventually lead
> to one of the two proposals listed below (one from Vlad Seryakov and the
other from Stephen Deasey) included in the core-server
> distribution.
>
> Both proposals look promising and both allow us to add support
> for arbitrary protocols (pop, imap, ftp...) to the AS, augmeting the
existing (built-in) http protocol.
>
> Vlad Seryakov's patch can be found on:
> http://sourceforge.net/tracker/index.php?func=detail&aid=726288&group_id=3152&atid=353152
>
> In a nutshell:
> Vlad's patch implements entirely new socket-level driver and sticks the
whole add-in functionality in the driver itself, effectively bypassing
the AS socket and/or ssl driver. It is minimaly invasive in terms of
core-server changes as it puts all of the new protocol parsing logic
into the driver itself.
>
>
> Stephen Deasey's patch can be found on:
> http://sourceforge.net/tracker/index.php?func=detail&aid=973010&group_id=3152&atid=353152
>
> In a nutshell:
> Stephen's patch integrates into the AS by adding new API call
> Ns_RegisterParseProc() which allows module authors to register a proc
which will be called by the driver thread to parse the data from a
connection socket. This way a new protocol connect handling looks pretty
much like regular http. Hence it utilitzes all of the recent
optimizations in the core (read-aead threads, async-reads) and runs
atop existing sock and ssl drivers.
>
>
> My personal opinion is that Stephen's patch is more versatile in the way
it integrates with other AS components. It brings more
> options to the protocol developer. It is relatively simple, not
> too invasive and I would vote we integrate this patch into the
> 4.1+ dvelopment branch.
>
> So, all of you interested in extending AS to handle non-http
> protocols, please go, have a look and give some feedback.
>
> Thanks,
> Zoran
>
>
> --
> 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.
