 
 
 
 Client-server
Interprocess communication between processes on the same machine 
or on different machines through TCP/IP sockets 
is a mode of point-to-point asynchronous communication.
The reliability of such transmissions is assured by the 
TCP protocol. It is nonetheless possible to simulate 
the broadcast to a group of processes through 
point-to-point communication to all receivers.
The roles of different processes communicating in an application are 
asymmetric, as a general rule.
That description holds for client-server architectures.
A server is a process (or several processes) accepting 
requests and trying to respond to them. The client, itself
a process, sends a request to the server, hoping for a response.
 Client-server Action Model
A server provides a service on a given port 
by waiting for connections from future clients. 
Figure 20.1 shows the sequence of principal tasks 
for a server and a client.
Figure 20.1: Model of a server and client
A client can connect to a service once the server is ready to 
accept connections (accept). 
In order to make a connection, the client must know the 
IP number of the server machine and the port number 
of the service. If the client does not know the IP number, 
it needs to request name/number resolution using the function
gethostbyname. 
Once the connection is accepted by the server, each program can
communicate via input-output channels over the sockets created at both ends.
 Client-server Programming
The mechanics of client-server programming
follows the model described in Figure 20.1. 
These tasks are always performed.
For these tasks, we write generic functions parameterized 
by particular functions for a given server.
As an example of such a program, we describe a server that 
accepts a connection from a client, waits on a socket 
until a line of text has been received, converting the line to CAPITALS,
and sending back the converted text to the client.
Figure 20.2 shows the communication between the 
service and different clients1.
Figure 20.2: CAPITAL service and its clients
Certain tasks run on the same machine as the server, while others are 
found on remote machines.
We will see 
- 
 How to write the code for a ``generic server'' and 
instantiate it for our particular capitalization service. 
-  How to test the server, without writing the client, by 
using the telnet program.
-  How to create two types of clients:
 
- 
a sequential client, which waits for a response after sending a request;
 
 
- 
a parallel client, which separates the send and receive tasks.
 Therefore, there are two processes for this client.
 Code for the Server
A server may be divided into two parts: waiting for a connection
and the following code to handle the connection.
 A Generic Server
The generic server function establish_server described below 
takes as its first argument a function
for the service (server_fun) that handles requests, 
and as its second argument, the address of the socket 
in the Internet domain that listens for requests.
This function uses the auxiliary function domain_of, 
which extracts the domain of a socket from its address.
In fact, the function establish_server is made up 
of high-level functions from the Unix library. 
This function sets up a connection to a server.
# let establish_server server_fun sockaddr =
   let domain = domain_of sockaddr in
   let sock = Unix.socket domain Unix.SOCK_STREAM 0 
   in Unix.bind sock sockaddr ;
      Unix.listen sock 3;
      while true do
        let (s, caller) = Unix.accept sock 
        in match Unix.fork() with
               0 -> if Unix.fork() <> 0 then exit 0 ; 
                    let inchan = Unix.in_channel_of_descr s 
                    and outchan = Unix.out_channel_of_descr s 
                    in server_fun inchan outchan ;
                       close_in inchan ;
                       close_out outchan ;
                       exit 0
             | id -> Unix.close s; ignore(Unix.waitpid [] id)
      done ;;
val establish_server :
  (in_channel -> out_channel -> 'a) -> Unix.sockaddr -> unit = <fun>
To finish building a server with a standalone executable that takes 
a port number parameter, we write a function
main_server which takes a parameter indicating a service. 
The function uses the command-line parameter as the port number of
a service. The auxiliary function get_my_addr,
returns the address of the local machine. 
# let get_my_addr () =
   (Unix.gethostbyname(Unix.gethostname())).Unix.h_addr_list.(0) ;;
val get_my_addr : unit -> Unix.inet_addr = <fun>
# let main_server  serv_fun =
   if Array.length Sys.argv < 2 then Printf.eprintf "usage : serv_up port\n"
   else try
          let port =  int_of_string Sys.argv.(1) in 
          let my_address = get_my_addr() 
          in establish_server serv_fun  (Unix.ADDR_INET(my_address, port))
        with
          Failure("int_of_string") -> 
            Printf.eprintf "serv_up : bad port number\n" ;;
val main_server : (in_channel -> out_channel -> 'a) -> unit = <fun>
 Code for the Service
The general mechanism is now in place. To illustrate how it works,
we need to define the service we're interested in.
The service here converts strings to upper-case.
It waits for a line of text over an input channel,
converts it, then writes it on the output channel, 
flushing the output buffer. 
# let uppercase_service ic oc =
   try while true do    
         let s = input_line ic in 
         let r = String.uppercase s 
         in output_string oc (r^"\n") ; flush oc
       done
   with _ -> Printf.printf "End of text\n" ; flush stdout ; exit 0 ;;
val uppercase_service : in_channel -> out_channel -> unit = <fun>
In order to correctly recover from exceptions
raised in the Unix library, 
we wrap the initial call to the service 
in an ad hoc function from the Unix library:
# let go_uppercase_service () = 
   Unix.handle_unix_error main_server uppercase_service ;;
val go_uppercase_service : unit -> unit = <fun>
 Compilation and Testing of the Service
We group the functions in the file serv_up.ml, 
adding an actual call to the function go_uppercase_service. 
We compile this file, indicating that the Unix library is 
linked in 
ocamlc -i -custom -o serv_up.exe unix.cma serv_up.ml -cclib -lunix
The transcript from this compilation (using the option -i) gives: 
val establish_server :
  (in_channel -> out_channel -> 'a) -> Unix.sockaddr -> unit
val main_server : (in_channel -> out_channel -> 'a) -> unit
val uppercase_service : in_channel -> out_channel -> unit
val go_uppercase_service : unit -> unit
We launch the server by writing:
serv_up.exe 1400
The port chosen here is 1400. Now the machine where
the server was launched will accept connections on this 
port.
 Testing with telnet
We can now begin to test the server by using an existing client 
to send and receive lines of text. The telnet utility,
which normally is a client of the telnetd service 
on port 23, and used to control a remote connection, 
can be diverted from this role by passing a machine name
and a different port number.
This utility exists on several operating systems. 
To test our server under Unix, we type:
$ telnet boulmich 1400 
Trying 132.227.89.6...
Connected to boulmich.ufr-info-p6.jussieu.fr.
Escape character is '^]'.
The IP address for boulmich is 132.227.89.6 
and its complete name, which contains its domain name, is
boulmich.ufr-info-p6.jussieu.fr. 
The text displayed by telnet indicates a successful 
connection to the server. 
The client waits for us to type on the keyboard, sending 
the characters to the server that we have launched on boulmich on
port 1400.
It waits for a response from the server and displays:
The little cat is dead.
THE LITTLE CAT IS DEAD.
We obtained the expected result.
WE OBTAINED THE EXPECTED result.
The phrases entered by the user are in lower-case and those
sent by the server are in upper-case. This is exactly
the role of this service, to perform this conversion.
To exit from the client, we need to close the window where it was
run, by executing the kill command. 
This command will close the client's socket, causing the 
server's socket to close as well. 
When the server displays the message ``End of text,'' 
the process associated with the service terminates.
 The Client Code
 
While the server is naturally parallel (we would like 
to handle a particular request while accepting others,
up to some limit), the client may or may not be so, according 
to the nature of the application. 
Below we give two versions of the client. Beforehand, we present 
two functions that will be useful for writing these clients.
The function open_connection from the Unix library 
allows us to obtain a couple of input-output channels for a socket.
The following code is contained in the language distribution.
# let open_connection sockaddr =
   let domain = domain_of sockaddr in
   let sock = Unix.socket domain Unix.SOCK_STREAM 0 
   in try Unix.connect sock sockaddr ;
          (Unix.in_channel_of_descr sock , Unix.out_channel_of_descr sock)
     with exn -> Unix.close sock ; raise exn ;;
val open_connection : Unix.sockaddr -> in_channel * out_channel = <fun>
Similarly, the function shutdown_connection closes 
down a socket.
# let shutdown_connection inchan =
   Unix.shutdown (Unix.descr_of_in_channel inchan) Unix.SHUTDOWN_SEND ;;
val shutdown_connection : in_channel -> unit = <fun>
 A Sequential Client
From these functions, we can write the main function 
of a sequential client. This client takes as its argument a 
function for sending requests and receiving responses.
This function analyzes the command line arguments to obtain
connection parameters before actual processing. 
# let main_client client_fun  =
   if Array.length Sys.argv < 3 
   then Printf.printf "usage :  client server port\n"
   else let server = Sys.argv.(1) in
        let server_addr =
          try  Unix.inet_addr_of_string server 
          with Failure("inet_addr_of_string") -> 
                 try  (Unix.gethostbyname server).Unix.h_addr_list.(0) 
                 with Not_found ->
                        Printf.eprintf "%s : Unknown server\n" server ;
                        exit 2
        in try 
             let port = int_of_string (Sys.argv.(2)) in
             let sockaddr = Unix.ADDR_INET(server_addr,port) in 
             let ic,oc = open_connection sockaddr
             in client_fun ic oc ;
                shutdown_connection ic
           with Failure("int_of_string") -> Printf.eprintf "bad port number";
                                            exit 2 ;;
val main_client : (in_channel -> out_channel -> 'a) -> unit = <fun>
All that is left is to write the function for client
processing.
# let client_fun ic oc = 
   try
     while true do  
       print_string  "Request : " ;
       flush stdout ;
       output_string oc ((input_line stdin)^"\n") ;
       flush oc ;
       let r = input_line ic 
       in Printf.printf "Response : %s\n\n" r;
          if r = "END" then ( shutdown_connection ic ; raise Exit) ;
     done
   with 
       Exit -> exit 0
     | exn -> shutdown_connection ic ; raise exn  ;;
val client_fun : in_channel -> out_channel -> unit = <fun>
The function client_fun enters an infinite loop 
which reads from the keyboard, sends a string to the server,
gets back the transformed upper-case string, and displays it.
If the string is "END", then the exception Exit 
is raised in order to exit the loop. If another exception is
raised, typically if the server has shut down, the function
ceases its calculations.
The client program thus becomes:
# let go_client () = main_client client_fun ;;
val go_client : unit -> unit = <fun>
We place all these functions in a file named
client_seq.ml, adding a call to the function 
go_client. We compile the file with the following
command line:
ocamlc -i -custom -o client_seq.exe unix.cma client_seq.ml -cclib -lunix
We run the client as follows:
$ client_seq.exe boulmich 1400 
Request : The little cat is dead.
Response: THE LITTLE CAT IS DEAD.
Request : We obtained the expected result.
Response: WE OBTAINED THE EXPECTED RESULT.
Request : End
Response: END
 The Parallel Client with fork
The parallel client mentioned divides its tasks between 
two processes: one for sending, and the other for receiving. 
The processes share the same socket. The functions associated
with each of the processes are passed to them as parameters.
Here is the modified program:
# let main_client client_parent_fun client_child_fun  =
   if Array.length Sys.argv < 3 
   then Printf.printf "usage :  client server port\n"
   else
     let server = Sys.argv.(1) in
     let server_addr =
       try  Unix.inet_addr_of_string server 
       with Failure("inet_addr_of_string")
              -> try  (Unix.gethostbyname server).Unix.h_addr_list.(0) 
                 with Not_found -> 
                        Printf.eprintf "%s : unknown server\n" server ;
                        exit 2
     in try 
          let port = int_of_string (Sys.argv.(2)) in
          let sockaddr = Unix.ADDR_INET(server_addr,port) in 
          let ic,oc = open_connection sockaddr 
          in match Unix.fork () with
                 0 -> if Unix.fork() = 0 then client_child_fun oc ; 
                      exit 0
              | id -> client_parent_fun ic ;
                      shutdown_connection ic ;
                      ignore (Unix.waitpid [] id)
        with
           Failure("int_of_string") -> Printf.eprintf "bad port number" ;
                                       exit 2 ;;
val main_client : (in_channel -> 'a) -> (out_channel -> unit) -> unit = <fun>
The expected behavior of the parameters is: the (grand)child sends
the request and the parent receives the response.
This architecture has the effect that if the child needs to send 
several requests, then the parent receives the responses 
to requests as each is processed. Consider again the preceding 
example for capitalizing strings, modifying the client side program.
The client reads the text from one file, while writing 
the response to another file. For this we need a function 
that copies from one channel, ic, to another, oc, 
respecting our little protocol (that is, it recognizes the 
string "END").
# let copy_channels ic oc = 
   try while true do 
         let s = input_line ic 
         in if s = "END" then raise End_of_file
            else (output_string oc (s^"\n"); flush oc)
       done 
   with End_of_file -> () ;;
val copy_channels : in_channel -> out_channel -> unit = <fun>
We write the two functions for the child and parent 
using the parallel client model:
# let child_fun in_file out_sock = 
   copy_channels in_file out_sock ;
   output_string out_sock ("FIN\n") ;
   flush out_sock ;;
val child_fun : in_channel -> out_channel -> unit = <fun>
# let parent_fun out_file in_sock = copy_channels in_sock out_file ;;
val parent_fun : out_channel -> in_channel -> unit = <fun>
Now we can write the main client function. It must 
collect two extra command line parameters:
the names of the input and output files.
# let go_client () = 
  if Array.length Sys.argv < 5 
    then Printf.eprintf "usage : client_par server port filein fileout\n"
  else let in_file = open_in Sys.argv.(3) 
       and out_file = open_out Sys.argv.(4) 
       in main_client (parent_fun out_file) (child_fun in_file) ;
          close_in in_file ;
          close_out out_file ;;
val go_client : unit -> unit = <fun>
We gather all of our material into the file client_par.ml
(making sure to include a call to go_client), and compile it. 
We create a file toto.txt containing the text to be converted:
The little cat is dead.
We obtained the expected result.
We can test the client by typing:
client_par.exe boulmich 1400 toto.txt result.txt
The file result.txt contains the text: 
$ more result.txt
THE LITTLE CAT IS DEAD.
WE OBTAINED THE EXPECTED RESULT.
When the client finishes, the server always displays the message
"End of text".
 Client-server Programming with Lightweight Processes
The preceding presentation of code for a generic server and
a parallel client created processes via the fork primitive
in the Unix library. This works well under Unix; many
Unix services are implemented by this technique. 
Unfortunately, the same cannot be said for Windows.
For portability, it is preferable to write client-server
code with lightweight processes, which were presented in 
Chapter 19. In this case, it becomes necessary 
to examine the interactions among different server processes.
 Threads and the Unix Library
The simultaneous use of lightweight processes and the Unix
library causes all active threads to block if a system call does 
not return immediately. In particular, reads on file descriptors, 
including those created by socket, are blocking.
To avoid this problem, the ThreadUnix library 
reimplements most of the input-output functions from the 
Unix library. The functions defined in that library will only 
block the thread which is actually making the system call. 
As a consequence, input and output is handled with the 
low-level functions read and write found 
in the ThreadUnix library.
For example, the standard function for reading a string of characters,
input_line, is redefined in such a way that it does not 
block other threads while reading a line.
# let my_input_line  fd = 
   let s = " "  and  r = ref "" 
   in while (ThreadUnix.read fd s 0 1 > 0) && s.[0] <> '\n' do r := !r ^s done ;
      !r ;;
val my_input_line : Unix.file_descr -> string = <fun>
 Classes for a Server with Threads
Now let us recycle the example of the CAPITALIZATION service, this 
time giving a version using lightweight processes. Shifting
to threads poses no problem for our little application
on either the server side or the client side, which start 
processes independently.
Earlier, we built a generic server parameterized over a service
function. We were able to achieve this kind of abstraction by relying on 
the functional aspect of the Objective CAML language. Now we are about to
use the object-oriented extensions to the language to show how objects 
allow us to achieve a comparable abstraction.
The server is organized into two classes: 
serv_socket and connection. The first of these
handles the service startup, and the second, the service itself. 
We have introduced some print statements to trace the main 
stages of the service.
 The serv_socket class.
 has two instance variables: 
port, the port number for the service, and socket, 
the socket for listening. When constructing such an object, the initializer 
opens the service and creates this socket. The run method 
accepts connections and creates a new connection object for handling 
requests. The serv_socket uses the connection class described 
in the following paragraph. Usually, this class must be defined before the
serv_socket class.
# class serv_socket p = 
   object (self)
     val port = p 
     val mutable sock = ThreadUnix.socket Unix.PF_INET Unix.SOCK_STREAM 0
 
     initializer 
       let my_address = get_my_addr () 
       in Unix.bind sock (Unix.ADDR_INET(my_address,port)) ;
          Unix.listen sock 3
    
     method private client_addr = function 
         Unix.ADDR_INET(host,_) -> Unix.string_of_inet_addr host
       | _ -> "Unexpected client"
 
     method run () = 
       while(true) do 
         let (sd,sa) = ThreadUnix.accept sock in 
         let connection = new connection(sd,sa) 
         in Printf.printf "TRACE.serv: new connection from %s\n\n"
                          (self#client_addr sa) ;
         ignore (connection#start ())
       done
   end ;;
class serv_socket :
  int ->
  object
    val port : int
    val mutable sock : Unix.file_descr
    method private client_addr : Unix.sockaddr -> string
    method run : unit -> unit
  end
It is possible to refine the server by inheriting from this class and redefining 
the run method.
 The connection class.
The instance variables in this class, 
s_descr and s_addr, are 
initialized to the descriptor and the address of the socket created
by accept. The methods are start, run,
and stop. The start creates a thread calling the
two other methods, and returns its thread identifier, which can be 
used by the calling instance of serv_socket.
The run method contains the core functionality of the 
service. We have slightly modified the termination condition for 
the service: we exit on receipt of an empty string.
The stop service just closes the socket descriptor 
for the service. 
Each new connection has an associated number obtained by 
calling the auxiliary function gen_num when 
the instance is created.
# let gen_num = let c = ref 0 in (fun () -> incr c; !c) ;;
val gen_num : unit -> int = <fun>
# exception Done ;;
exception Done
# class connection (sd,sa) = 
   object (self) 
     val s_descr = sd
     val s_addr = sa
     val mutable number = 0
     initializer 
       number <- gen_num();
       Printf.printf "TRACE.connection : object %d created\n" number ;
       print_newline()
 
     method start () =  Thread.create (fun x -> self#run x ; self#stop x) ()
 
     method stop() = 
       Printf.printf "TRACE.connection : object finished %d\n" number ;
       print_newline () ;
       Unix.close s_descr
 
    method run () = 
      try 
        while true do
          let line =  my_input_line s_descr 
          in if (line = "") or (line = "\013") then raise Done ;
             let result = (String.uppercase line)^"\n"
             in ignore (ThreadUnix.write s_descr result 0 (String.length result))
        done
      with  
         Done -> () 
       | exn  -> print_string (Printexc.to_string exn) ; print_newline() 
   end ;;
class connection :
  Unix.file_descr * 'a ->
  object
    val mutable number : int
    val s_addr : 'a
    val s_descr : Unix.file_descr
    method run : unit -> unit
    method start : unit -> Thread.t
    method stop : unit -> unit
  end
Here again, by inheritance and redefinition of the run method,
we can define a new service.
We can test this new version of the server by running the 
protect_serv function.
# let go_serv () = let s = new serv_socket 1400 in s#run () ;;
# let protect_serv () = Unix.handle_unix_error go_serv () ;;
 Multi-tier Client-server Programming
Even though the client-server relation is asymmetric, nothing prevents 
a server from being the client of another service.
In this way, we have a communication hierarchy. 
A typical client-server application might be the following:
- 
 a mail client presents a friendly user interface;
-  a word-processing program is run, followed by an interaction with the user;
-  the word-processing program accesses a database.
One of the goals of client-server applications is to alleviate the processing 
of centralized machines. Figure 20.3 shows two client-server 
architectures with three tiers.
Figure 20.3: Different client-server architectures
Each tier may run on a different machine. 
The user interface runs on the machine running the user mail application.
The processing part is handled by a machine shared by a collection
of users, which itself sends requests to a remote database server.
With this application, a particular piece of 
data may be sent to the user mail application or to the database server.
 Some Remarks on the Client-server Programs
In the preceding sections, we constructed servers for a simple CAPITALIZATION 
service. Each server used a different approach for its implementation.
The first such server used the Unix fork mechanism. Once we
built that server, it became possible to test it with the telnet 
client supplied with the Unix, Windows, and MacOS operating 
systems. Next, we built a simple first client. We were then able 
to test the client and server together. Clients may have tasks 
to manage between communications. For this purpose, we built the 
client_par.exe client, which separates reading from writing 
by using forks. A new kind of server was built using threads
to clearly show the relative independence of the server and the client, 
and to bring input-output into this setting. This server was 
organized into two easily-reused classes. We note that both functional
programming and object-oriented programming support the separation
of ``mechanical,'' reusable code from code for specialized processing.
 
 
