using connected UDP socket to contact to portmapper?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hello. Automount nfs mount code can happily perform NFSv4 mounts without a help from portmapper: NFSv4 port is - usually - 2049, and it is enough to perform the mount. But automount - correctly - tries to contact the portmapper anyway (unless the port is specified explicitly), and in case the portmapper service is not running on the remote host, this takes a few seconds to time out. This is because it uses connection-less UDP socket, which does not receive network errors. In order to eliminate this timeout, the socket used to contact the remote portmapper needs to be connected - this way, the OS will report ECONNREFUSED error instantly and the mount operation will proceed without delays even if the remote portmapper is not available. This is rpc_portmap_getport() function. I tried to follow the code, but the logic there is so twisted I've lost track of things quite quickly. The question is: is it possible to use connected UDP sockets there in all cases, or is conn_info->client reused for something else? If it is, I guess we may just get rid of cached (UDP) client and create new client for each call. Or is this completely backwards? I mean, UDP is really unreliable protocol, for it to actually work the app should retry sending packet in case of timeout, and the protocol is easy to spoof too... Alternatively, we may try to contact 2049 port first, and if that one does not respond, try to contact the portmapper. But I'm not sure if this is right thing to do to start with. Thanks, /mjt -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html