Networking Overview

Networking is about communicating with applications on other systems. The communication happens by sending messages. Messages can be sent to a single system where a connection is initiated before the message, as shown in Figure 29-1, or messages can be sent to multiple systems by a broadcast, as shown in Figure 29-2. With a broadcast, connections are not initiated, the messages are just sent to the network instead.

Figure 29-1

Figure 29-2

Networking can be best illustrated by showing the seven OSI layers. Figure 29-3 shows the stack of the OSI layers with their corresponding TCP/IP layers. Often the layers are also defined by numbers that are simply increments of the layers from bottom, where the physical layer is number 1, to the top, where the application layer is number 7.

Figure 29-3

The lowest OSI layer is the physical layer. At the physical layer, physical devices (such as networking cards and cables) are defined. The data link layer accesses the physical network with physical addresses. The data link layer performs error correction, flow control, and hardware addressing. The address of your Ethernet network card shows up when you use the ipconfig /all command, as shown in Figure 29-4. The system shown here has the MAC address 00-04-23-83-D1-BB.

Figure 29-4

The network layer uses a logical address to address systems in a WAN. The Internet Protocol (IP) is a layer 3 protocol; at layer 3, an IP address is used to address other systems. In IPv4, the IP address consists of 4 bytes, for example 192.14.5.12.

The transport layer is used to identify the applications that communicate. The applications can be identified by endpoints. The server application waiting for clients to connect has a known endpoint to connect to. Both the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are layer 4 protocols that use a port number (the endpoint) to identify an application. The TCP protocol is used for reliable communication, in which a connection is set up before data is sent, while with the UDP protocol communication is unreliable, because data is sent without a guarantee that it will be received.

Above layer 4, the OSI layers define a session, presentation, and application layer. The session layer defines services for an application, such as logging in to and out of an application. The session layer enables a virtual connection between applications. You can compare this with ASP.NET sessions discussed in Chapter 18. The presentation layer is about data formatting — within this layer encryption, decryption, and compression can happen. Finally, the application layer is the highest layer to offer networking features to applications, such as file transfers, e-mail, Web browsing, and so on.

With the TCP/IP protocol suite, the application-level protocols cover layers 4 to 7 of the OSI layer model. A few examples of these protocols are HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), and SMTP (Simple Mail Transfer Protocol). At the transport layer, endpoints are used to reach other applications; these application protocols define how the data that is sent to the other system looks. You will see later on what data is sent with HTTP.

Name Resolution

The Internet protocol requires IP addresses. Because the IP addresses aren't easy to remember (this is even more difficult with IPv6, where the IP address consists of 128 bits instead of 32 bits), a hostname is used. For communication between the systems, however, the IP address is required, as was discussed earlier. To map the hostname to the IP address, Domain Name System (DNS) servers are used. Figure 29-4 shows that the DNS servers with the IP addresses 192.168.0.10 and 195.202.128.2 are used by this system.

Windows has a command-line tool, nslookup, that can do name lookups (resolve IP addresses from host- names), or reverse lookups (resolve hostnames from IP addresses). Reverse lookups are interesting because by analyzing the log files where the IP address of client systems can be found, you can determine the origin of the client system.

With .NET, you can perform name lookups with the Dns class in the System.Net namespace. With the Dns class, a hostname can be resolved to its IP addresses, or an IP address can be resolved to its host- name. Let's try it out with a simple project.

Try It Out – Using DNS

1. Create a new C# console application project named DnsLookup in the directory C:\ BegVCSharp\Chapter29.

2. Import the namespace System.Net.

3. Invoke the GetHostEntry() method of the Dns class, as shown here, after checking the arguments from the Main() method.

   static void Main(string[] args) { if (args.Length !=  1) { Console.WriteLine("Usage: DnsLookup hostname/IP Adddress"); Console.ReadLine(); return; } IPHostEntry ipHostEntry = Dns.GetHostEntry(args[0]); 

4. Add the following code to the Main() method that follows the call to the GetHostEntry() method to write information about the resolved host to the console.

    Console.WriteLine("Host: {0}", ipHostEntry.HostName); if (ipHostEntry.Aliases.Length > 0) { Console.WriteLine("\nAliases:"); foreach (string alias in ipHostEntry.Aliases) { Console.WriteLine(alias); } } Console.WriteLine("\nAddress(es):"); foreach (IPAddress address in ipHostEntry.AddressList) { Console.WriteLine("Address: {0}", address.ToString()); } }

5. Compile the application and start the program. Pass a hostname as command-line argument, for example www.microsoft.com. To start it from Visual Studio you can set the command-line arguments with the Debug configuration, as shown in Figure 29-5. You can also start a command prompt, change to the directory of the executable, and start the application with dnslookup www.microsoft.com. You should get output that looks similar to that shown in Figure 29-6.

   
   Figure 29-5

   
   Figure 29-6

How It Works

The Dns class queries the DNS server to resolve hostnames to IP addresses and to do reverse lookups to get a hostname from an IP address. To do this, the Dns class uses the GetHostEntry() method, with which you can pass a hostname and an IPHostEntry will be returned. For reverse lookups, the GetHostByAddress() method can be called.

In all cases the Dns class returns an IPHostEntry. This class wraps information about a host. the IPHostEntry class has three properties: HostName returns the name of the host, Aliases returns a list of all alias names, and AddressList returns an array of IPAddress elements. the ToString() method of the IPAddress class returns the Internet address in a standard notation.

Uniform Resource Identifier

The resources that can be accessed across the network are described by a URI (Uniform Resource Identifier). You are using URIs every day when you enter Web addresses, such as http://www.thinktecture.com, in your Web browser. The class Uri encapsulates a URI and has properties and methods for parsing, comparing, and combining URIs.

A Uri object can be created by passing a URI string to the constructor:

 Uri uri = new Uri("http://www.wrox.com/go/p2p"); 

If you go to different pages on the same site, you can use a base URI and construct out of it URIs that contain the directories:

 Uri baseUri = new Uri("http://msdn.microsoft.com"); Uri uri = new Uri(baseUri, "downloads"); 

You can access parts of the URI by using properties of the Uri class. Let's look at a few examples of what you can get out of an Uri object that is initialized with the URI http://www.wrox.com/marketbasket.cgi?isbn=0764557599.

Uri Property	Result
Scheme	http
Host	www.wrox.com
Port	80
LocalPath	/marketbasket.cgi
Query	?isbn=0764557599

TCP and UDP

Now that you know how to get an IP address from a hostname, you're ready to step into the functionality of the TCP and UDP protocols. Both TCP and UDP are transport-layer protocols, as you saw in Figure 29-3. Both of these protocols use a port number to identify the application that's to receive the data. The TCP protocol is connection-oriented, while the UDP protocol is connectionless.

The TCP protocol requires the server application to create a socket with a well-known port number, so that the client application can connect to the server. The client creates a socket with a freely available port number. When the client connects to the server, the client passes its port number to the server so that the server knows the path to the client. After the connection is established, the client can send data that is received by the server, and then the server can send some data that is received by the client. Of course, sending and receiving can also happen the other way around. With the QOTD (quote of the day) protocol (a QOTD server is part of the Windows component Simple TCP/IP Services) the server just sends some data after the client connects, and closes the connection.

The UDP protocol is similar in so far as the server must create a socket with a well-known port number, and the client uses a freely available port number. The difference is that the client doesn't initiate a connection. Instead, the client can send the data without doing a connection first. Without a connection there's no guarantee that the data is received at all, but the overall transfer is faster. The UDP protocol has the big advantage that broadcasts can be done with it — sending information to all systems in the LAN by using a broadcast address.

Note

Broadcast addresses are IP addresses where all bits of the host part of the IP address are set to 1.

Application Protocols

Let's look at application protocols that make use of TCP or UDP. HTTP is an application protocol that is layered on top of TCP. The HTTP protocol defines the message that is sent across the network. Using the HTTP protocol to request data from a Web server, a TCP connection is opened, and then an HTTP request is sent. An example of an HTTP request initiated by a browser looks like this:

GET /default.aspx HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,  application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* Accept-Language: de-at,en-us;q=0.7 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50110) Host: localhost:80 Connection: Keep-Alive

This sample request shows a GET command. Some of the mostly frequently used HTTP commands are GET, POST and HEAD. GET is used to request a file from the server. With the POST command a file is requested from the server, too. However, unlike the GET command, with the POST command additional data is sent after the HTTP header. With the HEAD command the server only returns the file's header information, so that the client can determine whether the file is different from data that is already in the cache.

The GET command requests the file on the server. Here, the server should return the file /default.aspx. the last section of the first line defines the HTTP version. If both the client and server support version 1.1, this version will be used for the communication. Otherwise, HTTP 1.0 is used. With HTTP 1.1 it is possible to keep the same connection (see the HTTP header information Connection: Keep-Alive).

After the first line of the request with the GET command, HTTP header information follows. The browser sends information about the browser with the request. In the example, you can see the Accept information where mime types of supported programs are sent. the Accept-Language header defines the languages that are configured on the browser. The server can use this information to return different information to the client, depending on the supported files and languages. With the User-Agent header the browser sends information about the client application used to request the page from the server. Here, Internet Explorer 6.0 is used with Windows XP. Windows XP has the identifier Windows NT 5.1. The server can also read if the .NET runtime is installed on the client system. Here, both .NET 1.1 and .NET 2.0 show up as supported .NET versions.

After the server receives a GET request, a response message is returned. An example of a response message is shown here. If the request is successful, the first line of the response shows an OK status and the HTTP version used. Then HTTP header information follows, which includes the Server, the Date, and the Content-Type and the length that follows the header. The header and the content are separated by two lines.

HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Sun, 12 Sep 2004 20:14:59 GMT X-Powered-By: ASP.NET X-AspNet-Version: 1.1.4322 Cache-Control: private Content-Type: text/html; charset=utf-8 Content-Length: 991         <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > <HTML>  <HEAD>   <title>Demo</title>

You can easily simulate an HTTP request by using the Telnet utility that you will do with the next Try It Out.

Try It Out – Simulate a HTTP Request

1. Start the telnet client by typing telnet.exe at a command prompt. The prompt Microsoft Telnet> appears.

2. To see the commands you type and send to the server, enter set localecho in the Telnet session.

3. Create a connection to the Web server in your LAN. If you have a Web server on the local system, enter open localhost 80. 80 is the default port number used with the Web server.

4. Send a request to the Web server by typing the command GET / HTTP/1.1, then press the Return key twice. With the / the default page from the server is returned, for example default.htm. Instead of using the /, you can also request specific filenames. Sending two newline characters marks the end of the transmission. Now, you get a response from the server that looks similar to the response shown earlier.