Jump to content

Talk:Communication protocol

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Cherdchai Iamwongsrikul (talk | contribs) at 11:02, 2 December 2017 (Cherdchai Iamwongsrikul moved page Talk:Communications protocol to Talk:Communication protocol). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Please add {{WikiProject banner shell}} to this page and add the quality rating to that template instead of this project banner. See WP:PIQA for details.
WikiProject iconComputing: Networking C‑class High‑importance
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
CThis article has been rated as C-class on Wikipedia's content assessment scale.
HighThis article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (assessed as Top-importance).

Merge outcome

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

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

protocol vs language

despite the comer reference i think there is an important distinction to be made between protocols and languages. protocols are usually restricted to a specific set of predefined messages whereas languages can communicate origninal content. — Preceding unsigned comment added by 69.116.92.84 (talk) 12:09, 22 August 2013 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 2 external links on Communications protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:32, 11 August 2017 (UTC)[reply]