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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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 a
n
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.

[ Post a follow-up to this message ]

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)

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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)

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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
>
>

[ Post a follow-up to this message ]