Hi.

I have encountered a slight problem...it's Solaris 8, btw
I did the following:

1. Established one or more TCP sockets from a PC to a Solaris machine, where
the Solaris side has looping select-read's on them waiting for data.
2. Pulled the cable.

and when doing netstat on the Solaris machine, all the sockets are forever
in state 'ESTABLISHED'! Why?

/Fredrik

"Fredrik Lännergren" <fredrik_nospam_lannergren@yahoo.com> writes:

>I have encountered a slight problem...it's Solaris 8, btw
>I did the following:

>1. Established one or more TCP sockets from a PC to a Solaris machine, where
>the Solaris side has looping select-read's on them waiting for data.
>2. Pulled the cable.

>and when doing netstat on the Solaris machine, all the sockets are forever
>in state 'ESTABLISHED'! Why?

Because the connections are never closed; and as long as no data is send
and no keep alives are used, the connections will remain in ESTABLISHED
state *forever*.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

"Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
news:3f4f1ec6$0$49105$e4fe514c@news.xs4all.nl...
> "Fredrik Lännergren" <fredrik_nospam_lannergren@yahoo.com> writes:
>
> >I have encountered a slight problem...it's Solaris 8, btw
> >I did the following:
>
> >1. Established one or more TCP sockets from a PC to a Solaris machine,
where
> >the Solaris side has looping select-read's on them waiting for data.
> >2. Pulled the cable.
>
> >and when doing netstat on the Solaris machine, all the sockets are
forever
> >in state 'ESTABLISHED'! Why?
>
> Because the connections are never closed; and as long as no data is send
> and no keep alives are used, the connections will remain in ESTABLISHED
> state *forever*.

[possible repost, dunno what happened to the last one]

Ach... and here I thought select would notice the loss of link.
Ah well, SO_KEEPALIVE it is then.
Thanks for the quick reply :-).

/Fredrik

In article <bincm9$4c3$1@newstree.wise.edt.ericsson.se>,
"Fredrik Lännergren" <fredrik_nospam_lannergren@yahoo.com> writes:
>
> "Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
> news:3f4f1ec6$0$49105$e4fe514c@news.xs4all.nl...
>> "Fredrik Lännergren" <fredrik_nospam_lannergren@yahoo.com> writes:
>>
>> >I have encountered a slight problem...it's Solaris 8, btw
>> >I did the following:
>>
>> >1. Established one or more TCP sockets from a PC to a Solaris machine,
> where
>> >the Solaris side has looping select-read's on them waiting for data.
>> >2. Pulled the cable.
>>
>> >and when doing netstat on the Solaris machine, all the sockets are
> forever
>> >in state 'ESTABLISHED'! Why?
>>
>> Because the connections are never closed; and as long as no data is send
>> and no keep alives are used, the connections will remain in ESTABLISHED
>> state *forever*.
>
> [possible repost, dunno what happened to the last one]
>
> Ach... and here I thought select would notice the loss of link.
> Ah well, SO_KEEPALIVE it is then.
> Thanks for the quick reply :-).

Note that the default keepalive interval is something like two hours (up
to that long before it notices a dropped connection), and there's no way
(AFAIK) to adjust the interval on a per-program basis (only changing the
default for the entire system, usually _not_ a good idea). Keep-alives
are usually not the right answer; they really need to be done with an
application-level protocol (and even then may not be a good idea, since
it's a _feature_ not a bug that a connection can be disrupted for at
least a couple of minutes and then keep right on going; the only problem
being that the receiver may take much longer (or forever) to give up).
I'd say you need to dig out the TCP docs to determine how long it would
be before the sender would probably give up (I forget how you figure that
out) and have the receiver (or receiver system-wide keepalive defaults)
at least twice that long, so that you'll never give up unnecessarily.

I would think it would be fairly easy to find a discussion of such matters,
either on the web or in Steven's TCP books.


--
mailto:rlhamil@mindwarp.smart.net http://www.smart.net/~rlhamil

"Richard L. Hamilton" <Richard.L.Hamilton@mindwarp.smart.net> wrote in
message news:vkugrrqoghjpf3@corp.supernews.com...
*snip*
> Note that the default keepalive interval is something like two hours (up
> to that long before it notices a dropped connection), and there's no way
> (AFAIK) to adjust the interval on a per-program basis (only changing the
> default for the entire system, usually _not_ a good idea). Keep-alives
> are usually not the right answer; they really need to be done with an
> application-level protocol (and even then may not be a good idea, since
> it's a _feature_ not a bug that a connection can be disrupted for at
> least a couple of minutes and then keep right on going; the only problem
> being that the receiver may take much longer (or forever) to give up).
> I'd say you need to dig out the TCP docs to determine how long it would
> be before the sender would probably give up (I forget how you figure that
> out) and have the receiver (or receiver system-wide keepalive defaults)
> at least twice that long, so that you'll never give up unnecessarily.
>
> I would think it would be fairly easy to find a discussion of such
matters,
> either on the web or in Steven's TCP books.

Mmm, well, as long as it _does_ notice the connection loss for those
sockets, I'm happy. As it is, stray 'zombie' sockets are kept in a
limited-size list, preventing new connections from the same, now restarted,
source from establishing connections. Setting tcp_keepalive_interval is not
a problem, since our application is the only thing that runs on the machine.
I've tried with 15 minutes, and it looks like a reasonable number.

/Fredrik

In article <RkN3b.14738$_B.962656@twister.austin.rr.com>,
Logan Shaw <lshaw-usenet@austin.rr.com> writes:
> Fredrik Lännergren wrote:
>> Ach... and here I thought select would notice the loss of link.
>> Ah well, SO_KEEPALIVE it is then.
>
> Keep in mind that there may be many hops between "here" and
> "there". If someone pulls an ethernet wire out of one of these
> routers, how are the endpoints of the TCP connection going
> to know? Should that router broadcast to the entire Internet
> that the cable has been pulled, just in case? Or maybe to
> all the hosts that have sent a packet through it in the last
> 24 hours? :-)
>
> Also, what happens if someone changes a routing table to
> route around that router and then pulls the ethernet cable
> or flips the power switch? Packets will still be able to
> flow between the endpoints of the TCP connection, but the
> link over which the packet originally travelled is no
> longer there.
>
> In other words, because TCP/IP is packet-switched (and not
> circuit-switched), really the only practical solution to
> detecting whether the remote host is no longer "there" is
> to try and send a packet. If it gets there, great. If
> it doesn't, then does that mean the machine is crashed
> or disconnected, or does it mean that it's just really
> busy for the moment and/or there is network congestion?
> (Or that the network admin is in the wiring closet and
> in the process of moving several hosts to a new switch,
> and is thus yanking and re-plugging lots of ethernet
> cables?)
>
> So you can see why it must be handled at the application
> level. There is not enough information to always do
> the right thing; some applications (say, a backup to
> tape) want to wait hours for the remote host to start
> responding again, others want to give up more quickly.

....one reason why it would be really nice if there were a way to adjust
the frequency of tcp keepalives on a per-socket basis. (although I already
agreed that it really ought to be handled at the application level, that
would at least be much easier as a mod to existing code and/or where
app-level protocol couldn't handle it; just enable keepalives, set the
interval for the socket to override the system default, and be as sensible
about dealing with broken connections as one ought to be anyway)
If it were adjustable on a per-socket basis, there should be a systemwide
minimum interval that any request to set it lower than that would be
forced to, to prevent locally originated DoS.

--
mailto:rlhamil@mindwarp.smart.net http://www.smart.net/~rlhamil