• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Detecting network change
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Detecting network change
      • From: Jens Alfke <email@hidden>
References: 
 >Detecting network change (From: Greg <email@hidden>)
 >Re: Detecting network change (From: Jens Alfke <email@hidden>)
 >Re: Detecting network change (From: Greg <email@hidden>)
 >Re: Detecting network change (From: "Shawn Erickson" <email@hidden>)
 >Re: Detecting network change (From: Josh Graessley <email@hidden>)
 >Re: Detecting network change (From: Greg <email@hidden>)
 >Re: Detecting network change (From: Josh Graessley <email@hidden>)

  • Prev by Date: Re: Detecting network change
  • Next by Date: Re: Detecting network change
  • Previous by thread: Re: Detecting network change
  • Next by thread: Re: Detecting network change
  • Index(es):
    • Date
    • Thread