|WikiProject Computing / Networking||(Rated Start-class, High-importance)|
- 1 Confusingly similar articles
- 2 RSYNC
- 3 network protocol design principles
- 4 Proprietary standards
- 5 Technologies? Standards? Protocols?
- 6 Hardware protocols
- 7 Proposal: on how to add citations.
- 8 Painter of the Treason of Images
- 9 "Wire format"
- 10 History?
- 11 Length
- 12 Computer science "generally accepted" definition
- 13 protocol vs language
Confusingly similar articles
- Computer network communication protocols (the most common meaning now)
- Communication protocols in other kinds of communication networks (e.g. Morse and/or voice via radio)
- 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 doesn't appear that anyone has written anything covering items 2 and 3. If there's no content, there can't be an article or a section. First step will be to merge so that we don't have two articles covering the same topic, item 1. --Kvng (talk) 23:46, 11 May 2010 (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". --184.108.40.206 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)
- A merge has been proposed and has been open for discussion here since 2007. The way to proceed is to do the merge. --Kvng (talk) 17:50, 15 April 2010 (UTC)
- I would suggest merging to Communications protocol and that would be the surviving name. A quick read-through shows Protocol (computing) to be all about communications. --Kvng (talk) 23:46, 11 May 2010 (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 220.127.116.11 (talk) 19:11, 5 February 2008 (UTC)
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
- 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
- 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)
The articles should not be merged because then the article (combination of network and computing protocol) will be much to large. Xunex
Odd that we have a section here about Proprietary standards, and they are mentioned in other articles, but we have no article on what they are or how they differer from other or "real" standards. Jim.henderson (talk) 17:39, 7 December 2008 (UTC)
Technologies? Standards? Protocols?
I noticed that some article don't reference to, and don't mention the term "Communications protocol". for example:
It has always sounded strange to me when someone refers to communications interconnect hardware as a protocol. Is Ethernet a protocol? Is WiFi a protocol? Is RS-232 a protocol? Is a data bus a protocol? If you visit these articles the subject is not discussed as being a protocol but as implementing or being capable of carrying various protocols. I can understand how the various matched parameters required for communications (e.g. electrical configuration and voltage levels, RF carrier frequency) could technically be considered a protocol but in my experience "protocol" is not how these things are described by practicing communications engineers. The article is not particularly clear on this point. I can edit the article to clarify this but would like to get some feedback first. --Kvng (talk) 17:50, 15 April 2010 (UTC)
Proposal: on how to add citations.
Some of my contributions need citing, but the page lacks a
I propose to do it like this:
== References == ! .. (books) ! [COMER]:Douglas E. Comer, title ... ISBN .. ! .. ! <references/>
The ! should be thought of as meaning a newline
In the text above:
Text .. <ref> [COMER]: Ch.11 .. pg 192 ..... etc </ref>
- Have a look at WP:CITESHORT. Same idea. Wikipedia sanctioned formatting. --Kvng (talk) 15:09, 24 September 2010 (UTC)
Painter of the Treason of Images
The Treason of Images was painted by Rene Magritte (ref:3rd paragraph).
- The word wire format is sometimes used in a Java context to refer to a message format.--Jsoon eu (talk) 14:26, 24 November 2010 (UTC)
- Protocols have been there since day one. They form the glue for communications, so they are very dependent on the operating systems used (in-system protocols) and the (inter)network architecture (between-systems protocols). The problems associated with operating systems where solved with "concurrent programming" and the problems with networks where solved with the "TCP/IP and ISO model". To give an idea of time: 1950-1970 operating systems, 1970-1980 closed systems malaise, 1980-1990 LANs and the Internet, 1990-2000 WWW (webprotocols).
The recurring pattern in protocol history is that proprietary protocols are war declarations (on the market) and the inevitable (because communications assume agreement) standardizations are like peace treaties.
Maybe others can give there view or comment on this take?--Jsoon eu (talk) 07:10, 12 December 2010 (UTC)
I have the exact same feeling. I started reading this article to learn about protocols and without a good knowledge in computers. I stopped in the way because:
- the article is too wordy
- entire sections seem irrelevant or poorly introduced
- there's a lack of concrete short examples
Here are suggestions of improvement:
- more examples and diagrams
- talk about the Internet protocols (TCP / IP) more prominently, since this is an example most people would be interested in.
- provide more context - history, creators, applications
- delete sections around "protocols and programming languages" analogy. I don't have a CS background and therefore I did not get it. If writer tries to convey message, just say it. It took the double length to explain since he/she had to explain algorithm and programming languages. It may be relevant for "protocol design" but the result is a very long section that made me give up. -- Gabaix 7 June 2011 (UTC)
Computer science "generally accepted" definition
The Jargon File has an entry for it (http://www.catb.org/jargon/html/P/protocol.html). Most of it is semihumorous fluff, but the middle bit -- "describe any set of rules that allow different machines or pieces of software to coordinate with each other without ambiguity" -- is pretty solid, and I think the Jargon File is a pretty strong match for the criteria of generally acceptance by computer science. Heavenlyhash (talk) 18:03, 26 April 2011 (UTC)
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 18.104.22.168 (talk) 12:09, 22 August 2013 (UTC)