I believe the TCP_CORK will only hold up the segment if its not full sized (i.e. whatever the mss is then) (barring some other reason to hold up the send).
If the send is large, then we *must* send at least several frames.
Only the last one will have the FIN piggybacked (of course !)
Yes, I was referring to the last frame :).
Except, my point was, when you do the send, if it happens to be a multiple of the mss and all the data fits in full sized frames (i.e no runts left over), then the kernel should send everything out.
This is when the userspace call to shutdown has not occurred yet, in which case the kernel has not yet seen the FIN. When this does come down, its possible all the data actually has already gone out..
True, this is the exceptional case, the odds of nice multiples of the exact amnt of data needed to fit in mss finally is low :).
Otherwise, the send will be successful in sending out the segment, and the FIN will still be sent separately (once the shutdown call executes).
No, the last frame *will* carry over the FIN flag.
See above.
Yes, of course, but my main concern is to save bandwidth. A separate FIN costs a full TCP packet, instead of reusing one bit on the last Data packet. 40 bytes saved out of 40+84+40, that is a 25% saving...
My point was over typical longer lived connections, so the overhead of that extra packet would be amortized over a larger amnt of data. (Lies, damn lies, and perf numbers.. :))
I definitely agree, saving that last packet is a win, and thats usually what people want to optimize on (overally traffic in the network). But note that the last frame can get held up if CORK is set, until the kernel sees the FIN or gets more data to fill a full sized frame..
So the dest app may be seeing its data later..
Well, for a server handling hundreds of connections requests/second, the saving can be quite huge indeed.
Yep, but dont forget the cost of that extra system call :). If the network is lightly loaded but your host is not, and you care about system cpu cycles - it may not be as much as you think. I admit this is really nitpicking territory, but increasing awareness of these other issues is a good thing, even if relevant only in the rare case :).
thanks, Nivedita
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
