Detect closed socket on Client side
bla...@gmail.com
I have a simple client/server tcl program going but am having an
issue detecting when the server has died and closing the client side
nicely. Is there a fileevent or a test I can do that will tell me if
my client socket has been closed because of an error or the server
disconnecting me? Currently, my program crashes (obviously) when I do:
puts $mySock $myCommand
if $mySock has been closed.
I suppose I could catch the puts, but was wondering if there was a
better way?
Thank you!
Darren New
> I suppose I could catch the puts, but was wondering if there was a
> better way?
There is, in general, no reliable way on the Internet to detect that a
connection is broken without trying to send something. If the server
cleanly closes the socket out from under you, there may be something you
can do. But if the server crashes, loses power, or something between you
and the server stops forwarding packets, you won't know except that your
[puts] fails to go through.
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Alexandre Ferrieux
On Dec 5, 10:43 pm, "bla...@gmail.com" <bla...@gmail.com> wrote:
> Is there a fileevent or a test I can do that will tell me if
> my client socket has been closed because of an error or the server
> disconnecting me?
Your first encounter with the connection's being closed if through a
[puts]; I guess this happens because you didn't get a chance to detect
the EOF before. This is normal if you don't ever read from this socket,
or even if you do but only at specific times and do blocking things in
between.
But since you mention [fileevent], you know event-driven programming,
hence you may find it useful to register a "readable" fileevent:
fileevent $sok readable [list gotsok $sok]
proc gotsok ch {
if {[gets $ch line]<0} {close $ch;do_some_cleanup}
}
This way, although you're not interested in what $sok has to say (and
it may not say a word of its entire life), you'll be notified
immediately of its fate.
Now of course, this assumes there is a frank teardown of the
connection. If the server only half-closes the direction from client to
server (with the shutdown() syscall), then clearly there will be no
EOF, and you'll have to catch the [puts].
bla...@gmail.com
Fredderic
Darren New <dn...@san.rr.com> wrote:
> bla...@gmail.com wrote:
> > I suppose I could catch the puts, but was wondering if there was a
> > better way?
> There is, in general, no reliable way on the Internet to detect that
> a connection is broken without trying to send something. If the
> server cleanly closes the socket out from under you, there may be
> something you can do. But if the server crashes, loses power, or
> something between you and the server stops forwarding packets, you
> won't know except that your [puts] fails to go through.
Just out of curiosity, does TCL set keepalive on socket connections?
As I understand it, keepalive periodically pokes an inactive connection
to make sure it's still there (and let the other end know it's still
wanted). If it finds the connection has disappeared (eg. a network
cable has been ripped out by the janitor), you'll get an EOF on the
readable fileevent.
Frederic
Darren New
> Just out of curiosity, does TCL set keepalive on socket connections?
I think TclX supports setting it, or at least used to. I'm not sure it
used a fileevent to signal a broken connection, tho.
It also doesn't help for listener sockets, which is where I tend to have
trouble.
Uwe Klein
> Fredderic wrote:
>
>> Just out of curiosity, does TCL set keepalive on socket connections?
>
>
> I think TclX supports setting it, or at least used to. I'm not sure it
> used a fileevent to signal a broken connection, tho.
>
> It also doesn't help for listener sockets, which is where I tend to have
> trouble.
>
...
fcntl fileId attribute ?value?
This command either sets or clears a file option or returns its
current value. If value is not specified, then the current
value of attribute is returned. All values are boolean. Some
attributes maybe only be gotten, not modified. The following
attributes may be specified:
.........
KEEPALIVE
Keep a socket connection alive. If SIGPIPE is enabled, then it
is sent if connection is broken and data is written to the
socket. If SIGPIPE is ignored, an error is returned on the
write. This attribute is valid only on sockets. By default,
SIGPIPE is ignored in Tcl.
The NONBLOCK, NOBUF and LINEBUF are provided for compatibility
with older scripts. Thefconfigure command is preferred method
of getting and setting these attributes.
The APPEND and CLOEXEC options are not available on Windows
95/NT.
<end>
this fits in well with an idea i had sprouted to have "filevent error" type
handling.
uwe