Protocol of the Week

My original motivation for joining the DevCentral blogging community was an idea for a weekly blog post titled "Protocol of the Week".  The idea spawned from the desire to become acquainted with the protocols that govern modern day networking, from the small Local Area Network to the Internet itself.  A significant part of my work rests on these protocols and their impact on inter-computer communication, so the benefit to me for learning all I can about them is clear.  However, I knew that simply reading about them in books, blog posts, articles, and the RFCs (Request for Comment...the official protocol documentation) would lead to a lonely and dreary road of learning.  The obvious solution: Reach out to and engage with the Web 2.0 community, and this is the perfect place for it.

So each week I'm going to pick a protocol and write a short, high level piece on that protocol's origins, purpose, evolution, and (since I do work at F5 after all) how F5's products, specifically BIG-IP, handle/manipulate that protocol.

Now my call to the readers:

• At the end of each post, I will say what protocol I will be learning about next so that I may invite readers to suggest resources for research.  If you know some great article about the upcoming protocol, please, please share it with me via e-mail or with everyone via a blog comment.
• I am no expert on networking protocols.  As I said, this is a learning endeavor on my part, and though I will be careful with my research, inevitably I will say something not quite accurate or flat out wrong.  Thus I ask that you be (positively) critical of my work and let me know if you spot mistakes.  I would hate to misguide my learning and that of others.
• If you have any feedback on the way I present this blog or its content, or you are dying to learn about some protocol, definitely let me know. 

Finally, I'd like to finish by briefly answering the question, "What exactly is (and isn't) a protocol?".  When someone goes to the bank to withdraw money, for example, they approach a teller and make their request.  The teller then asks for the account number and a form of identification.  They then pull up the account on their computer and verify that the identification matches the owner of the account.  The teller also needs to make sure that there is enough money left in the account to satisfy the request.  Assuming this is so, the teller makes the transaction and pulls out the appropriate amount of cash.  Finally, the teller counts the cash in front of the patron and hands them a receipt with their money.  People may not know this, but in doing this whole process, they are partaking in a protocol.  A protocol is a step-by-step outline on how to accomplish a particular task.  In this case the protocol's goal was a cash withdrawal from a bank account.  This particular example could get more complicated when you include all that happens behind the scenes in the computer software that is run to perform the actual transaction.

The Internet operates on a very large set of protocols, where each protocol defines how a particular networking task is accomplished.  IP (Internet Protocol) defines how nodes on the Internet are uniquely addressed and how data is routable between these nodes.  TCP (Transmission Control Protocol) works on top of IP and defines a method for providing a reliable data stream between two nodes on the Internet.  HTTP (HyperText Transfer Protocol) works on top of TCP and defines how web pages and other data is transferred.  As noted, protocols sometimes use one another and therefore form a stack.  The most common categorization of this stack is called the OSI model.  Together these protocols provide a standard by which varyin g software and hardware packages can communicate with each other over a network.  Not all sets of protocols, however, are compatible.  The ones listed above, and any those that are compatible with them, are called "IP-based" protocols and are the most popular today.

My last point is that protocols, though they define steps for accomplishing certain networking tasks, do NOT define exactly how those tasks should be done.  How software and hardware execute these protocols is called the protocol's implementation, and this varies from system to system.  Linux and Windows, though they both support IP-based networking and are able to communicate with one another, have different code and varying parameters that get the job done.  The standards only dictate enough information to guarantee interoperability between varying implementations.

That's it, and I hope you stay tuned next Friday for our first protocol:  ARP (Address Resolution Protocol), which is a cornerstone of IP-based networking.

Have a great weekend!