Talk:Communications protocol

From Wikipedia, the free encyclopedia

"Bus" network topology This article is part of WikiProject Computer networking, an attempt to build a comprehensive and detailed guide to Computer networking on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
Computer networking Portal
Start This article has been rated as Start-Class on the assessment scale.
Computer networking To-do:

Material merged into this article in this edit came from the article Network protocol design principles, now a redirect.

[edit] Confusingly similar articles

Communications protocol and Protocol (computing) seemingly have overlapping content, and no clear boundary as to what's where. It seems to me that there are three separate topics:

  1. Computer network communication protocols (the most common meaning now)
  2. Communication protocols in other kinds of communication networks (e.g. Morse and/or voice via radio)
  3. Communication protocols in computing contexts (e.g. inter-process communication).

I'm trying to figure out how these three separate topics map onto the two articles we have. If I understand it correctly, 1 and 2 are supposed to be in Communications protocol, and 3 in Protocol (computing)? However, content from 1 seems to appear in both articles. So there are a couple of questions:

  • Do we want to have three articles, or two? Having three might make it more likely that we wouldn't have this confusing overlap of content.
  • If we do have three, what should the names be? I would suggest moving 1 to "Protocol (network)" - I know this is going to make a ton of work, but having it at "Communications protocol" seems somewhat confusing, I'd think that would be more appropriate for 2.
  • If only two, do I have the right impression of what ought to be in each article?

It is more important to me that we clear this up than that we adopt any particular solution! Noel (talk) 20:41, 1 September 2005 (UTC)

Now that I look at Special:Whatlinkshere/Communications protocol, a lot of pages actually link to Network protocol, which redirects here, (along with a lesser number of links to similar titles), so maybe the workload of a split wouldn't be too bad after all. That also suggests that the best name for 1 would be "Network protocol", which is what people seem to be using naturally. Noel (talk) 20:58, 1 September 2005 (UTC)

Just to bring it to your attention, I'm doing disambiguation of Protocol atm. I'm really not clear on the distinction between the scope of these two articles, so my redirection of links to either is probably fairly arbitrary. Hairy Dude 14:36, 7 March 2006 (UTC)

I suggest merging them into 1 article, and just having seperate sections for these 2 or 3 parts. That will make it easier to merge the overlapping content. We'll split it back up later after the article gets "too big". --65.70.89.241 16:43, 24 August 2006 (UTC)

The articles should be merged. I think the name should be "Network Protocol" since lots of links would indicate that most people use that phrase rather than computing protocol (never used, in my experience) or communications protocol (not so much, not even in the telecommunications industry - the thing that the telecommunications industry provides is just "The Network" - as opposed, of course, to "The Internet").

Speaking with my academic hat, there is no difference between a Protocol (Computing) and a Communications Protocol. The fields of computing and communications overlap in the area of protocols; computers need protocols to communicate and communications network need computing (hardware and/or software) to carry out the procedure for communicating. You might say that this wasn't the case when mechanical switches were used in telephony, but if a slide rule can be called a computer then so can a mechanical switch.

I have worked as a computer scientist for 30+ years, including 14 in the telecommunications industry (Bellcore/Bell Labs), so I could expand on this at length but would prefer to try to fix the articles. However, I'm a newbie to wikipedia and am concerned about style and - ahem - protocol.

How should I proceed? Ngriffeth 12:00, 28 June 2007 (UTC)


The article says that RSYNC is a proprietary protocol. Thats confusing since the rsync program is free software (GNU GPL). Is rsync really a proprietary protocl?? —Preceding unsigned comment added by 90.185.57.145 (talk) 19:11, 5 February 2008 (UTC)

[edit] network protocol design principles

Questionable passages removed from earlier draft, and comments:

An interesting fact is that the poor design of the error-correction protocol stack of the Internet forces a requirement for error-rates of 1x10-11. This is often achieved by tunneling the the internet protocols through a more reliable protocol such as ATM (asynchronous transfer mode).

This is not true. TCP will work reasonably well up to about 1x10-7, with slight degradation (0.12% packet loss on 12000 bit packets). In any case, it's fibre, not ATM, that is reliable. ATM has no EDC layer at all (unless you count cell header checksums)

The packets each have a checksum, the sum of all the 8-bit bytes in the packet.

No it's not: it's 16-bit one's complement checksum of the contents and a pseudo-IP-header: see http://www.networksorcery.com/enp/protocol/tcp.htm for details

In the internet, ICMP "pings" are sent by routers every 30 seconds or so. In the internet, when a ping fails, the router updates its routing table.

"Table" link rerouted, to provisional stub pending reorg of disambig of Table. --Jerzy 11:07, 2003 Oct 13 (UTC)
No, they're not pings: they're routing update messages.


-- The Anome

Thanks for the corrections. I think I need to qualify the remarks about the packet error rate. If an error rate above 1x10-11 is also coupled to a delay of three hundred milliseconds or more (i.e. a satellite link), I've heard reports that a packet storm of rebroadcast packets can occur, paralyzing the failing link until routers begin to avoid the congestion. A number of experimental and optionally-deployed protocols use more-selective packet retransmission to avoid this problem, which is a known defect in TCP caused by its windowed packet retransmission policy. Ray Van De Walker


See http://www.psc.edu/networking/tcp_friendly.html#performance and specifically the paper http://citeseer.nj.nec.com/mathis97macroscopic.html for

  • a theoretical derivation of TCP performance vs. error + delay * mathematical modelling ditto
  • actual measurements to back up the above.

This seems to suggest that error-limited performance is very roughly

bandwidth = (sqrt(mss) * C) / (rtt * sqrt(ber))

where the units are:

mss = max segment size in bits
C = dimensionless constant, approx 0.9 (see paper for more details)
rtt = round trip time in seconds
ber = bit error rate in per-bit

Note that this is a small-ber approximation, assuming loss is dominated by full-length packets.

Needless to say, the bandwidth does not go to infinity if the ber goes to zero: packet drops will occur when the b/w tries to exceed the physical link b/w.

This model appears to fit reality pretty well, according to the paper.

-- The Anome


Other things that might usefully be discussed

  • stream vs message protocols
  • out-of-order replies
  • pipelining
  • error recovery
  • marking boundaries (count at start vs special character)
  • out-of-band mechanisms (e.g. closing TCP connection to indicate end, FTP using new connections for file contents)

-- MartinPool


The articles should not be merged because then the article (combination of network and computing protocol) will be much to large. Xunex