Date: Thu, 24 Jan 2019 08:39:02 +0700 From: Alexey Dokuchaev <danfe@nsu.ru> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "net@freebsd.org" <net@freebsd.org> Subject: Re: Why rpcb_getaddr(3) uses UDP even for TCP NFS mounts? Message-ID: <20190124013902.GA50004@regency.nsu.ru> In-Reply-To: <YQBPR01MB01134DB658390853B481B211DD990@YQBPR01MB0113.CANPRD01.PROD.OUTLOOK.COM> References: <20190123093454.GA87168@regency.nsu.ru> <YQBPR01MB01134DB658390853B481B211DD990@YQBPR01MB0113.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 23, 2019 at 08:40:39PM +0000, Rick Macklem wrote: > Well, there is a reason why NFSv4 (published in an RFC in 2003) does > not use the Mount protocol or rpcbind. > Those protocols were defined decades ago by a company that no longer > exists. I understand that. :-) > If you took a look at Linux sources and found that they avoided using > UDP for rpcbind, then a compatible change would probably be ok. > To do this well, you probably have to look at several distros and see > if they all handle TCP only rpcbind.) I'll have a look, however, even our own sources say this in the comment for __rpcb_findaddr_timed(): * The algorithm used: If the transports is TCP or UDP, it first tries * version 2 (portmap), 4 and then 3 (svr4). This order should be * changed in the next OS release to 4, 2 and 3. We are assuming that by * that time, version 4 would be available on many machines on the network. * With this algorithm, we get performance as well as a plan for * obsoleting version 2. But I guess what exactly is "the next OS release" was never defined, and nothing was actually changed. That said, proposed order "4, 2 and 3" still looks strange to me: why not the more natural "4, 3, 2"? ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190124013902.GA50004>