Talk:TCP delayed acknowledgment

Nagle's algorithm

Wikipedia's articles on TCP need and reference the article on Nagle's algorithm. The article on Nagle's algorithm references and needs the article on TCP delayed acknowledgment. If the article on TCP delayed acknowledgment deleted, then the article on Nagle's algorithm is broken. If the article on Nagle's algorithm is broken, the articles on TCP are broken.

Then write a referenced, properly formatted article that isn't written as a manual. Ironholds (talk) 02:43, 27 March 2010 (UTC)

I am an engineer. Anyone who is a real expert on this stuff will write as a manual. If written the way you want it written, most likely written by people who do not know what they are talking about. Plus, anyone who is looking up TCP delayed acknowledgment, probably wants a manual.

And why should not Wikipedia be a manual James A. Donald (talk) 01:10, 28 March 2010 (UTC)

"Wikipedia is an encyclopedic reference, not an instruction manual, guidebook, or textbook. Wikipedia articles should not read like.... Instruction manuals.

This rule prohibits direct engagement with reality. Anything that has the form "If you do X, you will experience Y" has the form of a manual or guidebook.  ::::This rule demands official truth from on high, and rejects experienced truth. On TCP, there is no official truth from on high, only experienced truth. If there is an official truth on TCP delayed acknowledgment, it is page 96 of RFC 1122, which is even more manual like:

"A delayed ACK gives the application an opportunity to

update the window and perhaps to send an immediate

response. In particular, in the case of character-mode

remote login, a delayed ACK can reduce the number of

segments sent by the server by a factor of 3 (ACK,

window update, and echo character all combined in one

segment).

"In addition, on some large multi-user hosts, a delayed

ACK can substantially reduce protocol processing

overhead by reducing the total number of packets to be

processed [TCP:5]. However, excessive delays on ACK's

can disturb the round-trip timing and packet "clocking"

algorithms [TCP:7]."

Do you like the official truth better than my version? It has the advantage of being official, and the disadvantage of being polemical - clearly stating the advantages of delayed ack, while being vague and evasive about the ensuing problems.

"

• 1) please don't edit or screw around with someone else's comment. 2) You're missing the point. Saying "X is better than Y" does not make X good; it simply makes Y worse. Take a look at Aspect weaver for an example of a decent software article. Ironholds (talk) 01:51, 28 March 2010 (UTC)

Possibly so. All relevant and necessary information on TCP delayed acknowledgment is in my article and on pages 95 and 96 of RFC 1122. Perhaps you should rewrite the article. On the whole, delayed acknowledgment is a good idea for the reasons stated in RFC 1122, but it causes problems, which have to be worked around. —Preceding unsigned comment added by James A. Donald (talk • contribs) 02:09, 28 March 2010 (UTC)

As I see it, the biggest problem is the complete lack of any context. I've tried to add a bit of an introduction but I'm no expert on the subject. 82.46.253.56 (talk) 15:34, 17 August 2010 (UTC)

I have to agree with the above user. Because of the lack of context and the fact that it is a very technical article, I have added the (confusing) tag. I'm sure it makes sense to experts on the subject, but for the average reader it is very difficult to understand. AdventurousSquirrel (talk) 18:18, 3 November 2011 (UTC)