At 02:41 PM 4/4/2008, Chuck Lever wrote: >Use TCP instead of UDP to contact the local rpcbind daemon. If >rpcbind isn't listening, the connection is refused immediately, and >the RPC client can tell without waiting for a timeout. You can get a prompt error if you use UDP connected mode (call connect() on the UDP socket). Any ICMP port unreachable will flow back to an ECONNREFUSED error on the socket. This doesn't occur for unconnected UDP endpoints. >We would have to create a new RPC_CLNT_CREATE_FOO flag that tells the >client to fail an RPC immediately if the connection is refused (kind >of like the old "one shot" flag). This shouldn't be the default >behavior. Sounds reasonable. But, a port unreachable error should generally be a "hard" indication, since it does come from the remote host, or a middlebox acting as its proxy. In other words, any reasonably small number of retries would all receive the same response. This is much like a TCP RST - not a transitory event. UDP errors such as host unreachable or network down (which come from the infrastructure not the server) should not of course be considered this way and retry is appropriate. Bottom line, I think it might actually be a useful default. Why does the client currently retry ECONNREFUSED for port resolution? Tom. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
