Re: bin/59865: ftp should not set socket send/receive buffers unless told to

["Christof Meerwald via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59865; it has been noted by GNATS.

From: Christof Meerwald <cmeerw%cmeerw.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/59865: ftp should not set socket send/receive buffers unless
 told to
Date: Thu, 15 Jan 2026 22:00:19 +0100

 On Thu, Jan 15, 2026 at 05:05:01AM +0000, Luke Mewburn via gnats wrote:
 >  1. Existing ftp autoscale:
 >     By default if the rcvbuf/sndbuf/xferbuf commands haven't been used,
 >     autoscale on startup based on getsockopt(SO_RCVBUF) / getsockopt(SO_SNDBUF)
 >     as appropriate.  I.e, rcvbuf_size and sndbuf_size are 0.
 >     This functionality has existed since 1998-07-20, improved 1999-09-22.
 
 Maybe worth pointing out that TCP socket buffers automatic sizing was
 only added in 2007-08-02, so until then the additional setsockopt was
 presumably a no-op.
 
 https://cvsweb.netbsd.org/bsdweb.cgi//src/sys/sys/socketvar.h#rev1.98
 
 I still don't understand why, with the kernel TCP socket buffer
 automatic sizing, this getsockopt/setsockopt is ever desirable? Why is
 this not just a bug?
 
 
 >  2. Existing commands rcvbuf/sndbuf/xferbuf:
 >     If these commands are used interactively (or via macros in .netrc) with
 >     a positive value, change rcvbuf_size and sndbuf_size as appropriate,
 >     use those values and don't autoscale.
 
 Sure.
 
 >  3. New control(s) to disable ftp's autoscale and use the system defaults.
 >     This would be new functionality.
 
 I think this should just be the default.
 
 
 >  The new control(s) could be one or more of:
 >  
 >  3a. A new CLI option. This would affect URI fetchs and classic FTP.
 >  
 >  3b. A new ftp command. This would be used within .netrc, but wouldn't
 >      work for URI fetch.
 
 I don't think that's useful if it won't work for URI fetch.
 
 
 >  3c. Add more meaning to the argument of the existing -x XFERSIZE option
 >      and rcvbuf|sndbuf|xferbuf SIZE commands.
 >      Currently '0' is invalid even though that's the startup default.
 >      Maybe add symbolic words for XFERSIZE/SIZE as:
 >  	- "autoscale":	getsockopt() current values, and setsockopt() a value
 >  			clamped between [8 KiB, 8 MiB),
 >  			Default behaviour because it's been the existing
 >  			behaviour for 27 years.
 
 Calling that "autoscale" seems misleading to me.
 
 >      	- "system":	Use system defaults. Do not call setsockopt().
 >  			bufsize defaults to XFERBUFMAX (128 KiB).
 >  	- NUMBER:	Existing behaviour, no change.
 >  
 >  3d. Potentially add $FTPXFERSIZE environment variable to override
 >      the default "autoscale" behaviour?
 >  
 >  (Internally I'd probably implement this with magic negative values for
 >  rcvbuf_size and sndbuf_size in the code, with appropriate checks and
 >  asserts.)
 >  
 >  Thoughts ?
 
 I still don't see the need for all that complexity.