[PATCH] tcp options fix

[Scott Lamb]

On Jan 13, 2006, at 3:04 AM, Guus Sliepen wrote:
>> And the other problem I noticed - the extra packet each way - seems
>> to be that send_tcppacket does two writes - one through send_request,
>> one directly through send_meta. I see a comment "/* Evil hack. */" in
>> there. Is this what it's referring to?
>
> I think I know what happens: when send_tcppacket() is called, it first
> sends a small header indicating that a VPN packet is coming in (and  
> how
> big it is), then the packet itself follows. Because that means it does
> two write() calls, and Nagle has been disabled, the kernel will  
> send two
> TCP packets.

That's my understanding also. Prior to my Nagle fix, I think this was  
happening:

     host A: ping header
     host B: delayed ack
     host A: ping body
     host B: ack + pong header
     host A: delayed ack
     host B: pong body <-- and here my ping completes
     host A: delayed ack or ack + next packet

requiring six legs and two ack delays until I see the pong, causing  
my high latency. Now it's doing this:

     host A: ping header
     host A: ping body
     host B: ack + pong header (or a separate, immediate ack if the  
pong's not quick enough)
     host B: pong body <-- completes here
     host A: immediate ack

which is low-latency but still wastes two or three packets of  
bandwidth over the ideal:

     host A: ping
     host B: ack + pong
     host A: delayed ack or ack+next packet

> So, to make things a bit more efficient, send_tcppacket()
> should combine this somehow in one write() call...

Yeah.

I also worry a bit about send_meta's EWOULDBLOCK case. It returns  
false, which seems to mean "the connection broke; terminate it". Is  
this why there's a BlockingTCP option for "slow or congested links"?  
I'm tempted to:

- remove BlockingTCP
- make send_meta return true on EWOULDBLOCK
- add logic to main_loop to watch for write availability of meta  
connections with non-empty buffers and flush them.

Regards,
Scott

-- 
Scott Lamb <http://www.slamb.org/>