Following the lingering confusion of last week's lectures, and sensing that it might be a re-occuring predicament that I find myself in, I thought it would be a good idea to do as much terminology research as I could regarding any aspect of information technologies that I thought I would still be having a problem with. Which is a lot. I managed to get a sort of preliminary understanding of things that would commonly be found in discussions about the web. Things like HTML and XML and Javascript and API. I know have a book that is beginning to look like a glossary or dictionary because of all the terms I have written in there. And IP was one of the terms that I had looked up in this preliminary search.
IPs it would seem, are a lot more in-depth than what I originally perceived them to be. I managed quite easily to grasp the idea that you need an individual IP address for each individual device. I mean, look at humanity. Whilst we as humans are rather similar, we each have unique names that separate us from each other. Why shouldn't laptops, desktop computers, printers and iPads be the same? And I also understood what Prof. Long was talking about when he mentioned that the space being taken up by these unique addresses was running out and that we needed to expand that space in order to include more addresses. That's just logical.
But what really got me confused was when Prof. Long started talking about IP stacks and TCP/IP and how these all link together. It was just a lot for me to take in and to understand in what seemed to be a really short amount of time.
So again, I hit the research decks.
IP stands for Internet Protocol, that much is clear. As the principal set of rules of communication used for moving datagrams or network packets from one host to another (that is from one computer hooked up to a computer network, to another computer hooked up to a computer network) across the Internet, using the IP suite, which we'll come back to later, the primary role of the IP is to determine what networks are connected to which other networks as a part of the Internet. In knowing which networks link with which other networks, IP can figure out the routing paths along which these datagrams can be sent.
A brief interlude from IP while we talk about datagrams.
I think that I could grasp the general feel of datagrams, enough to put them into simpler terms for myself to understand at least. A datagram is comprised of two parts, the first of these being a sort of label, called a header, in which the identifiable information is stored and which means that routing can take place without any sort of preconceived knowledge regarding that datagram on the behalf of the network and the equipment. The second part is the data itself, the actual information that is being sent from one host to another.
So, at this point in time, we can see that the datagram is within the IP. And that the IP's job is to work with addressing, figuring out what the unique IP address is, figuring out what is within the datagram and then figuring out which networks to use to send that datagram along to get to the host it's labelled for. We can also see that the IP is a part of the Internet Protocol Suite.
But "What is the IP suite?" I hear you say (in a tone that suggests you just stopped tearing your hair out with your hands in exasperation long enough to hear me).
Well, again, doing that little extra bit of researching worked to locate a couple of little things that could help me.
First of all, the Internet Protocol Suite is often referred to as TCP/IP, because the original program (the Transmission Control Program of 1974) included both IP and Transmission Control Protocol (TCP), which is still widely used today, although not by all devices. TCP/IP determines five things about data: how it should be formatted, addressed, transmitted, routed and received at the destination. To do this, the suite has four layers that are each individually governed by their own rules. Like I said, each layer is individual, or abstracted, which means that via the process of encapsulation, the stack is divided into the four components. What the process of encapsulation does is determine which functions of a particular layer are different from the functions of the other layers either by inclusion or information hiding (which is when the aspects of a design that are most susceptible to change are separated from aspects that can not be changed or else risk facing complete destruction) such that a sort of ranking of the layers can be made, determinate of the more abstracted being at the top of the stack and the more specific being at the bottom (referred to as the upper layer protocol and lower layer protocol respectively). Each higher layer adds more features.
The lowest of the TCP/IP layers is the link layer. Also called the ethernet, this layer contains the communication technology for a local network, which is a smaller computer network mainly for computers at home or school.
The next layer is the internet layer, which is where IP addresses come into play, connecting local networks together and consequently establishing internetworking.
Following this we have the transport layer, handling all host-to-host communication.
Finally, at the very top of the protocol stack we have the application layer, where all the protocols for specific data communications services on a process-to-process level are contained. It is here that the protocol for how a browser communicates with a web server is determined.
And so, after all of that research, that is the point at where I realised the power that this blog had. By enabling me to go back and kind of re-think the work that had been done in the lecture (on both my behalf as a listener, and on Prof. Long's behalf as a lecturer) I was able to understand better some of the terminology and what was being discussed. I am in no ways implying that I definitely understand everything. Still a lot of it goes flying over my head, but the point is that I can sort of grasp the concepts a little bit more. So before, when I viewed this blog as yet another tedious task intent on stealing all my spare time, I was certain that I would learn nothing from this except how to handle failure gracefully. Now I am thinking, perhaps "how to just pass with grace" might be a better song to sing.
Image available: http://internet-texpert.blogspot.com.au/2011/07/virtual-internet-protocol.html
No comments:
Post a Comment