[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B6FB6@saturn3.aculab.com>
Date: Thu, 16 Aug 2012 09:50:05 +0100
From: "David Laight" <David.Laight@...LAB.COM>
To: "Yuchung Cheng" <ycheng@...gle.com>, <davem@...emloft.net>,
<hkchu@...gle.com>, <edumazet@...gle.com>, <ncardwell@...gle.com>
Cc: <sivasankar@...ucsd.edu>, <netdev@...r.kernel.org>
Subject: RE: [PATCH v2 0/7] TCP Fast Open client
This comment is a bit late but ...
> ...
> This patch series implement the client functionality of TCP Fast Open.
> TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
> packets and consumed by the receiving end during the initial
connection
> handshake, thus providing a saving of up to one full round trip time
> (RTT)
> compared to standard TCP requiring a three-way handshake (3WHS) to
> complete before data can be exchanged.
> ...
> To use Fast Open, the client application (active SYN sender) must
> replace connect() socket call with sendmsg() or sendto() with the new
> MSG_FASTOPEN flag. If the server supports Fast Open the data exchange
> starts at TCP handshake. Otherwise the connection will automatically
> fall back to conventional TCP.
It seems wrong to be using sendmsg() to perform a 'connect' action.
Anything that tries to monitor the socket state from a trace, or
validate the sequence of library calls will get it all wrong.
IMHO this should be a new connect_xxx() function - and probably
a new system call entry.
This is similar to the complete fubar where sctp abuses setsockopt().
For development hacking using sendmsg() probably avoided the need
to hack at some code paths, but I'm sure it will cause grief in
the long term.
Other OS may have much more difficultly in abusing sendmsg().
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists