Hi- On Jun 6, 2012, at 3:44 AM, Michael Tokarev wrote: > On 06.06.2012 08:12, Ian Kent wrote: >> >>> 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. >> >> Yes, it is a bit convoluted. >> >> This code was originally written for two reasons. >> First to take control over the timeouts to avoid lengthy waits and >> second to reduce socket usage by allowing callers to reuse socket file >> descriptors. > > Is that okay to made these sockets connected? I mean, is the > same socket can be reused to connect to different destination > (host or port)? There's a reason why using a connected socket for UDP port map requests could be problematic. Some older multi-homed servers were not able to return the RPC reply from the same address as the client used to send the RPC request. Thus the client drops the reply. With an unconnected socket, the client can properly process such replies. Thus, for portmap, I think you are better off sticking with unconnected UDP, as the current code in libtirpc does. However, to limit source port utilization, it would make sense to have a long-lived port map client somewhere in user space that could keep just a single port for sending rpcbind queries to all servers. For NFSv2 and NFSv3, a similar design would work well for sending MNT requests. > >>> 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. >> >> Don't think so. > >>> 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... >> >> Backward in the sense that we probably should (and should already) be >> using TCP first. > > If you mean TCP for the portmapper access, well, maybe it > actually does, but obviously the portmapper does not respond > there if it isn't even running on the remote host. > > Even with TCP, in case the portmapper port is firewalled, > we may get timeout. But this should be easy to work around > in the configuration -- when port is specified explicltly, > portmapper isn't consulted at all. With the port mapper protocol, TCP is usually the fallback. This is because setting up a TCP connection is much more expensive, relative to a single RPC request and reply, than it is for UDP, which has no such overhead. A similar scheme as above could be used where a long-lived port map client could cache connections to particular servers which see a lot of mount and unmount activity. A quick review of libtirpc source code shows that there is connection caching logic already built into rpcb_getaddr(3t). I don't know whether it works. >>> 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. >> >> Don't know that yet either. > > Currently it doesn't work with at all /net map. I asked > several times on IRC about this very case, -- whenever it > is ever possible to enumerate (nfsv4) exports without > portmapper, but no one replied :( Note: I know right to > nothing about this RPC internals. NFSv4 is designed to work without rpcbind on the server. Clients certainly can probe the server's rpcbind service to determine whether NFSv4 is available, but they can just as easily send a NULL NFS ping to 2049. --- Chuck Lever chuck [dot] lever [at] oracle [dot] com -- 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
