tailieunhanh - Internetworking with TCP/IP- P22

Internetworking with TCP/IP- P22: TCP/IP has accommodated change well. The basic technology has survived nearly two decades of exponential growth and the associated increases in traffic. The protocols have worked over new high-speed network technologies, and the design has handled applications that could not be imagined in the original design. Of course, the entire protocol suite has not remained static. New protocols have been deployed, and new techniques have been developed to adapt existing protocols to new network technologies | 178 Protocol Layering Chap. 11 Hardware failure. A host or router may fail either because the hardware fails or because the operating system crashes. A network transmission link may fail or accidentally be disconnected. The protocol software needs to detect such failures and recover from them if possible. Network congestion. Even when all hardware and software operates correctly networks have finite capacity that can be exceeded. The protocol software needs to arrange ways that a congested machine can suppress further traffic. Packet delay or loss. Sometimes packets experience extremely long delays or are lost. The protocol software needs to learn about failures or adapt to long delays. Data corruption. Electrical or magnetic interference or hardware failures can cause transmission errors that corrupt the contents of transmitted data. Protocol software needs to detect and recover from such errors. Data duplication or inverted arrivals. Networks that offer multiple routes may deliver data out of sequence or may deliver duplicates of packets. The protocol software needs to reorder packets and remove any duplicates. Taken together all the problems seem overwhelming. It is difficult to understand how to write a single protocol that will handle them all. From the analogy with programming languages we can see how to conquer the complexity. Program translation has been partitioned into four conceptual subproblems identified with the software that handles each subproblem compiler assembler link editor and loader. The division makes it possible for the designer to concentrate on one subproblem at a time and for the implementor to build and test each piece of software independently. We will see that protocol software is partitioned similarly. Two final observations from our programming language analogy will help clarify the organization of protocols. First it should be clear that pieces of translation software must agree on the exact format of data passed between them. For .