Lower-Level Protocols
This section briefly discusses some of the .NET classes used to communicate at a lower level.
Network communications work on several different levels. The classes you have seen in this chapter so far work at the highest level: the level at which specific commands are processed. It is probably easiest to understand this concept if you think of file transfer using FTP. Although today’s GUI applications hide many of the FTP details, it was not so long ago when you executed FTP from a command-line prompt. In this environment, you explicitly typed commands to send to the server for downloading, uploading, and listing files.
FTP is not the only high-level protocol relying on textual commands. HTTP, SMTP, POP, and other protocols are based on a similar type of behavior. Again, many of the modern graphical tools hide the transmission of commands from the user, so you are generally not aware of them. For example, when you type a URL into a Web browser, and the Web request goes off to a server, the browser is actually sending a (plain-text) GET command to the server, which fulfills a similar purpose as the FTP get command. It can also send a POST command, which indicates that the browser has attached other data to the request.
However, these protocols are not sufficient by themselves to achieve communication between computers. Even if both the client and the server understand, for example, the HTTP protocol, it will still not be possible for them to understand each other unless there is also agreement on exactly how to transmit the characters: What binary format will be used? And getting down to the lowest level, what voltages will be used to represent 0s and 1s in the binary data? Because there are so many items to configure and agree upon, developers and hardware engineers in the networking field often refer to a protocol stack. When you list all of the various protocols and mechanisms required for communication between two hosts, you create a protocol stack with high-level protocols on the top and low-level protocols on the bottom. This approach results in a modular and layered approach to achieving efficient communication.
Luckily, for most development work, you don’t need to go far down the stack or work with voltage levels, but if you are writing code that requires efficient communication between computers, it’s not unusual to write code that works directly at the level of sending binary data packets between computers. This is the realm of protocols such as TCP, and Microsoft has supplied a number of classes that allow you to conveniently work with binary data at this level.
Lower-Level Classes
The System.Net.Sockets namespace contains the relevant classes. These classes, for example, allow you to directly send out TCP network requests or to listen to TCP network requests on a particular port. The following table explains the main classes.
| Class | Purpose |
|---|---|
| Socket | Low-level class that deals with managing connections. Classes such as WebRequest, TcpClient, and UdpClient use this class internally. |
| NetworkStream | Derived from Stream. Represents a stream of data from the network. |
| TcpClient | Enables you to create and use TCP connections. |
| TcpListener | Enables you to listen for incoming TCP connection requests. |
| UdpClient | Enables you to create connections for UDP clients. (UDP is an alternative protocol to TCP but is much less widely used, mostly on local networks.) |
Open table as spreadsheet
Using the TCP Classes
The Transmission Control Protocol (TCP) classes offer simple methods for connecting and sending data between two endpoints. An endpoint is the combination of an IP address and a port number. Existing protocols have well-defined port numbers, for example, HTTP uses port 80, while SMTP uses port 25. The Internet Assigned Number Authority, IANA, (www.iana.org) assigns port numbers to these wellknown services. Unless you are implementing a well-known service, you will want to select a port number above 1,024.
TCP traffic makes up the majority of traffic on the Internet today. TCP is often the protocol of choice because it offers guaranteed delivery, error correction, and buffering. The TcpClient class encapsulates a TCP connection and provides a number of properties to regulate the connection, including buffering, buffer size, and timeouts. Reading and writing is accomplished by requesting a NetworkStream object via the GetStream() method.
The TcpListener class listens for incoming TCP connections with the Start() method. When a connection request arrives, you can use the AcceptSocket() method to return a socket for communication with the remote machine, or use the AcceptTcpClient() method to use a higher-level TcpClient object for communication. The easiest way to see how the TcpListener and TcpClient classes work together is to work through an example.
The TcpSend and TcpReceive Examples
To demonstrate how these classes work, you need to build two applications. Figure 35-11 shows the first application, TcpSend. This application opens a TCP connection to a server and sends the C# source code for itself.
Figure 35-11
Once again you create a C# Windows application. The form consists of two text boxes (txtHost and txtPort) for the host name and port, respectively, as well as a button (btnSend) to click and start a connection. First, you ensure that you include the relevant namespaces:
using System; using System.IO; using System.Net.Sockets; using System.Windows.Forms; The following code shows the event handler for the button’s Click event:
private void btnSend_Click(object sender, System.EventArgs e) { TcpClient tcpClient = new TcpClient(txtHost.Text, Int32.Parse(txtPort.Text)); NetworkStream ns = tcpClient.GetStream(); FileStream fs = File.Open(Server.MapPath("form1.cs"), FileMode.Open); int data = fs.ReadByte(); while(data != -1) { ns.WriteByte((byte)data); data = fs.ReadByte(); } fs.Close(); ns.Close(); tcpClient.Close(); } This example creates the TcpClient using a host name and a port number. Alternatively, if you have an instance of the IPEndPoint class, you can pass the instance to the TcpClient constructor. After retrieving an instance of the NetworkStream class, you open the source code file and begin to read bytes. Like many of the binary streams, you need to check for the end of the stream by comparing the return value of the ReadByte() method to -1. After your loop has read all of the bytes and sent them along to the network stream, you make sure to close all of the open files, connections, and streams.
On the other side of the connection, the TcpReceive application displays the received file after the transmission is finished (see Figure 35-12).
Figure 35-12
The form consists of a single TextBox control, named txtDisplay. The TcpReceive application uses a TcpListener to wait for the incoming connection. To avoid freezing the application interface, you use a background thread to wait for and then read from the connection. Thus, you need to include the System.Threading namespace as well these other namespaces:
using System; using System.IO; using System.Net; using System.Net.Sockets; using System.Threading; using System.Windows.Forms; Inside the form’s constructor, you spin up a background thread:
public Form1() { InitializeComponent(); Thread thread = new Thread(new ThreadStart(Listen)); thread.Start(); } The remaining important code is this:
public void Listen() { IPAddress localAddr = IPAddress.Parse("127.0.0.1"); Int32 port = 2112; TcpListener tcpListener = new TcpListener(localAddr, port); tcpListener.Start(); TcpClient tcpClient = tcpListener.AcceptTcpClient(); NetworkStream ns = tcpClient.GetStream(); StreamReader sr = new StreamReader(ns); string result = sr.ReadToEnd(); Invoke(new UpdateDisplayDelegate(UpdateDisplay), new object[] {result} ); tcpClient.Close(); tcpListener.Stop(); } public void UpdateDisplay(string text) { txtDisplay.Text= text; } protected delegate void UpdateDisplayDelegate(string text); The thread begins execution in the Listen() method and allows you to make the blocking call to AcceptTcpClient() without halting the interface. Notice that the IP address (127.0.0.1) and the port number (2112) are hard-coded into the application, so you will need to enter the same port number from the client application.
You use the TcpClient object returned by AcceptTcpClient() to open a new stream for reading. Similarly to the earlier example, you create a StreamReader to convert the incoming network data into a string. Before you close the client and stop the listener, you update the form’s text box. You do not want to access the text box directly from your background thread, so you use the form’s Invoke() method with a delegate and pass the result string as the first element in an array of object parameters. Invoke() ensures that your call is correctly marshaled into the thread that owns the control handles in the user interface.
TCP versus UDP
The other protocol covered in this section is UDP (User Datagram Protocol). UDP is a simple protocol with few features but also little overhead. Developers often use UDP in applications where the speed and performance requirements outweigh the reliability needs, for example, video streaming. In contrast, TCP offers a number of features to confirm the delivery of data. TCP provides error correction and retransmission in the case of lost or corrupted packets. Last, but hardly least, TCP buffers incoming and outgoing data and also guarantees a sequence of packets scrambled in transmission is reassembled before delivery to the application. Even with the extra overhead, TCP is the most widely used protocol across the Internet because of its high reliability.
The UDP Class
As you might expect, the UdpClient class features a smaller and simpler interface than TcpClient. This reflects the relatively simpler nature of the protocol. Though both TCP and UDP classes use a socket underneath the covers, the UdpClient client does not contain a method to return a network stream for reading and writing. Instead, the member function Send() accepts an array of bytes as a parameter, and the Receive() function returns an array of bytes. Also, because UDP is a connectionless protocol, you can wait to specify the endpoint for the communication as a parameter to the Send() and Receive() methods, instead of specifying it earlier in a constructor or Connect() method. You can also change the endpoint on each subsequent send or receive.
The following code fragment uses the UdpClient class to send a message to an echo service. A server with an echo service running accepts TCP or UDP connections on port 7. The echo service simply echoes any data sent to the server back to the client. This service is useful for diagnostics and testing, although many system administrators disable echo services for security reasons:
using System; using System.Text; using System.Net; using System.Net.Sockets; namespace Wrox.ProCSharp.InternetAccess.UdpExample { class Class1 { [STAThread] static void Main(string[] args) { UdpClient udpClient = new UdpClient(); string sendMsg = "Hello Echo Server"; byte [] sendBytes = Encoding.ASCII.GetBytes(sendMsg); udpClient.Send(sendBytes, sendBytes.Length, "SomeEchoServer.net", 7); IPEndPoint endPoint = new IPEndPoint(0,0); byte [] rcvBytes = udpClient.Receive(ref endPoint); string rcvMessage = Encoding.ASCII.GetString(rcvBytes, 0, rcvBytes.Length); // should print out "Hello Echo Server" Console.WriteLine(rcvMessage); } } } You make heavy use of the Encoding.ASCII class to translate strings into arrays of byte and vice versa. Also note that you pass an IPEndPoint by reference into the Receive() method. Because UDP is not a connection-oriented protocol, each call to Receive() might pick up data from a different endpoint, so Receive() populates this parameter with the IP address and port of the sending host.
Both UdpClient and TcpClient offer a layer of abstraction over the lowest of the low-level classes: the Socket.
The Socket Class
The Socket class offers the highest level of control in network programming. One of the easiest ways to demonstrate the class is to rewrite the TcpReceive application with the Socket class. The updated Listen() method is listed in this example:
public void Listen() { Socket listener = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); listener.Bind(new IPEndPoint(IPAddress.Any, 2112)); listener.Listen(0); Socket socket = listener.Accept(); Stream netStream = new NetworkStream(socket); StreamReader reader = new StreamReader(netStream); string result = reader.ReadToEnd(); Invoke(new UpdateDisplayDelegate(UpdateDisplay), new object[] {result} ); socket.Close(); listener.Close(); } The Socket class requires a few more lines of code to complete the same task. For starters, the constructor arguments need to specify an IP addressing scheme for a streaming socket with the TCP protocol. These arguments are just one of the many combinations available to the Socket class, and the TcpClient class configured these settings for you. You then bind the listener socket to a port and begin to listen for incoming connections. When an incoming request arrives, you can use the Accept() method to create a new socket to handle the connection. You ultimately attach a StreamReader instance to the socket to read the incoming data, in much the same fashion as before.
The Socket class also contains a number of methods for asynchronously accepting, connecting, sending, and receiving. You can use these methods with callback delegates in the same way you used the asynchronous page requests with the WebRequest class. If you really need to dig into the internals of the socket, the GetSocketOption() and SetSocketOption() methods are available. These methods allow you to see and configure options, including timeout, time-to-live, and other low-level options. Next, this chapter looks at another example of using sockets.
Building a Server Console Application
Looking further into the Socket class, this next example will create a console application that acts as a server for incoming socket requests. From there, a second example will be created in parallel (another console application), which sends a message to the server console application.
The first application you will build is the console application that acts as a server. This application will open a socket on a specific TCP port and listen for any incoming messages. The code for this console application is presented in its entirety here:
using System; using System.Net; using System.Net.Sockets; using System.Text; namespace SocketConsole { class Program { static void Main() { Console.WriteLine("Starting: Creating Socket object"); Socket listener = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); listener.Bind(new IPEndPoint(IPAddress.Any, 2112)); listener.Listen(10); while (true) { Console.WriteLine("Waiting for connection on port 2112"); Socket socket = listener.Accept(); string receivedValue = string.Empty; while (true) { byte[] receivedBytes = new byte[1024]; int numBytes = socket.Receive(receivedBytes); Console.WriteLine("Receiving ..."); receivedValue += Encoding.ASCII.GetString(receivedBytes, 0, numBytes); if (receivedValue.IndexOf("[FINAL]") > -1) { break; } } Console.WriteLine("Received value: {0}", receivedValue); string replyValue = "Message successfully received."; byte[] replyMessage = Encoding.ASCII.GetBytes(replyValue); socket.Send(replyMessage); socket.Shutdown(SocketShutdown.Both); socket.Close(); } listener.Close(); } } } This example sets up a socket using the Socket class. The socket created uses the TCP protocol and is set up to receive incoming messages from any IP address using port 2112. Values that come in through the open socket are written to the console screen. This consuming application will continue to receive bytes until the [FINAL] string is received. This [FINAL] string signifies the end of the incoming message and the message can then be interpreted.
After the end of the message is received from a client, a reply message is sent to the same client. From there, the socket is closed using the Close() method and the console application will continue to stay up until a new message is received.
Building the Client Application
The next step is to build a client application that will send a message to the first console application. The client will be able to send any message that it wants to the server console application as long as it follows some rules that were established by this application. The first of these rules is that the server console application is only listening on a particular protocol. In the case of this server application, it is listening using the TCP protocol. The other rule is that the server application is only listening on a particular port - in this case, port 2112. The last rule is that in any message that is being sent, the last bits of the message need to end with the string [FINAL].
The following client console application follows all of these rules:
using System; using System.Net; using System.Net.Sockets; using System.Text; namespace SocketConsoleClient { class Program { static void Main() { byte[] receivedBytes = new byte[1024]; IPHostEntry ipHost = Dns.Resolve("127.0.0.1"); IPAddress ipAddress = ipHost.AddressList[0]; IPEndPoint ipEndPoint = new IPEndPoint(ipAddress, 2112); Console.WriteLine("Starting: Creating Socket object"); Socket sender = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); sender.Connect(ipEndPoint); Console.WriteLine("Successfully connected to {0}", sender.RemoteEndPoint); string sendingMessage = "Hello World Socket Test"; Console.WriteLine("Creating message: Hello World Socket Test"); byte[] forwardMessage = Encoding.ASCII.GetBytes(sendingMessage + "[FINAL]"); sender.Send(forwardMessage); int totalBytesReceived = sender.Receive(receivedBytes); Console.WriteLine("Message provided from server: {0}", Encoding.ASCII.GetString(receivedBytes, 0, totalBytesReceived)); sender.Shutdown(SocketShutdown.Both); sender.Close(); Console.ReadLine(); } } } In this example, an IPEndPoint object is created using the IP address of localhost as well as using port 2112 as required by the server console application. In this case, a socket is created and the Connect() method is called. After the socket is opened and connected to the server console application socket instance, a string of text is sent to the server application using the Send() method. Since the server application is going to return a message in return, the Receive() method is utilized to grab this message (placing it in a byte array). From there, the byte array is converted into a string and displayed in the console application before the socket is shut down.
Running this application will produce the results presented in Figure 35-13.
Figure 35-13
Reviewing the two console applications in the figure, you can see that the server application opens and awaits incoming messages. The incoming message is sent from the client application, and the string sent is then displayed by the server application. The server application waits for other messages to come in, even after the first message is received and displayed. You can see this for yourself by shutting down the client application and re-running the application. You will then see that the server application again displays the message received.
