This book will help you develop network applications with .NET, using either the C# (pronounced C-sharp) or VB.NET programming language. It is broken up into three distinct sections: networking basics, distributed application design, and specialized networking topics.
The first six chapters of the book cover the established Internet technologies, such as email and the World Wide Web. Leveraging established technologies such as these gives the general public greater access to your software service because most users will already have a Web browser or email client on their computers.
The next five chapters discuss network application design. This includes application security, performance, and scalability. Contained within these chapters is practical, hands-on advice to help improve the overall quality of your software. With tougher security, your applications will be less susceptible to theft of intellectual property and privileged information. The performance and scalability improvements described in this section will ensure that your application remains responsive even under the most extreme loads.
The specialized networking topics section provides a wealth of information about both niche and cutting-edge Internet technologies. These include chapters on telephony, packet capture, message queues, IPv6, and Microsoft’s latest offerings in the field of distributed application development: Web services and remoting.
One of the first technical decisions to be made whenever a new project is undertaken is what language to use. .NET is a capable platform on which to develop almost any solution, and it offers substantial support for network programming. In fact, .NET has more intrinsic support for networking than any other platform developed by Microsoft.
This book assumes that you have already decided to develop with .NET, and languages outside the .NET platform will not be discussed in any great detail, except for comparative purposes. This is not to say that .NET is the be-all and end-all of network-programming applications. If your application runs over a UNIX-only infrastructure communicating via Java remote method invocation (RMI), then .NET is not the way to go. In most circumstances, however, you will find that .NET is more than capable of handling whatever you throw at it.
A network program is any application that uses a computer network to transfer information to and from other applications. Examples range from the ubiquitous Web browser such as Internet Explorer, or the program you use to receive your email, to the software that controls spacecraft at NASA.
All of these pieces of software share the ability to communicate with other computers, and in so doing, become more useful to the end-user. In the case of a browser, every Web site you visit is actually files stored on a computer somewhere else on the Internet. With your email program, you are communicating with a computer at your Internet service provider (ISP) or company email exchange, which is holding your email for you.
This book is largely concerned with creating network programs, not Web sites. Although the capabilities of Web sites and network programs are quickly converging, it is important to understand the arguments for and against each system. A service accessed via a Web site is instantly accessible to users across many different platforms, and the whole networking architecture is ready-built for you; however, there is a point at which features are simply unfeasible to implement using Web sites and at which you have to turn to network applications.
Users generally trust network applications; therefore, these programs have much greater control over the computers on which they are running than a Web site has over the computers viewing it. This makes it possible for a network application to manage files on the local computer, whereas a Web site, for all practical purposes, cannot do this. More importantly, from a networking perspective, an application has much greater control over how it can communicate with other computers on the Internet.
To give a simple example, a Web site cannot make the computer that is viewing it open a persistent network connection to another computer (except the computer from which the Web site was served). This applies even when the Web site contains embedded content such as a Java applet or Flash movie. There is one exception to this rule, when executable content (such as an ActiveX control) is included in a page. In this case, the page is capable of everything a network program could do, but most browsers and antivirus software will warn against or deny such executable content. Therefore, this scenario is commonly accepted as being unfeasible because of public distrust.
Every computer that connects directly to the Internet must have a globally unique IP address. An IP address is a four-byte number, which is generally written as four decimal, period-separated numbers, such as 192.168.0.1. Computers that connect indirectly to the Internet, such as via their company network, also have IP addresses, but these do not need to be globally unique, only unique within the same network.
To find out what the IP address of your computer is, open a DOS console window and type IpConfig (Windows NT, 2000, and XP) or winIpcfg (Windows 95, 98, and ME).
In Figure 1.1, the PC has two IP addresses: 192.618.0.1 and 81.98.59.133. This is unusual because this particular PC contains two network cards and is connected to two different networks. Only one of those IP addresses is publicly accessible.
If you receive the IP address 127.0.0.1, your computer is not connected to any network. This IP address always refers to the local machine and is used in later examples.
In the same way that you can tell whether a phone number is local or international by looking at the prefix, you can tell whether the computer with that IP address is on the same local area network or somewhere else on the Internet by looking closely at an IP address. In the case of IP addresses, they are always the same length, but certain prefixes (192.168 being the most common) indicate that the computer is in a local area network, or intranet, and not accessible to the outside world.
If you share your Internet connection with other computers on your network, you may have a private IP address. These can be recognized as being within the IP address ranges listed in Table 1.1.
The same private IP address may exist on two computers in different local area networks (LANs). This does not cause a problem because neither computer can directly contact the other. Whereas a privately addressed computer can initiate a request for information from a foreign computer, no foreign computer can initiate a request for information from a privately addressed computer.
The exception to this rule would be where network address translation (NAT) or port forwarding is set up on the router that lies upstream of the privately addressed computer. This is where requests from foreign machines destined for the IP address of the router are forwarded to a designated computer behind the router. Responses from this computer are forwarded from the router back to the foreign machine that initiated the request. The benefits of such an architecture are security and the possibility for load balancing, which is described in more detail in later chapters.
All computers with private IP addresses must be connected to at least one computer or network router with a public IP address to access the Internet.
In order to ensure that no two computers on the Internet have the same IP address, there is a central regulatory body known as the Internet Assigned Numbers Authority (IANA), and more recently the Internet Corporation for Assigned Names and Numbers (ICANN). This body acts through ISPs to assign public IP addresses to organizations and individuals. Although it is possible to be allocated one IP address at a time, it is more common to be allocated IP addresses in contiguous blocks.
Contiguous blocks come in three classes: A, B, and C. Class A addresses are blocks of IP addresses with the same first byte only. Class A is more than 16 million IP addresses in size. Class B addresses are blocks of IP addresses with the same first and second byte. Class B holds 65,024 public IP addresses. The full 216 byte range is not available because the last byte of an IP address cannot be 0 or 255 because these are reserved for future use. Class C addresses are blocks of IP addresses with the same first, second, and third byte. Class C holds 254 public addresses, and class C addresses are routinely allocated to companies.
A computer may not always have the same IP address. It may obtain its IP address from your ISP’s dynamic host control protocol (DHCP) server. This means that your IP address may change every time you go online. Such an IP address is called a dynamic IP address. If you are on an intranet, you can check to see if your IP address is liable to change by checking the “obtain IP address automatically” radio button in TCP/IP properties, under Network in the control panel.
The purpose of DHCP is that if there is a limited number of IP addresses available to the ISP, it will allocate its subscribers with IP addresses from a pool on a first-come, first-served basis. IP addresses are 32-bit numbers, with a maximum value of about 4 billion, and the number of computers in the world is fast approaching that figure. IPv6 is a solution to that problem and is discussed in later chapters.
There is one identifier built into every network card that is genuinely unique and cannot be changed. This is called the hardware, or media access control (MAC) address. A sample MAC address is 00-02-E3-15-59-6C. This is used on intranets to identify computers when they log on to the network. A system called address resolution protocol (ARP) is used to associate MAC addresses with IP addresses.
The digital signals that travel between computers on the Internet are extremely complex. Without the concept of encapsulation, programmers would quickly become bogged down with insignificant details.
This technique is used in everyday life, where you may ask a taxi driver to take you to the city center. It is the taxi driver’s responsibility to find the quickest route and to operate the car. At a lower level again, it is the car manufacturer’s responsibility to ensure that gasoline will be present in the engine pistons while the accelerator is depressed.
Encapsulation is where the more complex details of a task are hidden, and the programmer only needs to concentrate on what is happening at a higher level. The open systems interconnection (OSI) network stack model has seven layers of encapsulation, as shown in Table 1.2.
In modern programming, however, the network stack looks more like Table 1.3.
The most important layer for any programmer is the uppermost layer because this will afford the greatest ease of use and will suit most applications. When you head down the stack, implementation becomes more difficult, albeit more flexible.
This book covers the application layer primarily, but coverage is given to all of the various layers, excluding the physical layer, which would apply only to electronics engineers.
In network programming, you generally do not need to concern yourself with how information travels between two computers, just with what you want to send. The finer details are handled at lower levels and are controlled by the computer’s operating system.
If you want to browse the Web and receive emails at the same time, your computer needs to decide which bits of network traffic are emails and which are Web pages. To tell the difference, every piece of data on the network is tagged with a port number: 80 for Web pages, 110 for incoming email. This information is contained within either the transmission control protocol (TCP) or user datagram protocol (UDP) header that immediately follows the IP header. Table 1.4 lists common protocols and their associated port numbers.
When developing a networked application, it is important not to reinvent the wheel or otherwise create an application that is unnecessarily incompatible with other applications of the same genre. This book often refers to standards documents, so it is worthwhile knowing where to find them.
A shining example is dynamic HTML, which was implemented differently on Internet Explorer and Netscape Navigator. This meant that most Web sites that used dynamic HTML would fail to work properly on all browsers. Thus, Web developers avoided it and moved toward crossbrowser technologies, such as Macromedia Flash and Java Applets. The reason for this downfall is lack of standardization.
Two organizations are largely responsible for regulating Internet standards: the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C). The IETF is a not-for-profit organization, which regulates the most fundamental protocols on the Internet. Anyone can submit a protocol to them, and it will be publicly available as a request for comments (RFC) on their Web site at www.ietf.org/rfc.html. Table 1.5 lists some important RFC documents.
The W3C (www.w3c.org) is designed to facilitate standard interoperability among vendors. Only large corporations can become members of the W3C. The W3C is responsible for hypertext markup language (HTML), cascading style sheets (CSS), and extensible markup language (XML).
.NET is not a programming language. It is a development framework that incorporates four official programming languages: C#, VB.NET, Managed C++, and J# .NET. Where there are overlaps in object types in the four languages, the framework defines the framework class library (FCL).
All four languages in the framework share the FCL and the common language runtime (CLR), which is an object-oriented platform that provides a runtime environment for .NET applications. The CLR is analogous to the virtual machine (VM) in Java, except it is designed for Windows, not cross-platform, use; however, a stripped-down version of the .NET framework, known as the .NET compact framework, is capable of running on Windows CE devices, such as palmtops and certain cell phones. Furthermore, there are initiatives to port the CLR to Linux, such as the MONO project (www.go-mono.com).
In this book, the two most popular .NET programming languages, C# and VB.NET, are used. Both languages differ syntactically, but are equally capable and offer identical performance characteristics. Languages in the .NET framework are highly interoperable, so there is no need to be confined to a single language. A class compiled from VB.NET can be called from a C# application and vice versa. Similarly, a class written in VB.NET can derive from a compiled class written in C#. Exceptions and polymorphism are also supported across languages. This is made possible by a specification called the Common Type System (CTS).
When an application written in a .NET language is compiled, it becomes the Microsoft intermediate language (MSIL) byte code, which is then executed by the CLR. MSIL code generated from compiling C# is generally identical to MSIL code generated from compiling VB.NET code. Exceptions to this lie with a few language-specific features, such as how C# can use classic C-style pointers within unsafe code and how VB.NET can use VB6-style Windows API definitions.
One of the failings of interpreted, or semicompiled, languages is a performance loss. .NET avoids this problem by using a just-in-time (JIT) compiler, which is generally transparent to the user. JIT acts ondemand, whenever MSIL code is first executed. JIT compiles MSIL code to machine code, which is optimized for the processor of the computer that is executing the code. In this way, JIT can leverage new features as they become available in new Intel processors without rendering older computers obsolete.
.NET languages are object-oriented rather than procedurally based. This provides a natural mechanism to encapsulate interrelated data and methods to modify this data within the same logical construct. An object is a programmatic construct that has properties or can perform actions. A core concept of object orientation is the ability of one class to inherit the properties and methods of another. The most common example used in this book is inheritance from System.Windows.Forms.Form. This provides the standard Windows user interface (i.e., a grey window with a title bar and the Minimize/Restore/Close button set at the top right).
You can make your own classes, which could form a base class from which other classes inherit. A typical example would be a class representing a car that could inherit from the vehicle class. .NET does not support multiple inheritance, so the car class cannot inherit from a vehicle class and a Windows form. Interestingly, every class within .NET derives from a root called System.Object.
An interface is a contract that stipulates what methods and properties a class must expose. To return to the previous example, the vehicle interface could be that it must be able to move, hold people, and be bought and sold. The benefit of interfaces is that software designed to auction vehicle objects would work with cars, motorcycles, and boats. An object can inherit from multiple interfaces. Thus, a boat could inherit from the vehicle interface and expose extra methods that satisfy with the marine interface (e.g., buoyancy ratings, nationality).
The code examples in this book are designed to be stand-alone Windows applications, rather than portable, self-contained classes. This approach is used to ensure that examples are kept as concise as possible. In real-world applications, networking code is generally kept separate from other facets of the application (e.g., user interface (UI), database access). Therefore, it is commonplace to keep classes associated with networking in a separate assembly.
An assembly is generally a .DLL file that contains precompiled (MSIL) code for a collection of .NET classes. Unlike standard Win32 DLLs in which developers had to rely on documentation, such as header files, to use any given DLL, .NET assemblies contain metadata, which provides enough information for any .NET application to use the methods contained within the assembly correctly. Metadata is also used to describe other features of the assembly, such as its version number, culture, the originator of the code, and any custom attributes that were added to the classes.
.NET provides a unique solution to the issue of sharing assemblies between multiple applications (aptly named DLL Hell). Generally, where an assembly is designed for use with only one application, it is contained within the same folder (or bin subfolder) as the application. This is known as a private assembly. A public assembly is copied into a location where all .NET applications on the local system have access too. Furthermore, this public assembly is designed to be versioned, unique, and tamperproof, thanks to a clever security model. This location into which public assemblies are copied is called the global assembly cache (GAC).
If you are developing a component that will be shared among many applications, you can transfer it to the GAC with these simple steps. First, create a key-pair file by typing sn -k c:keys.snk at the command prompt. You then associate the key file with your assembly by adding the code [assembly:AssemblyKeyFile("c:keys.snk")] to the head of your class. Finally, it can be copied into the GAC, either by copying and pasting into windows assembly with Windows Explorer or by typing gacutil /I:MyAssembly.dll.
The examples in this book require you to have access to Microsoft Visual Studio .NET. To program in Microsoft .NET, you need to have the Microsoft .NET SDK or Microsoft Visual Studio .NET. The former is freely available at the Microsoft Web site (http://msdn.microsoft.com/netframework/technologyinfo/howtoget/). The SDK can be used to create .NET applications, but it is awkward to create graphical user interfaces (GUIs) and use command-line-based compilers.
Visual Studio .NET is not free, but no serious .NET developer should attempt to write .NET applications without it. A free alternative to Visual Studio .NET is SharpDevelop (http://www.icsharpcode.net/OpenSource/SD/Default.aspx). This first example will include instructions for developers opting to use the .NET SDK, as well as Visual Studio .NET users, but no further examples will use the .NET SDK.
All examples are given in the two most popular .NET languages: C# and Visual Basic .NET. Both languages have exactly the same capabilities, and there is absolutely no difference in performance between the two languages. If you are familiar with C or C++, you should choose to develop in C#. If you are familiar with Visual Basic, you should choose to develop in Visual Basic .NET. When developing an application, you should not swap between languages.
The first example demonstrates how to display a Web page within a .NET application.
Open Visual Studio .NET, and click New Project. Then type in a name and location for your project (Figure 1.2).
Select the Visual Basic Windows application or Visual C# Windows application, depending on which language you wish to develop in.
When the form appears, right-click on the toolbox and select Customize Toolbox (Visual Studio .NET 2002) or Add/Remove Items (Visual Studio .NET 2003). Then select Microsoft Web Browser from the dialog box (as shown in Figure 1.3), and press OK.
Drag the Explorer icon onto the form, and then drag a button and text-box onto the form. The finished form should look like Figure 1.4.
The next step is to set the properties of all the user interface elements. Right-click on the button and select the Properties option. You will see the Properties snap-in window appearing. Scroll up to the top of this window, and click on the property labeled (Name). Enter in the new name, btnBrowse, as shown in Figure 1.5.
Similarly, name the textbox tbURL and the Microsoft Web Browser control webBrowser.
If you double-click on the button, you will see a page of code already written for you. Find the reference to btnBrowse_Click and insert the following code:
VB.NET
Private Sub btnBrowse_Click(ByVal sender As _ System.Object, ByVal e As System.EventArgs) Handles _ btnBrowse.Click webBrowser.Navigate(tbURL.Text) End Sub
private void btnBrowse_Click(object sender, System.EventArgs
e)
{
object notUsed = null;
webBrowser.Navigate(tbURL.Text,ref notUsed,ref notUsed, ref
notUsed, ref notUsed);
}The code consists simply of a single method call, navigate. This invokes the standard process that Internet Explorer goes through as it navigates the Web. The reason for the extra parameters to the method in the C# version is that C# does not support optional parameters. The navigate method has four optional parameters: Flags, targetFrameName, postData, and Headers. None of these is needed for this simple example.
In the application, click Debug→Start, type in the name of a Web page in the space provided, and press the Browse button. You will see that Web page appearing in the Web Browser control on the page, such as that shown in Figure 1.6.
You will quickly notice that the Web browser window behaves identically to Internet Explorer. This is because the component that was added to the toolbox is the main processing engine behind Internet Explorer. This component was developed before .NET arrived on the scene, so it uses an older component model than the native .NET-managed controls.
Applications written in .NET are referred to as managed, or type-safe, code. This means that the code is compiled to an intermediate language (IL) that is strictly controlled, such that it cannot contain any code that could potentially cause a computer to crash. Applications written in native code have the ability to modify arbitrary addresses of computer memory, some of which could cause crashes, or general protection faults.
Components designed before the advent of .NET are written in native code and are therefore unmanaged and deemed unsafe. There is no technical difficulty in combining unsafe code with a .NET application, as shown previously; however, if an underlying component has the potential to bring down a computer, the whole application is also deemed unsafe. Unsafe applications may be subject to restrictions; for instance, when they are executed from a network share, they could be prevented from operating. On the whole, though, if a component can do the job, use it.
The Internet Explorer component is a Common Object Model (COM) control. This type of model was used most extensively in Visual Studio 6.0. When a COM object is imported into a .NET application, a Runtime callable wrapper (RCW) class is created. This class then exposes all the properties and methods of the COM object to .NET code. In some cases, this importing process produces an interface that is virtually identical to the original COM object; however, as aptly demonstrated in the previous example, there may be some differences in the syntax of function calls.
In the original COM object, the Navigate method’s last four parameters were optional, but in the case of C#, the optional parameters had to be passed ref notUsed.
Using the .NET SDK to develop .NET applications makes a lot more work for a developer. This section shows you how to write and compile a .NET application from the command line.
The command line may be adequate for development of console applications, ASP.NET, and components, but it is not feasible to develop large Windows forms applications from the command line. The previous example, although easy to implement in Visual Studio .NET, would require a large and complex program. Nevertheless, it should be informative to Visual Studio .NET developers to be aware of the code that is autogenerated by Visual Studio .NET.
In the true programming tradition, we shall start with a program that simply displays “Hello World.” To make this different, the program will be written as a Windows form. After all, DOS console applications are very much past their sell-by date, and there seems little point in using them at all.
The code for this application may seem daunting at first, but this should illustrate how much extra work is required to implement applications without Visual Studio .NET.
First, decide which language you want to develop in, either C# or Visual Basic .NET. Open a text editor, such as Notepad, and type in the following code:
C#
using System;
using System.Windows.Forms;
namespace helloWorld
{
public class Form1 : System.Windows.Forms.Form
{
public Form1()
{
this.Text = "Hello World";
}
[STAThread]
static void Main()
{
Application.Run(new Form1());
}
}
}VB.NET
Imports System Imports System.Windows.Forms Public Class Form1 Inherits System.Windows.Forms.Form Public Sub New ( ) InitializeComponent( ) End Sub Private Sub InitializeComponent( ) Me.Text = "Hello World" End sub End Class Module Module1 Sub Main ( ) Application.Run ( new Form1 ( ) ) End sub End Module
All this code does is open a window with the caption “Hello World,” which is somewhat underwhelming for the amount of code entered. Looking closely at the code, you can see the process of events that make up a Windows application in .NET.
An application in .NET is made up of namespaces, some of which are system defined and others are coded in. This application contains three namespaces: System, System.Windows.Forms, and helloWorld. The latter is the only namespace of the three that is actually supplied by the programmer. The helloWorld namespace contains a class, named Form1. This class inherits from System.Windows.Forms.Form. This means that the class will have a visible presence on screen.
Whenever a class is created, a function known as the constructor is called. This function can be recognized in C# when the name of the function is the same as that of the class. In VB.NET, the constructor is a subroutine named New. In the case of the previous example and in most Windows applications, this constructor is used to place user interface elements (sometimes referred to as widgets) on the form. In the previous example, the constructor calls InitializeComponent, which then sets the window name of the current form (this) to “Hello World.”
Every application must have a starting point. It is tradition in virtually every programming language that the stating point should be called Main. In C#, the [STAThread] attribute indicates the function which acts as the entry point for this single threaded apartment (STA) application. Every application must have one, and only one, entry point.
[STAThread] static void Main()
In VB.NET, the main function is coded in a different way but operates identically. The main function must appear in a separate module and be coded as follows. A module is a programmatic element that contains code that is global to the entire application.
Module Module1: Sub Main ( )
Once a Windows application starts, at least one form (a class inheriting from System.Windows.Forms.Form) must be created in order for there to be a visual interface. To create a new form, we call Application.Run, passing an instance of the form.
Save the file to d: emphelloworld.vb. Open the command prompt by pressing Start→Run and then typing cmd for Windows NT, 2000, or XP or command for Windows 95, 98, or ME.
Type the following:
DOS
D: emp> path %path%;C:WINDOWSMicrosoft.NETFrameworkv1.0.3705 D: emp> Vbc /t:winexe /r:system.dll /r:system.windows.forms.dll helloworld.vb D: emp> helloworld
Save the file to d: emphelloworld.cs. Open the command prompt by pressing Start > Run and then typing cmd for Windows NT, 2000, or XP or command for Windows 95, 98, or ME.
DOS
D: emp> path %path%;C:WINDOWSMicrosoft.NETFrameworkv1.0.3705 D: emp> csc /t:exe helloworld.cs D: emp> helloworld
To run the application, you need to compile it first. Depending on what language you used to program the application, skip to the relevant section. Once it has compiled, you can run the application by clicking on the executable (.exe) file generated from the compilation. You should see a form resembling Figure 1.7.
This chapter should whet your appetite for .NET network programming and give you a better understanding of what you have to bear in mind when working with networks.
The following chapter deals with input and output (I/O) in .NET, which forms the foundation for all native .NET networking functions.