When developing a TCP/IP related application, programmers usually face the lack of a proper debugging tool. Since most of the times the programmer must build both client and server applications, starting a development can be a painful task, especially if it is the first networking development. Even for an experienced programmer, having a TCP/IP debugging tool is a useful help for testing purposes.
As a programmer strongly involved in networking applications, I have faced this problem many times. Maybe too many times, therefore two months ago I decided to start developing a solution for this problem, TCP/IP Builder.
If you have used TCP/IP Builder (windows open source tool) before reading this document, you could be asking yourself why do I call it a debugging tool. Well, it is not a debugging tool from a strict point of view. Anyway, it is used as a debugging tool 90% of the time. To be more specific I would like to say it is a 'Black Box' debugging tool, because it doesn't need internal information about the application being debugged. It will work as long as the application uses sockets to communicate with the outside world. (And as long as you know how to 'talk' with this application, of course).
TCP is a connection-oriented protocol, it means communication occurs between two actors. When this communication starts, one of these actors must 'place a call' to the other one. This defines two different roles, client (place a call) and server (listen for a call). TCP/IP Builder may play either client or server role. It may behave as a client to debug a server application or it may behave like a server to debug a client application. If you have used netcat in Linux, you will be familiar with this concept.
TIP: If you have to choose between two applications with similar features and maturity level, prefer open source tools whenever it's possible.
Let's start with the simplest scene: using TCP/IP Builder to debug a TCP/IP standard server
First of all, we will need a server application to debug. We are going to use a SMTP server (Simple Mail Transfer Protocol) because they are very common in Internet and your ISP should be providing one for you.
Check you mail, you should receive the mail you sent to your real email address. Some STMP servers take some time to deliver emails so be patient. Taking a look at what we have done, we realize that debugging a STMP server involves two skills. Knowing how to connect to a server using sockets and how to 'talk' to this specific server.
TCP/IP Builder allows you to connect to a server using sockets. You have to know how to talk with the server. In our previous test we have talked to a SMTP server. All data sent to the server is specified in the SMTP specification. You can find it at http://rfc.net/rfc821.html
When debugging an application using TCP/IP Builder, you have to know how to talk to the application. You have to know what data send, what data you may receive upon sending data, etc. This is the high-level protocol, sockets are a lower level protocol and our talk takes place over it. Socket communication takes place over other protocols, in this case it does over TCP and TCP takes place over IP and so on. You may go deeper into low-level protocols until you reach the hardware involved in this communication. In this article we just want to pay attention to the sockets protocol and those above it.
That's about all for the present article, I will be back with other kind of debugging in future article parts. Coming next "TCP client debugging" in part two of this article. Where TCP/IP behaves like a server.
Continue reading the second part of this text: TCP/IP High-Level Protocol Debugging Part 2
If you've found this to be an useful article, don't forget to share it.