Talk:Nagle's algorithm

FYI

The person who created Nagle's Algorithm edits on Wikipedia as User:Nagle. He said this on his userpage. To make a new working algorithm is quite an accomplishment. Congratulations to him. --Shultz IV 21:18, 21 May 2006 (UTC)

User 67.67.207.94 (talk · contribs) claimed, in an unsigned edit, that "John Nagle is [an offensive person], necessitating the deletion of this entry. Nagle's algorithm, which may or may not have been useful, must perish along with its creator.". I have refactored this per WP:RFA. 67.67.207.94 also added a Template:dated prod to the article, which I have deleted. See Talk:DZK for the probable cause of this hostility. Cheers, CWC(talk) 22:58, 30 June 2006 (UTC)

Shameless self-promotion?

This article seems like nothing more than shameless self-promotion through the use of various sock-puppet accounts. Is there any real encyclopaedic or noteworthy reason for the inclusion of this article? —Preceding unsigned comment added by 79.75.246.185 (talk) 18:08, August 25, 2007 (UTC)

The use of the Nagle algorithm is mentioned in various TCP-implementations. See the definition of the TCP_NODELAY flag in Microsofts Winsock (http://msdn2.microsoft.com/en-us/library/ms740476(VS.85).aspx) and Linux (http://linux.die.net/man/7/tcp) implementations. I think that it qualifies noteworthy. —Preceding unsigned comment added by 217.210.30.61 (talk) 16:20, 27 January 2008 (UTC)

I just checked those links. Two of them are completely dead and one is just a descriptive listing on a web page or blog. As it stands this evidence seems to fail the noteworthy test. If I can help any editors to do research on this let me know, but if this topic is not important then we should put it up for deletion. Let's first give all editors time to do the legwork on this and to discuss.aharon42 (talk) 03:21, 6 September 2008 (UTC)

Note to wikipedants: please familiarize yourself with whatever topic you're trying to "police" before recommending stuff for deletion, or switch to a topic you are more familiar with. Please see: http://tools.ietf.org/html/rfc1122#page-98 . Yes please delete crap or spam, but when in doubt, don't delete... What next, someone trying to delete Jimmy Cliff from a reggae article? 60.48.224.111 (talk) 04:22, 17 May 2010 (UTC)

Real world application... World of Warcraft!

The 2.3.2 patch notes for World of Warcraft state: "Reduced network latency by disabling the Nagle algorithm." Some interesting technical discuss follows, here. Dfrauzel (talk) 23:12, 30 December 2007 (UTC)

Real patch notes don't list said application. Seems to be a bit of self-promotion to me Philipwhiuk (talk) 21:06, 9 January 2008 (UTC)

Just so any passing readers don't get a false impression from the various comments above, I'd like to point out that the actual real world application for Nagle's algorithm is in the TCP/IP stacks of practically every computer made since the 1980s. The WoW patch note mentioned above is about disabling the algorithm, which is enabled on modern computers by default, to achieve a performance improvement in a particular special case. The whole idea of this article being "self promotion" seem to have been started by an IP editor pissed off at User:Nagle because he questioned the notability of a rapper with no record releases (see AfD). —Ilmari Karonen (talk) 02:06, 25 July 2008 (UTC)

These blog sources and others do not seem reliable. Can I help do some research to find some better ones. If this algorithm is so important and well known then it should be in some programming or computer textbook.. aharon42 (talk) 03:23, 6 September 2008 (UTC)

You mean like some of these books? —Ilmari Karonen (talk) 13:32, 6 September 2008 (UTC)

User send versus segment transmission

If one goes back to the original writeup, the intention was to apply the heuristic on a user send by user send basis, not a segment transmission by segment transmission basis. So, the issue with a user send that is > mss but not an integral multiple of the MSS really shouldn't arise with a "properly implemented" stack. http://tools.ietf.org/rfc/rfc896.txt — Preceding unsigned comment added by Perfgeek (talk • contribs) 20:15, 28 October 2012 (UTC)

can it handle length>65535?

Can Nagle's Algorithm handle packets of total length >65535? (cause it would be easy to support in theory, eg, if a packet is exactly 65535 then FFFF ~data~ 0000 , or if a packet is >65535 then (for 65536): FFFF ~data1~ 01 00 ~data2~~ , which could continue forever until a non-FFFF is reached or until 0000 is reached, but im just theorizing, i don't know how it _ACTUALLY_ works :o ) Divinity76 (talk) 00:50, 8 February 2015 (UTC) UPDATE: answer from John Nagle himself: The maximum possible length for an IP datagram is 65535 bytes, because the size field in the IP header, for both IPv4 and IPv6, is only 16 bits. John Nagle (talk) 06:52, 8 February 2015 (UTC) (src: https://en.wikipedia.org/wiki/User_talk:Nagle#.22Nagle.27s_Algorith.22.2C_can_it_handle_length.3E65535.3F ) Divinity76 (talk) 03:54, 9 February 2015 (UTC)

Window size in algorithm

Nagle (talk · contribs), which window size does the algorithm refer to? I would assume that it is the congestion window and not the receive window and I updated the article accordingly, but please confirm and correct if necessary. After reading Understanding Application Performance on the Network – Part VII: TCP Window Size, I guess it is the receive window, actually? Still a bit confusing. Does window size refer to the actual window size or some sort of available space in the window? II | (t - c) 16:30, 10 July 2016 (UTC)