An Overview of Network Communication
| I l @ ve RuBoard |
| We live in an increasingly networked world. From our computers to our cell phones, the Internet (including custom intranets ) is becoming almost unavoidable. This means, of course, that the importance of communicating over these networks is more important and necessary than ever. Technologies such as remoting and XML Web services provides high-level distributed communication frameworks, but they are not the complete solution. Besides, those technologies must at some point be implemented, and that involves using a lower-level communications protocol. (They are both built on TCP/IP, after all.) Network ArchitecturesBefore we get into too much detail, we should take a step back and look at what role network architectures play into today's applications. There are effectively two types of communication architectures in common use today:
The vast majority of applications are based on the client/server application architecture. Web-based applications are a client/server model. A client/server model is typically a centralized networking architecture with communication in only one direction. (See Figure 6-1.) Applications that fall into this category include e-mail server, Web server, database server, and Telnet. Figure 6-1. The client/server application architecture. The traditional client/server model has been challenged in recent years by the popular peer-to-peer (P2P) networks. Peer-to-peer communication architectures have been around for years . The earliest P2P networks in wide use were based on the AppleTalk networking protocol; these were closely followed by the SMB protocol used by Microsoft for Windows file sharing. Unfortunately, neither of these technologies is suitable for large-scale (such as Internet-scale) P2P networks. Napster and all of the subsequent P2P file-sharing networks heralded a much more sophisticated form of P2P network ”one that allowed true online communities to be built. These P2P networks are based on the idea that each computer represents a communications node within the network. In many ways, these nodes provide functionality and additional robustness to the network they join. In true P2P networks ”see Figure 6-2 ”nodes communicate directly with other nodes on the network, forming a weblike structure (that's web as in spider, not browser). Nodes continually come on line and drop off, but the network maintains itself by requiring each node (computer) to maintain links to multiple clients . This creates a robust network that does not have a single failure point. Note In terms of a distributed architecture, the Napster P2P network did not have a strict P2P architecture because it had a single failure point. Napster maintained a set of central servers that held song indexes and user lists. File transfers happened in a P2P fashion, but the server was needed to find the peers with the desired content. This was the architectural Achilles' heel of the Napster network ”you take out the servers, and the network is toast . Figure 6-2. The P2P network architecture. Application architectures can be tricky to define. Rarely are applications a pure form of one architecture or another. Increasingly, we see applications that are a distinct mixture of the two, and that's probably a good thing. Mixing the Client/server and P2P architectures allows a great deal of flexibility when your development requirements allow it. Communications ProtocolsProtocols in the computer world are the basic rules of communication between two devices, or endpoints. You can think of the English language as a protocol of sorts; You have greetings , phrases, questions, and, most important, interaction. Protocols define how you communicate and in what language. Protocols can be built off of other protocols (forming compound protocols), and they can flexible or rigid. It's all up to the originator of the protocol. Probably the most common protocol in use today is HTTP, the backbone of the World Wide Web. HTTP is built on the foundation of TCP, which is, in turn , based on IP. Figure 6-3 illustrates how some of the network protocols build off each other. Figure 6-3. Sample hierarchy of IP network communication protocols. More Info For more details about network architectures and communications, consult the Open Systems Interconnection (OSI) routing protocol documentation at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/osi_prot.htm. To give you a better understanding of how some of these protocols interact, we'll first look at IP and at the two most common IP-based protocols in use today. The IP ProtocolIP is the protocol by which all data is sent on the Internet. Each computer, or host, on the Internet has at least one IP address. This address uniquely identifies the host among all other hosts on the network. For two devices to communicate, both the sender and recipient IP addresses must be known in advance. These two IP addresses constitute the two endpoints of the communications link. Communication between these two endpoints is done in a connectionless fashion. The sender does not open a connection to the recipient; rather, it sends a set of "packets" to the recipient that the recipient can either accept or refuse . All data that are sent or received over the Internet is first divided into these packets, which contain both the sender's and recipient's Internet addresses. As a packet is sent out, it hits a gateway computer. This gateway determines where to send that packet (usually to another gateway). Each packet makes a series of hops, from gateway to gateway, until it reaches a gateway that is responsible for the recipient machine's address space. This final gateway forwards the packet directly to the computer designated as the recipient in the packet. Because messages are divided into many packets, it is possible, and even desirable, for each packet to trace a different route across the Internet. This can mean that packets arrive in a different order than the order in which they were sent. IP doesn't care ”all it cares about is delivering the packets. It's usually the job of another protocol built on top of IP, typically TCP, to restore the packets to their original order. IPv4 vs. IPv6It shouldn't be surprising that there are different versions of the IP protocol. The version of IP that is most widely used today is version 4 (IPv4). The problem with IPv4 is that the address space is limited, leading to a shortage of addresses. To the rescue comes version 6 of the IP protocol (IPv6). IPv6 provides support for many more IP addresses, which is crucial as more and more devices are connected to the Internet. The IPv6 protocol is a functional superset of IPv4; by extension, any device that supports IPv6 packets can also support IPv4 packets. Note Support for IPv6 was introduced to the .NET Framework in version 1.1, which was included in the Microsoft Visual Studio .NET 2003 release. IP-Based ProtocolsA low-level protocol such as IP isn't really that much fun. It's very lightweight, but it requires you to do an awful lot of work. Thankfully, you'll rarely need to deal with IP at all. Instead, you'll deal with two common protocols that are based on IP:
Most network applications use the TCP protocol (TCP over IP, or TCP/IP). The UDP protocol has found its use in several kinds of applications, most notably multiplayer gaming systems. TCPTCP is considered a connection-oriented protocol. This means a connection is established and maintained until the information to be exchanged between endpoints has been transferred. TCP is a protocol built on IP to send data between computers. IP handles the actual delivery of the data, while TCP handles breaking down the data into packets for transmission and reordering and reassembling packets upon receipt. For example, when you request a Web page from a server, the TCP layer in that server divides the page into one or more packets, numbers the packets, and then forwards them individually to the IP layer. Recall that although each packet has the same destination IP address, it might travel a different route through the network. At the other end (your Web browser), the TCP layer reassembles the individual packets and waits until they have all arrived before forwarding them to your browser as a complete Web page. UDPUDP provides significantly fewer features than TCP. UDP is considered an alternative to TCP. Like TCP, UDP uses IP to transmit packets from one endpoint to another. Unlike TCP, however, UDP does not provide the service of dividing a message into packets or reassembling and reordering them at the other end. In other words, UDP doesn't provide any facility for maintaining proper sequencing of IP packets. This means that an application that uses UDP is responsible for ensuring that the entire message has arrived and in the correct order. Applications that want to save processing time might favor UDP over TCP. Typically, applications benefit from UDP if they have very small amounts of data to exchange (and therefore little reassembling to do at the other end). UDP does provide two services not provided by the IP layer. To start with, UDP provides port numbers to help distinguish different user requests . Second, it provides an optional checksum capability to verify that the data arrived intact. Pluggable ProtocolsA tremendous number of protocols run over TCP/IP. Only the most common ones have been provided with the first revisions of the .NET Framework. Given that you might need to communicate using a protocol that has not be provided, it seems reasonable that you would want to write your own communication layer. Taking this a step further, it would be desirable to have a single object model that could be used for multiple protocols. The WebRequest and WebResponse classes are the .NET Framework classes that provide the basis for pluggable protocols in the .NET Framework. In my opinion, the WebRequest and WebResponse classes are poorly named. They are designed as abstract classes ( MustInherit ) that are designed to make a request to a give Uniform Resource Identifier (URI). These classes do not need to be specifically tied to a requests using the HTTP protocol. In fact, you can specify additional protocol handler classes (create your own or share with your buddies ) or override existing handlers.
The .NET Framework supports only three URI protocols out of box for the WebRequest mechanism: http, https , and file. The Machine.config file contains the following definitions for the webRequestModules object in the <system.net> section: <webRequestModules> <addprefix="http" type="System.Net.HttpRequestCreator" /> <addprefix="https" type="System.Net.HttpRequestCreator" /> <addprefix="file" type="System.Net.FileWebRequestCreator" /> </webRequestModules> You're not limited to just these default protocols. You're free to add your own webRequestModules . For example, you can easily add support for File Transfer Protocol (FTP). In the current version of the .NET Framework, if you try to pass a URI with the FTP protocol, you'll get a NotSupportedException . However, creating an FTP webRequestModule is easy. On the other hand, implementing it might not be so easy. Regardless, you'll need to inherit your new classes from both the WebRequest and WebResponse classes and then register the new classes with the WebRequest.RegisterPrefix method. Alternatively, you can modify the App.Config file to specify your own handler. Typically, you'll distribute the App.Config file with the application, and you can have only your custom protocol in it rather than make it globally available on your machine. (This is exactly what would happen if you added the handler to the machine.config file.) |
| I l @ ve RuBoard |
EAN: 2147483647
Pages: 103