Talk:Protocol (computer)

From Citizendium
Revision as of 14:46, 9 May 2008 by imported>Howard C. Berkowitz (→‎Too much emphasis on OSI: new section)
Jump to navigation Jump to search
This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition Rules for communication among devices in a computer network. [d] [e]
Checklist and Archives
 Workgroup category Computers [Categories OK]
 Talk Archive none  English language variant British English

will a list of more protocols be described here?, TPX/PX, UDP/ICMP etc??? Robert Tito | Talk 17:09, 20 February 2007 (CST)

Ideally I think we need a list of protocols, possibly divided by purpose or something, as well as a brief description. This will largely be about aggregating protocols and defining them. -- ZachPruckowski (Talk) 17:12, 20 February 2007 (CST)

I think if we seperated the protocols into different articles but had them all under the Computer Protocol category, then it might work out. We could define the protocols based on something like: Connection Oriented and Connectionless such as certain routing protocols and TFTP. --Paul Derry 17:19, 20 February 2007 (CST)

I definately agree with the Communications Protocol Category.--Nick Johnson 13:29, 22 February 2007 (CST)

I expanded the article a bunch, emphasizing the OSI model.--Nick Johnson 13:29, 22 February 2007 (CST)

Protocol List

I know there has been some talk about not using categories or lists, but I think we ought to have one for the protocols since they cover such a broad field of use. --Paul Derry 11:07, 24 February 2007 (CST)

making separate articles for every protocol will leave us with a bunch of 2 line articles, as if we are waiting for that. Robert Tito | Talk 11:09, 24 February 2007 (CST)

What if we clustered related protocols such as TFTP, SFTP and FTP, they still all have the same function, the protocols are just slightly different. The article might be entitled FTP and have the different variants of it. The same could be said of one for RIP, RIPv1 and RIPv2 would go into the same page. It's not a certainty, but it would help limit one-liner protocol pages. Especially if we cluster them well.

--Paul Derry 15:26, 24 February 2007 (CST)

There is pedagogic value in comparing different protocol stacks (IP, IPX, X.25, etc.) and how the addess the same problems, so even if we don't want to become a compendium of protocols, it's worthwhile to consider some basic examples and compare them. Greg Woodhouse 14:42, 14 May 2007 (CDT)

big problems with overall relationship of articles

First off, "protocols" are used in computer science in areas far outside physical networking. Anybody can design a thing called a "protocol" to allow any two things (or larger group of things) to communicate. So the name of the article is too broad at the moment, or else the focus of the article is too narrow. Secondly, this article duplicates much of the content of OSI 7-layer model and computer network. I'm not judging just what should go where. I'm saying that we need a coherent plan on how all these articles are going to cooperate. We also have internet, world wide web, and a number of other articles springing up like weeds without any gardener's hand guiding their inter-relationships. Help! Pat Palmer 14:34, 14 May 2007 (CDT)

some things in the list of protocols are not protocols

In the TCP/IP networking terminology, FTP is an "application" (as in OSI 7-layer model), not a protocol. So is SMTP. The list of things there are not all at the network protocol level in the so-called "network stack", which is kind of messy and may lead a reader into confusion. Pat Palmer 16:08, 15 May 2007 (CDT)

Actually, FTP (and, for that matter, telnet) are both the names of protocols and of application clients. When one issues an ftp command from a command line interface, it invokes the File Transfer Protocol (RFC 959 and various updates). ftp is also a method in URLs. Howard C. Berkowitz 14:25, 9 May 2008 (CDT)

can we reverse the order of the stack?

In all literature, the Application Layer is always depicted "on top" (first). Is there a way to hand-number a list so that layer 7 is "on top" and layer 1 on "bottom"? Pat Palmer 16:15, 15 May 2007 (CDT)

Too much emphasis on OSI

In computer networking reference models, I discuss that the OSI reference model, at least in the basic 7-layer form, is obsolete. Offhand, the only real-world 7-layer protocol stack that comes to mind is the Network File System (NFS) from the UNIX/TCP-IP world, not OSI. Even there, there's apt to be sublayering in the network layer (e.g. ARP), in the data link layer (LLC and MAC), and at the physical layer.

Having taught networking protocols for many years, I find the informal 4-layer model used in the Internet, which emphatically considers rigid layering a bad idea, to be much more intuitive. It consists of application, end-to-end, internetwork, and a rather agnostic collection of "interface" protocols below IP.

What is the layering, for example, of BGP running over TCP over IP over pseudo-PPP L2TP over UDP over another IP over 802.2 LLC Class I over 802.3 MAC over 802.3 100BaseT? How about SMTP over TCP over IP through GMPLS that selects a particular optical wavelength ver DWDM? Think about IP in IP, or IP in GRE, used to run private addresses over a public network. I miss ATM LAN Emulation (LANE), as it could really get recursive.

I am dubious that a master list of protocols is really of great use, beyond what you could do with a search engine looking for protocol names. How far back should one go? Novell NLSP and SPX? AppleTalk AARP and ZIP? ARPANET IMP-IMP? Semaphore? Signal flags?

Someday, I'm going to find a protocol theologian and exorcise the OSI model.

Owner: Nononono, no, no! 'E's resting in the Study Group!
Mr. Praline: All right then, if he's restin', I'll wake him up! (shouting at the cage) 'Ello, Mister Polly Parrot! NETWORK-CONNECT-REQUEST! SESSION-RESYNCHRONIZE! I've got a lovely fresh cuttle fish for you if you show...
(owner hits the cage) [Note Murphy's Law of Trade Shows: any sufficiently advanced technology is indistinguishable from a rigged demo]
Owner: There, he moved bits!
Mr. Praline: No, he didn't, that was you hitting the Ethernet connector!
Owner: I never!!
Mr. Praline: Yes, you did!
Owner: I never, never did anything...
Mr. Praline: (yelling and hitting the cage repeatedly) 'ELLO POLLY!!!!! 802.2 XID! 802.2 XID! 802.2 XID! 802.2 XID! This is your nine o'clock alarm call!
(Takes protocol out of the cage and thumps its preamble and header on the counter. Throws it up in the air and watches it plummet to the floor.)
Mr. Praline: Now that's what I call a dead reference model.
Owner: No, no.....No, 'e's stunned!
Mr. Praline: STUNNED?!?
Owner: Yeah! You stunned him, just as he was wakin' up! Norwegian Blues stun easily, major. They insist on 9.6 microsecond idle time between 802.3 10Base5 frames.
Mr. Praline: PININ' for the FJORDS?!?!?!? What kind of talk is that?, look, why did he fall flat on his back the moment I got 'im home?
Owner: The Norwegian Blue prefers keepin' on it's back! Remarkable bird, id'nit, squire? Lovely plumage!
Mr. Praline: Look, I took the liberty of examining that parrot when I got it home, and I discovered the only reason that it had been sitting on its perch in the first place was that it had been NAILED there. (Nailed circuits are defined in the ISDN basic rate interface specification)_
Owner: No no! 'E's pining!
Mr. Praline: 'E's not pinin'! 'E's passed on! This model is no more! He has ceased to be! 'E's expired and gone to meet 'is committee! 'E's a stiff! Bereft of life, 'e

rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is logic processes are now 'istory! 'E's off the stack! 'E's not just kicked the bit bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' SYSLOG invisible!! THIS IS AN EX-PROTOCOL!! Howard C. Berkowitz 14:46, 9 May 2008 (CDT)