Re: Detecting network change
Re: Detecting network change
- Subject: Re: Detecting network change
- From: Greg <email@hidden>
- Date: Thu, 23 Oct 2008 19:42:13 -0400
On Oct 23, 2008, at 6:04 PM, Josh Graessley wrote:
This will fail eventually. I think there are a few reasons this
isn't handled.
The first is simply that the entire stack wasn't designed for the
dynamic environment we live in today. sockets were designed decades
ago, and considering how old they are, they do a good job. If you
don't give them a little leeway for being so old, sockets are pretty
crappy.
The second reason is that returning an error immediately breaks a
feature...or behavior that may have been more accidental than
intentional. If you were to wait for a read, your tcp socket will
maintain state indefinitely. If you picked up your laptop and took
it home then back to work the next day, the remote side could send
data on that connection and it would just work. Unless there are
keepalives in use, maintaining a TCP socket requires no data
transmission. If you try and send, the send will eventually timeout.
Before it times out, you have the opportunity to get your device
back in to a state where that send could succeed. If the stackwere
to immediately detect the routing change for the socket and decide
that the socket state was no longer valid, the behavior above would
break. Depending on what's going on, that may or may not be a big
deal.
Since the application using the socket is in a better place to know
about whether or not the change in network state is a big deal and
whether losing the current connection would totally suck or just be
an excuse to try another connection, the application should be the
one making the decision about how to handle these network change
events.
-josh
Very interesting. I'm still not sure though this was the best decision
on (whoever's) part, because the socket becomes unreadable and
unwritable while you're on that other network; essentially a zombie
socket, which isn't very useful anyhow. Perhaps it will reanimate if
you switch back to the other network, but why would you do that or
want that behavior? I think that this situation is exceptional enough
to warrant a special error of some kind. But then again, I'm too young
to be questioning the saints of old... those legendary programmers
responsible for my YouTube fix...
On Oct 23, 2008, at 6:19 PM, Justin C. Walker wrote:
This behavior is hardly accidental. It's one of the design goals
for the protocol (TCP): unless someone specifically breaks a
connection, it should survive the slings and arrows of outrageous
fortune (or more specifically, nuclear attacks on the routing
infrastructure :-})
Justin
This is a really fascinating topic that I wish I'd have more time to
look into — the makings and history of TCP, perhaps its relationship
to foreign policy as well?
Thank you both for the informative replies.
- Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden