Talk:Transmission Control Protocol

Checksum

The TCP checksum -- isn't it more properly referred to as the one's complement of the one's complement sum? In any case, I'm removing the link to one's complement in the article, because that gives a *very* misleading impression of how to calculate the checksum.--Ryan Stone 19:01, 8 Nov 2004 (UTC)

RFC 793 calls it the one's complement of the one's complement sum, so that's what I'm putting in the article.--Ryan Stone 19:08, 8 Nov 2004 (UTC)

Yes, it's the complement of the sum, so that when you receive a packet, you don't have to zero out the checksum field (after first storing the checksum), and then compare the checksums afterwards - you just sum up the packet, with the received checksum in situ, and the resulting sum should be 0 (actually all 1's, which is also zero in one-comp notation - there's no way to add up any sequences of non-zero numbers and get 0 as the result in one's-comp addition, due to the wrap-around add of the carry). I'll add this to the article, along with why we used a ones-comp sum to begin with. Noel (talk) 14:22, 14 Nov 2004 (UTC)

---

Is it really appropriate to have the ellipsis after the Network Layer enumeration of IPv4, IPv6, and ARP? Are there really other network layer protocols?

TCP windows or Windows' TCP

In the paragraph titled TCP window size: "The Windows TCP/IP stack is designed to self-tune itself" - do you mean Microsoft Windows ? (Since "window" generally means something else in this paragraph). If yes, make it explicit. If no, why the word order and capitalization?

This confused me too, so I googled the phrase. It looks like that paragraph was ripped off of [Microsoft] (I really doubt the other way 'round....). Anyway, in the context of the microsoft article, it clearly refers to Microsoft Windows 200x.

Ah, both the Window scaling and the Window size sections are ripped off of that MS article. Probably more.

Jeff 02:11, July 12, 2005 (UTC)

Poor definition methodology

Just making a simple observation: Several examples in this article casually use the accronym TCP in its own definition, which is generally considered poor practice. E.g. ...Any SYN packet holds Sequence Number. The Sequence Number is a 32-bit field TCP segment header...

In this case it could be considered confusing to the laymen to use the subject of the article in its own definition.

Comment: But does it really matter? Laymen wouldn't understand the details of the protocol anyway...and are probably not interested in try to understand them. —Preceding unsigned comment added by 74.93.1.129 (talk • contribs)

Few responses to above

As someone who originally did much of this article, I'd like to challenge the whole notion of 3-way and 2-way termination handshake. I don't believe that is really any such thing, I think what this is, is some stacks "cheating", but I'll dig into it to verify. And the 2-way handshake, that certainly sounds made up. Going by the state diagram and calling it 2-way or 3-way based on that is a bit misleading I think. In any case, I don't believe anyone ever refers to the connection termination as a handshake and pretty sure never a 3-way or 2-way handshake, but I'm prepared to be proven wrong. ...and we refer IP datagrams, UDP messages and TCP segments, but most people tend to say "packets" and that is generally fine unless one is being particularly pedantic. It looks the article needs some other minor updates since I last looked and I'll try to do my share soon.

Can someone please check the sequence number used in client's ACK for the 3-way handshake? I believe this is incorrect and should be using the initial sequence number

— Preceding unsigned comment added by Kthelgason (talk • contribs)