Debugging network code

3.5 Debugging network code

Network connections can and do break, and other applications may be already using the ports you want to use. It is therefore foolhardy to assume that a call to a Connect or Listen method will always succeed. For this rea- son, the try/catch construct should be employed as demonstrated below:

C#

try {

serverSocket.Bind(ipepServer); serverSocket.Listen(-1);

} catch(SocketException e) {

MessageBox.Show(e.Message); } catch(Exception e) {

MessageBox.Show(e.Message); Application.Exit();

VB.NET

try serverSocket.Bind(ipepServer) serverSocket.Listen(-1)

catch e as SocketException MsgBox(e.Message) Catch e as Exception MsgBox(e.Message)

Chapter 3

74 3.5 Debugging network code

Application.Exit() End try

Another type of problem that plagues network applications is scalability. This is where the software cannot cope with a large number of sequential or concurrent connections, or both. To discover scalability problems, you can either repetitively hit the Connect and Send buttons on your client or write

a stress test program to do this for you over long periods. The program may run out of memory if sockets are not set to null after use, or it may crash because of simultaneous access to a limited resource, or start dropping con- nections, or work perfectly.

To locate problems in multithreaded applications, tracing statements are invaluable. A good mechanism for doing this is the System. Diagnostics.Trace class or simple Console.WriteLine statements at the entrance and exit of methods. Once the problem has been located, plac- ing Lock statements around non-thread-safe code usually aids system sta- bility; however, placing a Lock clause around a blocking statement may cause your application to hang.

When developing an application that interfaces with a third-party dis- tributed application, it is sometimes quite difficult to see exactly what is being sent between client and server. This matter can be further compli- cated if the protocol is proprietary, with little or no technical information.

Many protocols are inherently text based and were originally designed for users to access by typing the commands directly into the server, rather than using a GUI. Nowadays, nobody would have the patience to upload a file via FTP by typing the FTP commands directly into the server, but because Internet standards are somewhat immortal, these old systems have remained.

This rather arcane way of accessing Web-based services may no longer

be relevant to the end-user, but it is a godsend to the developer. Say, for example, you are developing a program that is designed to interface an IMAP (email) server. If the program is not receiving emails, after you’ve meticulously implemented the protocol as per RFC spec, you can always open up telnet and go through the paces of receiving an email by typing text into telnet. If you can re-create the error manually, it should help solve the problem from a programmatic perspective. This approach would not work with binary protocols such as Distributed Common Object Model (DCOM).

3.6 Socket-level networking in .NET 75

Figure 3.5

Netstat utility.

If you are working with an unofficial or proprietary protocol, there may

be little chance you can guess how it works. The first step in approaching any such protocol is to determine on which port it is operating. A useful tool in doing this is netstat . To see it in action, open the command prompt and type netstat (Figure 3.5).

This lists all of the current outgoing and incoming connections to your computer at that time, along with the port in use. To isolate the port used by any particular application, use the process of elimination. If you turn off all nonessential network services apart from the application that you are trying to analyze, take note of the list of ports, then turn off the application, and compare the new list with the old list; whatever port is missing is the application’s port.

Knowing the port number is only one step toward tapping into a proto- col. To see exactly what bits and bytes are being sent between the two appli- cations, you can use one of the example protocol analyzer programs described in Chapter 13 or a ready-made application such as Trace Plus from www.sstinc.com.