Hi all,
Can I close a port opened by some other process using sb-bsd-sockets?
For example, if I open a passive port using SBCL (or by any other
process):
;;Assume I have created a socket instance 's'
(sb-bsd-sockets:socket-bind s #(127 0 0 1)
port)
(sb-bsd-sockets:socket-listen s 5)
and the port does not close cleanly at the end of the program, can I
free up that port using functions in sb-bsd-sockets?
Thanks...
Deech
On Mon, 15 Oct 2007 16:06:34 -0000, deech <············@gmail.com>
wrote:
>Can I close a port opened by some other process using sb-bsd-sockets?
>For example, if I open a passive port using SBCL (or by any other
>process):
>
>;;Assume I have created a socket instance 's'
>(sb-bsd-sockets:socket-bind s #(127 0 0 1)
>port)
>(sb-bsd-sockets:socket-listen s 5)
>
>and the port does not close cleanly at the end of the program, can I
>free up that port using functions in sb-bsd-sockets?
Your process can only close its own handles. If the port is being
shared between processes, it will remain open as long as any of the
processes holds a handle to it.
George
--
for email reply remove "/" from address
On Oct 16, 9:16 pm, George Neuner <·········@/comcast.net> wrote:
> On Mon, 15 Oct 2007 16:06:34 -0000, deech <············@gmail.com>
> wrote:
>
> >Can I close a port opened by some other process using sb-bsd-sockets?
> >For example, if I open a passive port using SBCL (or by any other
> >process):
>
> >;;Assume I have created a socket instance 's'
> >(sb-bsd-sockets:socket-bind s #(127 0 0 1)
> >port)
> >(sb-bsd-sockets:socket-listen s 5)
>
> >and the port does not close cleanly at the end of the program, can I
> >free up that port using functions in sb-bsd-sockets?
>
> Your process can only close its own handles. If the port is being
> shared between processes, it will remain open as long as any of the
> processes holds a handle to it.
>
> George
> --
> for email reply remove "/" from address
Hi George,
If you insert a :
(sb-ext:gc :full t) ; gc as in garbage collector
; This code is courtesy of the sb-bsd-sockets test
code.
before any socket connection code it clears away old socket handles
and allows the new socket to connect.
Thanks for your reply!
Deech
On Mon, 22 Oct 2007 20:11:44 -0000, deech <············@gmail.com>
wrote:
>On Oct 16, 9:16 pm, George Neuner <·········@/comcast.net> wrote:
>> On Mon, 15 Oct 2007 16:06:34 -0000, deech <············@gmail.com>
>> wrote:
>>
>> >Can I close a port opened by some other process using sb-bsd-sockets?
>> >For example, if I open a passive port using SBCL (or by any other
>> >process):
>>
>> >;;Assume I have created a socket instance 's'
>> >(sb-bsd-sockets:socket-bind s #(127 0 0 1)
>> >port)
>> >(sb-bsd-sockets:socket-listen s 5)
>>
>> >and the port does not close cleanly at the end of the program, can I
>> >free up that port using functions in sb-bsd-sockets?
>>
>> Your process can only close its own handles. If the port is being
>> shared between processes, it will remain open as long as any of the
>> processes holds a handle to it.
>>
>> George
>> --
>> for email reply remove "/" from address
>
>Hi George,
>If you insert a :
>(sb-ext:gc :full t) ; gc as in garbage collector
> ; This code is courtesy of the sb-bsd-sockets test
>code.
>
>before any socket connection code it clears away old socket handles
>and allows the new socket to connect.
>
>Thanks for your reply!
>Deech
Okay, now I understand the problem.
There is a delay between the time the socket is closed and when its
resources are released. It's fairly expensive to set up a TCP address
context, so the OS keeps it for a while after the last socket using it
is unbound. An address context is created when the first socket is
bound. The problem is, a new socket being bound to an already
existing address context is treated as a multiple binding ... even if
there are no other sockets using it.
The right solution is to set SO_REUSEADDR on your listen socket before
you bind it. Your solution using GC may or may not be either reliable
or portable - the problem is in the OS's TCP implementation and
whether any Lisp can clean it up depends on the socket library and how
it interfaces to the OS.
George
--
for email reply remove "/" from address
George Neuner <·········@/comcast.net> wrote:
+---------------
| The right solution is to set SO_REUSEADDR on your listen socket before
| you bind it. Your solution using GC may or may not be either reliable
| or portable - the problem is in the OS's TCP implementation and
| whether any Lisp can clean it up depends on the socket library and how
| it interfaces to the OS.
+---------------
Yup. I've run into this one before myself. Fortunately, the CMUCL
socket stuff -- and thus one would assume "sb-bsd-sockets" as well --
provides a :REUSE-ADDRESS keyword on the CREATE-INET-LISTENER function.
Just set it to T, and it will do the proper "setsockopt()" on the
"listen()" file descriptor for you.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Oct 23, 4:39 am, ····@rpw3.org (Rob Warnock) wrote:
> George Neuner <·········@/comcast.net> wrote:
> +---------------
> | The right solution is to set SO_REUSEADDR on your listen socket before
> | you bind it. Your solution using GC may or may not be either reliable
> | or portable - the problem is in the OS's TCP implementation and
> | whether any Lisp can clean it up depends on the socket library and how
> | it interfaces to the OS.
> +---------------
>
> Yup. I've run into this one before myself. Fortunately, the CMUCL
> socket stuff -- and thus one would assume "sb-bsd-sockets" as well --
> provides a :REUSE-ADDRESS keyword on the CREATE-INET-LISTENER function.
> Just set it to T, and it will do the proper "setsockopt()" on the
> "listen()" file descriptor for you.
No, sb-bsd-sockets is an SBCL binding to the BSD Sockets API, it has
nothing to do with the CMUCL sockets layer/mess. Rob, you need to
quit posting things like "CMUCL, and thus I assume 'SBCL', does it
this way". It's getting to be a loud source of misinformation. I
know you're trying to be helpful, but unless you get a better idea of
where CMUCL and SBCL share common history, where they diverged, and
where they converged, you'll only spread confusion. As another
example, the SBCL threading facility is real native threads, written
from the ground up, and has nothing whatsoever to do with the horrid
MP package in CMUCL.
Thomas F. Burdick <········@gmail.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > ...CMUCL socket stuff -- and thus one would assume "sb-bsd-sockets"...
|
| No, sb-bsd-sockets is an SBCL binding to the BSD Sockets API, it has
| nothing to do with the CMUCL sockets layer/mess. Rob, you need to
| quit posting things like "CMUCL, and thus I assume 'SBCL', does it
| this way". It's getting to be a loud source of misinformation.
+---------------
O.k., I'll try to be more careful about that in the future.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
George Neuner <·········@/comcast.net> writes:
>
> Okay, now I understand the problem.
>
> There is a delay between the time the socket is closed and when its
> resources are released. It's fairly expensive to set up a TCP address
> context, so the OS keeps it for a while after the last socket using it
> is unbound. An address context is created when the first socket is
> bound. The problem is, a new socket being bound to an already
> existing address context is treated as a multiple binding ... even if
> there are no other sockets using it.
>
> The right solution is to set SO_REUSEADDR on your listen socket before
> you bind it. Your solution using GC may or may not be either reliable
> or portable - the problem is in the OS's TCP implementation and
> whether any Lisp can clean it up depends on the socket library and how
> it interfaces to the OS.
Wouldn't the Right Solution be for the Lisp implementation to abstract
away the differences between OSes, perhaps with some low-level
fiddliness for where an app author really _does_ want to meddle with the
low-level stuff? Just MHO.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Any time you catch yourself thinking that your life might be empty and
pointless, just meditate for a minute or two on the concept 'Paris
Hilton fan.' That should set you straight. --John Derbyshire
Robert Uhl <·········@NOSPAMgmail.com> writes:
> George Neuner <·········@/comcast.net> writes:
>>
>> Okay, now I understand the problem.
>>
>> There is a delay between the time the socket is closed and when its
>> resources are released. It's fairly expensive to set up a TCP address
>> context, so the OS keeps it for a while after the last socket using it
>> is unbound. An address context is created when the first socket is
>> bound. The problem is, a new socket being bound to an already
>> existing address context is treated as a multiple binding ... even if
>> there are no other sockets using it.
>>
>> The right solution is to set SO_REUSEADDR on your listen socket before
>> you bind it. Your solution using GC may or may not be either reliable
>> or portable - the problem is in the OS's TCP implementation and
>> whether any Lisp can clean it up depends on the socket library and how
>> it interfaces to the OS.
>
> Wouldn't the Right Solution be for the Lisp implementation to abstract
> away the differences between OSes, perhaps with some low-level
> fiddliness for where an app author really _does_ want to meddle with the
> low-level stuff? Just MHO.
This is what Allegro CL does. See
http://www.franz.com/support/documentation/8.1/doc/operators/socket/make-socket.htm
and search for :reuse-address, finding it in the sections for
both :address-family :internet :type :stream and :type :datagram.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Wed, 24 Oct 2007 08:43:01 -0600, Robert Uhl
<·········@NOSPAMgmail.com> wrote:
>George Neuner <·········@/comcast.net> writes:
>>
>> Okay, now I understand the problem.
>>
>> There is a delay between the time the socket is closed and when its
>> resources are released. It's fairly expensive to set up a TCP address
>> context, so the OS keeps it for a while after the last socket using it
>> is unbound. An address context is created when the first socket is
>> bound. The problem is, a new socket being bound to an already
>> existing address context is treated as a multiple binding ... even if
>> there are no other sockets using it.
>>
>> The right solution is to set SO_REUSEADDR on your listen socket before
>> you bind it. Your solution using GC may or may not be either reliable
>> or portable - the problem is in the OS's TCP implementation and
>> whether any Lisp can clean it up depends on the socket library and how
>> it interfaces to the OS.
>
>Wouldn't the Right Solution be for the Lisp implementation to abstract
>away the differences between OSes, perhaps with some low-level
>fiddliness for where an app author really _does_ want to meddle with the
>low-level stuff? Just MHO.
It's not a difference to be abstracted away. When you bind a socket
with the SO_REUSEADDR flag set, the bind call won't fail if the
address/port combo is already in use by another process. If you
aren't careful, you may interfere with another program's
communication. SO_REUSEADDR isn't for general use - it is for
services that must be quickly restarted in the event of a crash.
George
--
for email reply remove "/" from address