Networking continued
Now that you know the basic layers of the network interface, I will continue with some other principles concerning hostnames, connections and software level protocols.
1. DNS
DNS stands for Domain Name System, which accounts for the conversion of hostnames to and from IP numbers. Because IP numbers are not easy to remember (well not many at least), another more convenient naming system was created. Now, instead of an IP number, you could use a hostname alternatively. Examples of hostnames are: madwizard.org, somepc.someuniversity.edu, www.google.com, etc. Anyone browsing the internet has used them. When connecting to a website, its IP is needed. So if you enter a hostname like www.google.com, it first needs to lookup the corresponding IP number of google. This is where DNS comes in. Your PC sends out a hostname lookup request to the DNS your provider has setup in its network. If the DNS can resolve the hostname, it sends back the corresponding IP to you. DNS are organized in a hierarchical way, forwarding unresolvable hostnames to a DNS at a higher level, until the hostname is resolved.
2. Connections
TCP/IP is a connection-oriented protocol. The connection is always between two devices, and each side uses its own IP and port number. Usually, one side is called the client, the other side the server.
The client is the one that requests something, the server responses accordingly. For example, when opening a website, the browser is the client, the webserver is the server. The browser initiates the connection with the server and requests a specific resource. The server then sends back a response and the data requested.
The server is continually waiting for incoming connections. This is called listening, which is always done on a certain IP and port number. The client is only active when necessary, as the client is always the initiator of a connection and the one that requests information. To create a connection, the client needs to know both the IP and port number the server is listening on. A connection is made to that server and hopefully accepted by the server. While communication over a TCP/IP connection is two-way, many protocols (HTTP, FTP, etc) let the client and server interact in turn.
Both the server and client side use an IP and port number, but the IP and port number of the server are usually fixed. The standard port for the WWW is 80 (using HTTP). Google for example, is a webserver that runs on port 80 and IP 216.239.39.101 (at the moment of writing). Each client (read: anyone google-ing :) connects to this IP and port. So the webserver can have many connections on the same port. This is no problem, since all traffic on that port is for the same process. On the client side, the port number doesn't matter. Any port can be used. Some people think that the port number used in a connection needs to be the same on both sides. This is not true. Just open a website and quickly run 'netstat -an' in a command line. You might see a line like this:
TCP xxx.xxx.xxx.xxx:2894 216.239.39.101:80 ESTABLISHED
xxx.xxx.xxx.xxx was my IP, 216.239.39.101 is google's IP. The number after the colon is the port number. As you can see, the server side uses port 80, while the client uses a random (read: some free) port number like 2894. Each client connection needs a different port number on the client side, since every connection is associated with a different client.
- Client
- The program that initiates the connection, and requests information.
- Server
- The program that listens for incoming connections, accepts them and responses according to the received requests. The IP and port number of the server need to be known by the client to connect to it.
3. Protocols again
In the previous chapters I have showed several protocols at the different levels of a network interface. The protocols I didn't discuss yet are the protocols that work at software level. Examples of these are HTTP, FTP, POP3, SMTP. Most of them work in a client-server way, ie. the client makes requests, the server responds. The exact format of the requests and responses are described in these protocols. I won't discuss them further right now, but I will later when you know the winsock basics to actually implement them.