AOL Webserver - connected socket pool

Author

connected socket pool

John Buckman

2006-09-07, 1:11 am

I'd like to keep a permanently connected socket connection to another
machine, with each aolserver thread having a socket that is already
connected to that other app.

I tried using the namespace trick to keep a global around, like so:

namespace eval sbuff {}
proc mysockget {} {
global sbuff:mysock
if {[info exists mysock] == 1} {
return $mysock
}
set mysock [socket localhost 9999]
}

but while the socket descriptor stays around with this trick,
aolserver automatically closes the socket itself. This must be some
sort of cleanup code in aolserver, normally a good thing.

Is there a way to either:
1) have my socket NOT be cleaned up by aolserver
2) have a connected socket pool, like nsdb, but w/o any functionality
other than a connected socket

I'm not alone with this need, I know that Rusty needs to do this too,
and lots of tcpip socket protocols have login steps, that cause a new-
connection-per-adp-page strategy to be inefficient.

-john

Michael A. Cleverly

2006-09-07, 7:11 am

On 9/6/06, John Buckman <john@magnatune.com> wrote:
> I'd like to keep a permanently connected socket connection to another
> machine, with each aolserver thread having a socket that is already
> connected to that other app.
>
> I tried using the namespace trick to keep a global around, like so:
>
> namespace eval sbuff {}
> proc mysockget {} {
> global sbuff:mysock
> if {[info exists mysock] == 1} {
> return $mysock
> }
> set mysock [socket localhost 9999]
> }
>
> but while the socket descriptor stays around with this trick,
> aolserver automatically closes the socket itself. This must be some
> sort of cleanup code in aolserver, normally a good thing.
>
> Is there a way to either:
> 1) have my socket NOT be cleaned up by aolserver
> 2) have a connected socket pool, like nsdb, but w/o any functionality
> other than a connected socket
>
> I'm not alone with this need, I know that Rusty needs to do this too,
> and lots of tcpip socket protocols have login steps, that cause a new-
> connection-per-adp-page strategy to be inefficient.

This does seem like a very useful feature to have...

The code that closes the socket is ns_cleanupchans defined in
nsd/init.tcl (in the 4.5 source distribution). It is called by
ns_cleanup. You could modify your ns_cleanupchans to ignore (in
addition to the stdin/stdout/stderr channels it already ignores) the
chan in your sbuf::mysock variable. I.e., something like:

proc ns_cleanupchans {} {
ns_chan cleanup; # close shared channels first
set except ""
if {[info exists ::sbuf::mysock]} {
set except $::sbuf::mysock
}
foreach f [file channels] {
# NB: Leave core Tcl stderr, stdin, stdout open.
if {![string match std* $f]} {
if {$f != $except} {
catch {close $f}
}
}
}
}

Michael

Rusty Brooks

2006-09-07, 1:11 pm

I'd like to see this as a feature of AOLServer... being able to mark a
channel as do-not-cleanup.

Rusty

Michael A. Cleverly wrote:
> On 9/6/06, John Buckman <john@magnatune.com> wrote:
>
> This does seem like a very useful feature to have...
>
> The code that closes the socket is ns_cleanupchans defined in
> nsd/init.tcl (in the 4.5 source distribution). It is called by
> ns_cleanup. You could modify your ns_cleanupchans to ignore (in
> addition to the stdin/stdout/stderr channels it already ignores) the
> chan in your sbuf::mysock variable. I.e., something like:
>
> proc ns_cleanupchans {} {
> ns_chan cleanup; # close shared channels first
> set except ""
> if {[info exists ::sbuf::mysock]} {
> set except $::sbuf::mysock
> }
> foreach f [file channels] {
> # NB: Leave core Tcl stderr, stdin, stdout open.
> if {![string match std* $f]} {
> if {$f != $except} {
> catch {close $f}
> }
> }
> }
> }
>
> Michael
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the
> Subject: field of your email blank.

Zoran Vasiljevic

2006-09-07, 1:11 pm

On 07.09.2006, at 16:36, Rusty Brooks wrote:

> I'd like to see this as a feature of AOLServer... being able to
> mark a channel as do-not-cleanup.

You can open a (tcl) channel in one thread, then detach it from the
interpreter/thread and re-use (i.e. attach) it into some other thread.
The only limitation is: only one therad/interp can access the
channel at a time.

Look at the [ns_chan] command for more information.

Cheers,
Zoran

Tom Jackson

2006-09-07, 1:11 pm

John,

I tried to do this once, for similar reasons. When a connection closes, all
open files are closed. I'm not sure of any better way to run the server: if
you don't have automatic code closing open files, then you run the risk of an
error leaving your file open, and then you might screw up future use of that
file from the other threads. I don't think it is the variable which
references the socket which is necessarily lost, but the open file itself.
(Otherwise you could just save the file reference in an nsv, or like you did
with a namespace var.)

The way to do this now is with nsproxy, but I haven't used it yet, so I can't
offer much in the way of details or limitations.

I think I remember looking at another potential method: named pipes, or
another method of IPC. But none are out of the box supported, but some form
of pipe is in the AOLserver C library.

I was hoping that the nsdci module would include some better tools for this,
but just guessing.

tom jackson

On Wednesday 06 September 2006 21:58, John Buckman wrote:
> I'd like to keep a permanently connected socket connection to another
> machine, with each aolserver thread having a socket that is already
> connected to that other app.
>
> I tried using the namespace trick to keep a global around, like so:
>
> namespace eval sbuff {}
> proc mysockget {} {
> global sbuff:mysock
> if {[info exists mysock] == 1} {
> return $mysock
> }
> set mysock [socket localhost 9999]
> }
>
> but while the socket descriptor stays around with this trick,
> aolserver automatically closes the socket itself. This must be some
> sort of cleanup code in aolserver, normally a good thing.
>
> Is there a way to either:
> 1) have my socket NOT be cleaned up by aolserver
> 2) have a connected socket pool, like nsdb, but w/o any functionality
> other than a connected socket
>
> I'm not alone with this need, I know that Rusty needs to do this too,
> and lots of tcpip socket protocols have login steps, that cause a new-
> connection-per-adp-page strategy to be inefficient.
>
> -john
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the
> email message. You can leave the Subject: field of your email blank.

Dossy Shiobara

2006-09-07, 1:11 pm

On 2006.09.07, Rusty Brooks <me@RUSTYBROOKS.COM> wrote:
> I'd like to see this as a feature of AOLServer... being able to mark a
> channel as do-not-cleanup.

I honestly don't think this is what you really want.

Please look at [ns_chan] --

http://panoptic.com/wiki/aolserver/Ns_chan

-- Dossy

--
Dossy Shiobara | dossy@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

Rusty Brooks

2006-09-07, 1:11 pm

Dossy Shiobara wrote:
> On 2006.09.07, Rusty Brooks <me@RUSTYBROOKS.COM> wrote:
>
>
> I honestly don't think this is what you really want.
>
I think it probably is. Why don't you think so? My goal is to open one
channel per thread and not have it close, until I tell it to.
> Please look at [ns_chan] --
>
> http://panoptic.com/wiki/aolserver/Ns_chan
>
I'll check it out. But the other thing is way too easy not to try.

Regarding Tom Jackson's comments, naturally you don't want EVERY file
handle you use to stick around. But there are special cases where I do.

Rusty

Dossy Shiobara

2006-09-07, 1:11 pm

On 2006.09.07, Rusty Brooks <me@RUSTYBROOKS.COM> wrote:
> I think it probably is. Why don't you think so? My goal is to open one
> channel per thread and not have it close, until I tell it to.

Can any request from any user use any previously opened channel? i.e.,
is the channel's use stateless? Or, is it stateful (i.e., tied to a
user session)?

If it's stateful, then you need to be able to "get back to" that
previously opened channel regardless of which connection thread happens
to handle your request. This is what "ns_chan" is particularly useful
for.

-- Dossy

--
Dossy Shiobara | dossy@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

Tom Jackson

2006-09-07, 1:11 pm

Instead of trying to give additional advice on this subject, I'll just make an
observation: most of us are here to discuss how to use AOLserver, not how to
introduce more bugs.

tom jackson

On Thursday 07 September 2006 08:13, Rusty Brooks wrote:
> Dossy Shiobara wrote:
>
> I think it probably is. Why don't you think so? My goal is to open one
> channel per thread and not have it close, until I tell it to.
>
>
> I'll check it out. But the other thing is way too easy not to try.
>
> Regarding Tom Jackson's comments, naturally you don't want EVERY file
> handle you use to stick around. But there are special cases where I do.
>
> Rusty
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the
> email message. You can leave the Subject: field of your email blank.

Rusty Brooks

2006-09-07, 1:11 pm

It's stateless. Think of it like a database connection. AOLServer just
needs to pipe commands to this channel and get results back.

Rusty

Dossy Shiobara wrote:
> On 2006.09.07, Rusty Brooks <me@RUSTYBROOKS.COM> wrote:
>
>
> Can any request from any user use any previously opened channel? i.e.,
> is the channel's use stateless? Or, is it stateful (i.e., tied to a
> user session)?
>
> If it's stateful, then you need to be able to "get back to" that
> previously opened channel regardless of which connection thread happens
> to handle your request. This is what "ns_chan" is particularly useful
> for.
>
> -- Dossy
>
>

Dossy Shiobara

2006-09-07, 1:11 pm

On 2006.09.07, Rusty Brooks <me@RUSTYBROOKS.COM> wrote:
> It's stateless. Think of it like a database connection. AOLServer just
> needs to pipe commands to this channel and get results back.

Then, I'd try the suggestion of replacing ns_cleanupchans with your own
version that doesn't auto-close channels you want to preserve.

How to best implement that in general in the core AOLserver code will
benefit from any feedback you give based on your implementation and
experiences.

Let us know if/how it works for you,

-- Dossy

--
Dossy Shiobara | dossy@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

Rusty Brooks

2006-09-07, 1:11 pm

Thankfully, it's open source, and I can introduce more bugs to my hearts
content!

Rusty

Tom Jackson wrote:
> Instead of trying to give additional advice on this subject, I'll just make an
> observation: most of us are here to discuss how to use AOLserver, not how to
> introduce more bugs.
>
> tom jackson
>
>
>
> On Thursday 07 September 2006 08:13, Rusty Brooks wrote:
>
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <listserv@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
>

Rusty Brooks

2006-09-07, 1:11 pm

OK, I gave it a shot. I'm still going to look at the ns_chan info but
for now this will work. I'm trying to cobble together a
proof-of-concept to switch parts of our product from tclhttpd to
aolserver, and so I need something that works, this week, no matter what.

I would not implement it in aolserver core how I did it, which was to
nsv_lappend to a variable any channels that I wish to not have cleaned up.
My ns_cleanup chan lsearches that list before closing a channel, and if
the chan it's considering closing is in the list, it just skips it,
like it does for stdout etc.

Dossy Shiobara wrote:
> On 2006.09.07, Rusty Brooks <me@RUSTYBROOKS.COM> wrote:
>
>
> Then, I'd try the suggestion of replacing ns_cleanupchans with your own
> version that doesn't auto-close channels you want to preserve.
>
> How to best implement that in general in the core AOLserver code will
> benefit from any feedback you give based on your implementation and
> experiences.
>
> Let us know if/how it works for you,
>
> -- Dossy
>
>

Gustaf Neumann

2006-09-09, 7:11 am

Hi Rusty,

Last year i implemented what i think you are looking for for the
aolserver. In essence,
the changes allow for a synchronous delivery of files. We use this (in
production on a
server with up to 4mio requests per day) for two purposes:

- background delivery of files (a connection thread can finish as soon the
asynchronous delivery starts; so multiple deliveries of e.g. large files
over slow lines dont do a DDOS "attack" to your system)

- chat (in combination with ajax): The same infrastructure can be used
for pushing (and broadcasting) information to multiple users connecting
to the aolserver (via ajax). Instead of using e.g. a polling chat
package,
the clients keep an open connection to which we can broadcast).

the asynchrounous delivery requires a small patch (2 changes, one is a
backport from naviserver)
and the tcl thread library (by zoran). The application code is in
Tcl/XOTcl is only a few lines of code.
And is included in the CVS of OpenAcs.

This is described in
http://media.wu-wien.ac.at/download.../xotcl-apm.html where the
version numbers are outdated. get the actual code from cvs, not the apm
packages. The file contains as well the description for installing
libthread as well...

best regard
-gustaf neumann