On Monday, October 24, 2005 01:21:05 PM -0400 Ken Hornstein <[EMAIL PROTECTED]> wrote:
/* Linux is nice -- it can tell us right away that we cannot * reach this recipient by returning an ENETUNREACH error * code. So, when this happens let's "down" the host NOW so * we don't sit around waiting for this host to timeout later. */I can't speak for the Windows implementation ... but I thought that the Linux version of this drove some network implementations nuts (e.g., the BIND codebase), because if you send out a bunch of packets to different hosts it's impossible to match up the ICMP error with a particular packet, and depending on what you're doing you may get an error from the "wrong" server (this is why other Unixes require the use of a connected socket to get back ICMP errors). Maybe this has changed, I dunno.
You're thinking of two different things. The behavior the comment is talking about is that if you try to send a packet and there is no route (or it is on the local network and not answering ARP's, or...), then you will get an error on the syscall where you send the packet. The annoying behavior which is unique to Linux is that they decided that when an ICMP unreachable was received, the standard required them to notify the application that sent the packet, by returning an error on the next (unrelated) operation on the same socket. They did not seem to understand that the requirement was to make the information available to the application, rather than to shove it at apps that don't care at the expense of breaking lots of things. After a while, they added a socket option to disable the broken behavior, allowing applications to request "BSD compatible" behavior (of course, there was nothing BSD compatible about having to explicitly request the traditional behavior). The good news is that they apparently finally figured out how dumb this was, and made the traditional "correct" behavior the default. -- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
