× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




Wouldn't the program receive an error indication if the other end went
away and it tried to do something? Especially if they are blocking on a
select or read?

No. If no packets arrive, it doesn't know whether that means that the conenction is dead, or whether that means that the remove computer has powered off. The only way it can know is if data is sent that says "that computer isn't available", which isn't possible if the network cable is cut, or if the device that would normally send the message has been powered off.

So it waits on the recv() or select() forever.  (Or until your timeout...)

IF you send something, it would theoretically be able to tell that the data was not received on the other end (assuming that we're talking about a TCP connection). However, it would take awhile to come to that conclusion because it'd keep trying to resend the packet for awhile before it gave up and reported the error.

IP was designed as an "unreliable network". The idea is that packets can be discarded or lost at any time, and it's up to the application (and not the underlying protocol) to detect this and recover. Remember, TCP/IP was originally designed for use by the military under conditions such as an invasion or a nuclear war. It'd be impossible for the hardware and protocol to be able to handle every possible error -- such as a bomb hitting a station where the switching equipment is stored. Instead, the application needs to be vigilant. If you should have data from the remote side by now, but you haven't, you assume that the connection is dead and get on with your life.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.