||[Aug. 19th, 2007|03:14 pm]
In TCP connection setup with have a syn, syn+ack, ack. As far as I understand, there is nothing stopping data to be sent with the first ack except the lack of an API to do so. (In socket world, the socket isn't writeable at that stage and you are still in connect() until the ack is sent). |
Sun streams was supposed to solve this, but didn't gain traction outside solaris space. Is there anything that allows you to do this on Linux? Why don't clients do this to if so.
2007-08-19 11:09 pm (UTC)
It is indeed permitted (Section 3.4 of RFC 793), but I'm not aware of any implementation that does it.
So the idea would be to get data moving faster?
I was going to say something along the lines of 'what good would that do' but I think that I know better now :)
Perhaps it could be implemented at the load balancer. In perlbal maybe?
no, it needs to be done in the client
the problem is that no socket API lets you pack data into the first ack
that would mean that the client would have to request something with the initial syn :)
What would the server be sending along with that first ack?
No, I mean with the clients first ack. You can't send anything with the SYNACK, but the first ack from the client could send data with it. But it would require you to tell the API what data you want to send in that ack.
Drop down to the raw packet interface to construct your packets. No idea how well that would mix with an existing TCP connection or the APIs for it, but maybe there is a way to do it. Might have to circumvent libc and Have Your Way with some syscalls. I've never explored this...
Note that you're only saving packets on the wire. Not any time. In my ethereal window here, I see a 45 to 55 usec delay between the client sending that confirmation ACK and the first PSH/ACK.