Re: Detecting network change
Re: Detecting network change
- Subject: Re: Detecting network change
- From: "Justin C. Walker" <email@hidden>
- Date: Thu, 23 Oct 2008 15:19:19 -0700
On Oct 23, 2008, at 15:04 , Josh Graessley wrote:
On Oct 23, 2008, at 2:51 PM, Greg wrote:
[snip]
I'm surprised by the current behavior of the sockets. I'm using
asynchronous sockets and calling recv() or send() on them does not
result in any serious error on errno after switching jumping
networks, which is bizarre and the reason I started looking outside
the BSD socket API in the first place. I'm curious as to why they
don't do that...
This will fail eventually. I think there are a few reasons this
isn't handled.
[snip]
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.
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
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
My wife 'n kids 'n dogs are gone,
I can't get Jesus on the phone,
But Ol' Milwaukee's Best is my best friend.
-----------
_______________________________________________
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