Please give the quote. I woudl like to see if it really says that information on the last sent packet is available immediately after the send call returns, since that is your claim.
Sorry, I've confused the issue. I was only saying that I had previously believed that to be the case for *JAVA* in particular, but...
...I then made the point that the TCP spec contains a suggested set of information that should be exposed by an API, but which Java does *NOT* expose; without this info, it is not possible to do things which IMHO you really ought to be able to do in TCP [c.f. below], because it was designed with such use in mind, as far as I had been aware (but I'll need to re-read RFC's etc to check the extent to which these application designs were intended...).
I was then suggesting that, having worked with the TCP RFC before, I'd probably assumed java behaved the way I had because this was the ONLY way that java could fully support all TCP-based application designs, since it doesn't have a "STATUS" command. If you search the 793 for "STATUS" you should find the paras outlining the suggested info. About 3 pages earlier it is at pains to explain that it is NOT mandating this.
The TCP spec suggested info includes "bytes acknowledged". With this information, the API-user can accurately and definitely discover whether or not all their SENT packets have been RECEIVED (...which is the core functionality demanded by the use-cases cited previously; I had naively assumed old-IO in java provided this functionality automatically, since it's API's are dumbed-down, compared to what the RFC suggests. Whilst I've been accepting this is wrong, I've been struggling to accept that it's impossible to achieve in java. If everything you've said is true, it is indeed impossible, which IMHO is limiting enough that it MUST be documented in the API docs).
Since you wanted an RFC reference, this seems pretty clear and authoritative:
==================================
RFC1180, Page 24
TCP is a sliding window protocol with time-out and retransmits.
Outgoing data must be acknowledged by the far-end TCP.
Acknowledgements can be piggybacked on data. Both receiving ends can
flow control the far end, thus preventing a buffer overrun.
As with all sliding window protocols, the protocol has a window size.
The window size determines the amount of data that can be transmitted
before an acknowledgement is required. For TCP, this amount is not a
number of TCP segments but a number of bytes.
=====================================
SO it seems very clear to me that acknowledgement of individual writes is NOT requried by the protocol. The guarantee is that after a certain number of bytes, those bytes must be acknowledged, with that number fo bytes set by a transmission window.
You are correct that "acknowledgement of individual writes is NOT required", but that does not mean that the protocol is NOT AWARE of how many bytes have been acknowledged (which is the functionality I've been referring to throughout, albeit perhaps badly explained on my part).
The text you've quoted refers to the "transmission-in-progress" pseudo-state (i.e. my ease-of-explanation definition meaning "what happens in the middle of a transfer"
). My core concern is that once I've *finished* transmitting a set of bytes, I want to know when/whether they've been *successfully* transmitted.
The question is, should I be allowed to know this *only* when I close the TCP connection? The evidence you've offered for java (and for Berkeley, since I'm taking your word for it there) explicitly says I have to close the connection to know that my data was sent.
That sucks.
TCP is a very old protocol, so it's easy to imagine that it was designed for something as low performance as opening and closing a separate stream for each application-level chunk of data (i.e. no pipelining); pipelining made a relatively late move into various RFC's (e.g. HTTP). I'd always worked on the assumption that TCP supports pipelining; the RFC I quoted explicitly "suggests" that implementors "could" provide a set of info that happens to include everything necessary for API-users to implement correct pipelinining with minimal effort, by reusing data that TCP is already keeping track of.
Are we done yet?
As if!
No, seriously, I really want to explain this to you sufficiently that you understand my perspective here. If you think this is better done by email or phone...? Basically, I want you to understand why what I'm suggesting is reasonable to assume, and reasonable to expect. It's sufficiently unlikely that java's old IO sucks THIS much that I basically want an informed second opinion. I'm actually secretly hoping that there's some other way of achieving this "reasonable" functionality in java, and that I just haven't spotted it yet.
Unfortunately, there's only one person I know who knows *everything* I do about networking in java, and a lot more on top, and he's hard to get hold of
.
I have some niggling memories in the back of my head of rants by academics against the IO models of Java pre-NIO, and I'm wondering now if we've come across what they were referring to (I didn't pay much attention at the time; I wasn't that interested in networking back then). My vague memory is of hearing them as part of various papers/articles/lectures/pages (can't remember which
) outlining "serious fundamental problems" with java; I think it's the same place I first discovered some of the major (but extremely subtle) JVM bugs where e.g. Sun's 1.1.x reference JVM didn't adhere to the JLS in "10 different ways". But it was sooooo long ago...
