Sending a Message

At this point we can put together what we've learned and send a message from one computer to another. Let's say we have two computers in our network: PC A and PC B. PC A wants to send a message to PC B. What happens?

First, PC B must be running some software that will listen to a specified port number. The software must register itself with the operating system. During the registration process, the software will specify the port that it wants to listen to. Let's say, for example, that PC B has an IP address of 192.168.1.20 and is listening on port 34567.

PC B: 192.168.1.20:34567

To send a message to PC B, PC A will try to open a connection on the specified port. Let's say, for example, that PC A has an IP address of 192.168.1.10. When the program running on PC A asks to open the connection to PC B, the operating system will assign an unused port number on PC A. Let's say that PC A is assigned 45678. The resulting connection would be numbered like this:

192.168.1.10:45678 ... 192.168.1.20:34567

Since we're using TCP here we are establishing a connection through which both sides can send and receive messages. So, let's go ahead and try it. At first we can try it from one shell to another. After that we can try it from one PC to another.

Telnet & Netcat

If you have one PC running Linux you can try this using the telnet and nc (netcat) utilities. Netcat is sort of a networking swiss army knife that allows you to send and receive using TCP and UDP. Telnet is a utility that has been around for a long time. As with netcat it can establish a connection with a TCP port and allow you to send and receive text through that connection.

If you are using Windows you will find that telnet is already installed. Netcat, unfortunately, is not available by default. You will have to first download a version of netcat from your favorite source. If you are an Apple Mac user you will no doubt find telnet installed on your system by default. You may have to check the Apple documentation to find out how to find the equivalent of netcat in your environment.

Let's start by sending a message from one shell to another on the same computer. Open two shells (also known as command shells or DOS boxes in Windows.) In the first shell, run netcat and tell it to listen on port 34567:

$ nc -l 34567

(The command should be the same in Windows; check the documentation for your version of netcat.)

On the second shell, use the telnet command to talk to netcat:

$ telnet localhost 34567

(The above command will work in Windows command shells as is.)

When the telnet program starts running, it establishes a TCP connection to the netcat program. By convention, localhost is the name of a special network interface, the Loop Back device, on the local computer. There should be a loopback device on every computer you work with and it should always have the same IP address: 127.0.0.1.

Getting back to the telnet program: it is waiting for you to type something. Anything that you type will be sent through the TCP connection to the listening program; in this case netcat. Netcat will simply take whatever it gets and display it on the screen.

Note that nothing happens until you press the Enter key - both programs will buffer a line of input text before they send anything.

tcpdump

Another good thing to try is to open a third shell and run a utility called tcpdump on the loopback device. Tcpdump is a utility that listens to the traffic passing through an interface. It can display everything it finds on your screen or you can tell it to display only specific information.

(Windows users will find that there are many programs that can be downloaded to perform similar functions. Look for wireshark, among others.)

On Linux systems you will only be allowed to do this if you have access to the root password. This is because the tcpdump utility must have low-level access permission to be able to listen to device traffic.

In this case, we want to display the activity on the loopback device that involves port number 34567. The command (for Redhat-related distributions of linux,) is:

$ su -c "tcpdump -i lo port 34567"

Now, when you go to one of the other shells and type a line of text: The text will appear in the other shell and a trace of the traffic on the loopback device will appear in the tcpdump shell:

The exact meaning of the above is perhaps not terribly important - but you can see that a message goes from the listening program (netcat, where I sent the line of text from,) to the connecting program (telnet,) in the other shell. This message is followed by a reply. Note also that the first message comes from the destination port 34567 that was specified when the listening program, nc, was started. The connecting program, telnet, was assigned a source port number of, in this example, 36636.

From either of the first two shells you can press Control-D to send an End of File message. This will cause both programs to stop running.

ping

Another utility that you might want to try: ping lets you verify that you can get a reply from a specific device. In one of the shells, type ping localhost to see how that works:

Of course, the localhost address and the loopback device should always be working on your computer. The information that they return is more interesting when you try it on devices that are not working properly. Try to ping a number you don't expect to hear back from, such as 12.34.56.78 (when you are not connected to the internet:)

There are many reasons why you might not get a response from a device that you try to ping. With time you will learn about all the various bits of software and hardware that carry the ICMP messages back and forth. Once you have a solid understanding of the whole process you will be able to investigate each step in the route, find any problems and fix them.

traceroute

One last exercise that might be useful is to try traceroute. You will need to be connected to the internet for this to work. Try traceroute www.microsoft.com, for example. On windows machines the command name is a little different: tracert instead of traceroute. Traceroute will list all the routers between your computer and the one you want to talk to. It will display a total round-trip time, in thousandth's of a second (ms,) three times, for each router in the route. If a router drops a packet, traceroute will display a star in place of the round-trip time for that ping.

Some traceroute results are kind of amazing! When I first discovered this utility I enjoyed connecting to the internet from a dial-up line and running traceroutes back to the local high-speed connection. It's amazing how two computers sitting next to each other in an office might have to route their packets through several other cities when they communicate together. This is because each service provider has agreements with different back-bone operatators in different cities. Even these days it's amazing to see just how far a packet has to travel to get from one ISP to another. Routes between two local computers in Montreal often have to pass through Toronto, Chicago and New York - and will often do so in less than 60ms.

Finally, if you do have two computers handy, you might want to try the above telnet/netcat exercise between them. Of course, you will want the two computers to already be connected through a working network. You will also need to know the address of one of them. Let's continue to use the example addresses that we recently used for PC A and PC B above:

PC A: 192.168.1.10 PC B: 192.168.2.20

On PC A run netcat and tell it to listen to port 34567 (nc -l 34567 or netcat -l 34567.) On PC B, telnet to PC A (telnet 192.168.1.10 34567) and send some lines of text back and forth.

You should see the same results that you saw in the single computer example.