From owner-freebsd-net@freebsd.org Thu Jan 24 01:07:36 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B15AF14B8262 for ; Thu, 24 Jan 2019 01:07:35 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 201576E21A for ; Thu, 24 Jan 2019 01:07:35 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id D756D14B8261; Thu, 24 Jan 2019 01:07:34 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5A7614B8260 for ; Thu, 24 Jan 2019 01:07:34 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CE5C6E218 for ; Thu, 24 Jan 2019 01:07:33 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from Debian-exim by mx.nsu.ru with local (Exim 4.72) (envelope-from ) id 1gmTUK-0000S4-Kq for net@freebsd.org; Thu, 24 Jan 2019 08:07:24 +0700 Received: from [84.237.50.47] (helo=regency.nsu.ru) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1gmTUK-0000Rr-Jh; Thu, 24 Jan 2019 08:07:24 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id x0O1d8WU051427; Thu, 24 Jan 2019 07:39:08 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id x0O1d3C1051358; Thu, 24 Jan 2019 08:39:03 +0700 (+07) (envelope-from danfe) Date: Thu, 24 Jan 2019 08:39:02 +0700 From: Alexey Dokuchaev To: Rick Macklem Cc: "net@freebsd.org" Subject: Re: Why rpcb_getaddr(3) uses UDP even for TCP NFS mounts? Message-ID: <20190124013902.GA50004@regency.nsu.ru> References: <20190123093454.GA87168@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 3 X-KLMS-Message-Action: skipped X-KLMS-AntiSpam-Status: not scanned, whitelist X-KLMS-AntiPhishing: not scanned, whitelist X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, whitelist X-Rspamd-Queue-Id: 3CE5C6E218 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 01:07:36 -0000 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