[PATCH] Added NoDelay config option and nodelay subsystem option

[mouring]

> On Mon, 28 Jan 2002, mouring wrote:
> 
> > [..]
> > > My overlapping reads/writes for sftp seems to be ignored at the moment.
> > > 
> > > I'm not happy.
> > > 
> > > /Tobias
> > > 
> > One thing you must learn Tobias, unless things are clear cut as 'THE WAY'
> > to go there is (and more than likely ever will be) a long period in time
> > from patch conception to inclusion.  And this is one in which is not
> > 100% clear cut.  Between NoDelay, COPY_SIZE, how many overlapping
> > segments, and if we should let the user muck with them are all things that
> > will affect how we accept the patch.
> 
> Of course I understand that it may take some time.  What I do not
> understand is whether a long silence after the first flurry of comments to
> a patch (or a suggested change) means that the patch is under
> consideration, if it was deemed unacceptable, or if it was simply
> forgotten.
> 

If you don't want to be forgotten about log it and push the patch into the
bugzilla tracking system.

> One other thing is that since I did not know who the maintainers were
> (there seem to be a whole bunch), I did not know what "suggestions" were
> "masked vetos".
>
Markus would be considered the 'head' of the project.  It is his baby.
Damien, steves, a few others, and myself would end up being the core
developers (either OpenBSD committers and/or portable tree committers).

Just look at the release notes for a new version and that should list
all of the developers.

> > I'm still waiting for you to provide any information on upping COPY_SIZE
> > to 32k and retesting with multiple overlapping.  I don't remember seeing
> > such an email messages.  
> 
> Looking through my mailboxes, I cannot find such a request, and I do not
> remember one either.  The closest I can find is "Also, you may want to
> check out pushing BLOCKSIZE (think that is right, not looking at the code)
> to 4092 which is the max size the RFC states. This may change your
> testing."
> 
My mistake.. BLOCKSIZE was what I was trying to remember. 

> This comment was made invalid IMHO after the Nagle interaction problem was
> found.
> 
> > However, this should also help lower the amount of overlapping request.  
> > As a result lower the cost of a missing request. I don't want to get
> > into the case where sftp thrashes due to multiple pending requests out
> > and a bad link that drops 2 out of 5 packets.  Which would not only
> > cause large amount of seeks() but also could trigger edge cases within
> > the code for binary integerity.
> 
> First of all, we only need more than one overlapping request if the
> delay-bandwidth product of the link is larger than the block size.  I do
> not have any figures for a wide number of links.  The reason why I thought
> I needed more was the interaction with the Nagle algorithm. The Nagle
> problem is orthogonal, but needs to be resolved.  It seems to be very hard
> to agree on a solution, though.
> 
> The latest version of the overlap patch (which is several weeks old now) 
> contains code to reduce the request size if the server splits a request.  
> With this mechanism, it should be safe to use a larger initial request 
> size.
> 
> > I don't have the patch infront of me..but there was some bits I did not
> > care for if I remember right.
> 
> Please reconsider the patch in light of the nodelay findings.  (And if you 
> do benchmark it, please use TCP_NODELAY in both ends.)
> 

Some bits.. Over it is fine.  I'll take a look at it again.   

- Ben