Home > Articles > Programming > C/C++

Writing a C-based Client/Server

  • Print
  • + Share This
  • 💬 Discuss
From the author of
With a C compiler on your UNIX/Linux system, and a few files you can build or download as described in this article, you can program your own multiprocessing application. And then, world domination! Or at least simultaneous processing.

Consider for a moment having the massive power of different computers all simultaneously trying to compute a problem for you—and still being legal! With the commonplace interconnectivity that a network brings, you can do just that. All you need is a login and a compiler—and a few system calls.

Network programming extends the ability to solve computational problems. Nearly all network programs use sockets to provide connection points between the source and destination. You can compare sockets with an in/out box for messages between tasks on different computers. All you need is a host address and port, and you can send and receive messages from anywhere on your network.

For example, SETI@Home uses others' computers to process a block of data with complex computations. This network of free processing time essentially creates a massively parallel multiprocessor. In just one year (5/99–2/00), SETI had processed over 165,000 years of data. All this is possible because of sockets.

Connecting the Client

You can program your own multiprocessing application with the tools on your computer. Most UNIX operating systems include a C compiler, and you can try out the coding examples directly from this article or the Linux Socket web site. Programs that connect to the network are really straightforward, with the understanding that some of the system calls are a little hard to find. Use Linux Socket Programming (Sams Publishing, 2001, ISBN 0-672-31935-7) as your guide to find all the needed calls, tips, and tricks.

Sockets always have two ends: the sender and the receiver. And all messages eventually boil down to individual message blocks (or frames) on the physical network. Typically, the computer that initiates communication is the client; and the server accepts the message. The client opens a connection to the server, following a syntax (such as MIME) and protocol (such as HTTP).

Getting the Hostname

But before the client can connect to the server, the client has to know the address and port of the server. No computer on the network really uses the hostname. Instead, all connections use the host's IP address, and the client is responsible for converting the hostname to the IP address. The user who runs your program may supply a hostname; you can get the IP address from the operating system's Domain Name Services (DNS) with the gethostbyname() library call:

#include <netdb.h>
struct hostent* host;
host = gethostbyname("lwn.net");
printf("IP address = %s\n", 
  inet_ntoa(*(long*)host->h_addr_list[0]));

If successful, host points to a structure that contains the network byte-order address.

Getting the Port Number

The next piece of information you need is the port number. The port is an agreed-upon connection point between the client and server. You can use any port you like between #1 and #65535, and you must have root privilege to use port #1 through #1023. All computers connected to a network use a published list of ports for standard services. You can find this list in /etc/services. For example, the standard port for HTTP is 80, and Telnet is 23.

You can use this file to get the exact port, or you can select a port directly. If you want to use a standard service, be aware that using the direct port number can cause compatibility problems. Instead, use the getservbyname() library call to convert the name into the port. The call converts the port number (s_port) into the network byte-order for you:

#include <netdb.h>
struct servent *srv;
srv = getservbyname("http", "tcp");
printf("%s: port=%d\n", srv->s_name, ntohs(srv->s_port));

Connecting to the Server

Once you have the address and port number, you can connect to the server. To connect to the server, the program needs a socket. The socket may seem very primitive is its design. However, it hooks right into the file I/O subsystem, making it a very powerful primitive. After creating a socket and connecting to the server, you can treat it like a regular file (see below).

The program creates a socket with the socket() system call:

#include <sys/socket.h>
#include <sys/types.h>
#include <resolv.h>

int sd;
sd = socket(PF_INET, SOCK_STREAM, 0); /* create socket */

It's that simple. The constants PF_INET and SOCK_STREAM mean TCP/IP network and TCP protocol. The Linux operating system handles many types of networks and protocols; this is just one combination.

The socket() system call only creates a connection point. To really start the flow of data, you need to connect to the server:

#include <sys/socket.h>
#include <sys/types.h>
#include <resolv.h>

struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));    /* create & zero struct */
addr.sin_family = AF_INET;    /* select internet protocol */
addr.sin_port = srv->s_port;         /* set the port # */
addr.sin_addr.s_addr = 
        *(long*)host->h_addr_list[0]; /* set the addr */
connect(sd, &addr, sizeof(addr));         /* connect! */

NOTE

If any of the calls yield an error, you need to stop and check errno. Network programming is very prone to error and unreliability. Following good programming practices can save you a lot of debugging time.

After connecting, you can begin the dialogue. Because sockets hang off of the file I/O subsystem, you can use the standard read()/write() system calls or use specialized recv()/send() system calls. The following example converts the socket connection into a FILE stream, and works the connection from there:

char s[200];
FILE *fp;
fp = fdopen(sd, "r+");         /* convert into stream */
fprintf(fp, "GET / HTTP/1.0\n\n");      /* send request */
fflush(fp);               /* ensure it got out */
while ( fgets(s, sizeof(s), fp) != 0 )  /* while not EOF ...*/
 fputs(s, stdout);           /*... print the data */
fclose(fp);

HTTP is a relatively simple protocol. More complicated tools may require logins, encryption, more interaction, and so on. When defining your own SETI@Home–style of network program, you have full flexibility to use text, binary (sending straight data structures), or whatever you need. The only limitation is that you can't send pointers. Once the pointer leaves the program that owns it, it's meaningless (even going to the same host in loopback), because the memory that it references is inaccessible to the receiver.

  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus