Suppose that a third person joined the network by placing his hand on the rope, as illustrated here...
Now when you send a message, it is no longer obvious which of the other two parties is the intended recipient.
To help solve this problem, network engineers agreed a long time ago to give each connection on a network a name or a number. We refer to this as the station’s address. And every station on a network section needs to have a unique address. Of course, as computers evolved and as networks grew, it became commonplace to have more than two or three computers on a network segment. Some segments have hundreds. Back in the earliest days of network evolution, designers agreed that when they are sending a message on a network that has multiple recipients like this, every message would be divided up into sections, and at the beginning of each section, the address of the intended recipient would be transmitted.
This system works a lot like an old telegraph. Back in the days of the telegraph, when a message had to be sent, at the very beginning the telegrapher would include Morse code to say something like: “Message for Salt Lake City, from Denver.” The beginning of every telegraph message always had that kind of addressing information in it, and it was convenient so that the telegrapher in St. Louis could just go to sleep for a while after he saw that there was a message for Salt Lake City from Denver that he could ignore.
There are so many similarities between Ethernet messages and telegrams that it’s worthwhile examining the way telegrams were put together. First, the telegraph operator would transmit the destination address: some description of the telegraph station that was expected to receive the message. Secondly, the telegrapher would send his own location, so people would know from whom the message came: the “sending address.” Next would come the main body of the message, the sentences and the punctuation and text for which the customer paid a fee to comprise the message. And finally, after the main body of the text, the telegrapher would send some kind of a sign-off message saying: “This is Denver. That’s the end of the message. Signing off for now.” Of course, if the main body of the text was just too darn long, the telegraph company might encourage the customer to send two separate telegrams and send it in two separate messages, each of which would follow this same general format.
With a simple little diagram like this one, which is read from left to right, just like a sentence on a piece of paper, we can examine the way an Ethernet message is built up. Ethernet messages follow that same general format. A single Ethernet message is often called an “Ethernet frame,” and if any given Ethernet message is long and complex, or represents a lot of information or spans a lot of time, that message is divided up into separate short individual frames, and each of those little frames follows the same general format.
Within each Ethernet frame, the individual pieces are called “fields.” The first important field within an Ethernet frame is called the destination address. It’s just like a telegram. It tells you to whom the message is intended. The second important field in each Ethernet frame is the “source address,” or a description of the person or station sending the message; again, just like an old telegram. The third important field is the main body of the text; once again, just like a telegram.
Ethernet can handle many different kinds of messages, and an elaborate system of fields and subfields has evolved over the years within this message field. In later movies, we’ll study the way different kinds of messages can be formatted or encapsulated within the message field. In fact, messages can hold messages inside messages, but we’re going to ignore all of that for right now because we want to keep this diagram simple.
In Ethernet framing, the fourth field (the last field shown in the diagram above) is a little more sophisticated than telegrams. Instead of just saying “over” or “stop” or “end of message,” Ethernet designers found it’s useful to include some kind of error checking information. So, for example, they’ll include a little description of the message just sent. The descriptions are mathematical in nature but we don’t need to do the math. Think of it this way: suppose you just received a message, and after receiving it, the sender said to you, “OK. There should be 310 characters. Of those 310 characters, 152 should consist of even binary numbers and 158 should consist of odd binary numbers, and if you add up all the binary numbers, the last four digits should be 0152. If your copy doesn’t match this description let me know and I’ll send it again.”