Notes On Chapter Three -- Network Programming And Applications

• 3.1 Introduction
  
  
  • This chapter is about the manner in which a programmer uses the network (API's)
    
    
  • The programmer doesn't need to think about or understand how the network actually works.
    
    
  • Library functions provide the programmer's interface to the network. The programmer simply "operates" the network by calling the library functions.
    
    
• 3.2 Network Communication
  
  
  • Typically a program (process) running on computer X sends a request for a service to a process on computer Y, and the process on Y replies to the process on X.
    
    
  • The network is just the passive medium for the message exchange.
    
    
• 3.3 Client-Server Computing
  
  
  • A server program waits for requests. The address of the server is "well-known" through some sort of advertisement.
    
    
  • The client program, aware of the address of the server, sends it a message requesting the service. The client includes its own address in the message so that the server will know where to send its replies.
    
    
  • In effect the addresses used have two parts. One part of the address identifies the computer to which the message is being sent. The other part of the address identifies which process (running program) the message is intended for.
    
    
  • Instead of "addresses," typically humans use "names" to designate computers and processes. However, network software ultimately translates these names into numerical addresses.
    
    
• 3.4 Communication Paradigm -- the typical steps
  
  
  • Server starts and waits for requests
    
    
  • Client initiates request
    
    
  • Client and server exchange messages
    
    
  • When ready, client and server send end-of-file signals to terminate communication.
    
    
• 3.5 An Example Application Program Interface (API)
  
  
  • await_contact -- used by a server to wait for contact from a client
    
    
  • make_contact -- used by a client to contact a server
    
    
  • cname_to_comp -- used to translate a computer name to an equivalent internal binary value.
    
    
  • appname_to_appnum -- used to translate a program name to an equivalent internal binary value
    
    
  • send -- used by either client or server to send data
    
    
  • recv -- used by either client or server to receive data
    
    
  • send_eof -- used by both client and server after they have finished sending data
    
    
• 3.6 An Intuitive Look At The API
  
  
  
  • The figure illustrates the calls that would typically be made by a very simple server and client. In this communication session the client sends one request and receives one reply.
    
    
  • Note that the client uses the send_eof operation to tell the server that the client will not send any more data. Also, the server uses the send_eof operation to inform the client that the server will send no more data. When both processes have done a send_eof, both know that the session is over.
    
    
  • Note that the client and server would block indefinitely if they both tried to send after initiating their session. This simple example illustrates an important general principle: there has to be an agreement ahead of time about the manner in which the communication will proceed. In this case, there is a preexisting understanding that initially the client will send data and the server will receive. Such agreements are called protocols
    
    
• 3.7 Definition of the API
  
  
  • 3.7.1 The Await_Contact Function
    
    
    • Purpose: wait for a connection to a client.
    • symbolic prototype --> connection await_contact (appnum a)
    • "appnum a" denotes the type of service offered by the server.
    • "connection" denotes the connection to a client returned by the function
    
    
    
  • 3.7.2 The Make_Contact Function
    
    
    • Purpose: establish a connection to a server.
    • symbolic prototype --> connection make_contact (computer c, appnum a)
    • "computer c" designates the host to which the client is connecting.
    • "appnum a" denotes the type of service the client desires.
    • "connection" denotes the connection to a server returned by the function.
    
    
    
  • 3.7.3 The Appname_to_appnum Function
    
    
    • Purpose: Look up the number corresponding to a name.
    • symbolic prototype --> appnum appname_to_appnum (char *a)
    • "char *a" is the name of a service.
    • "appnum" is the service number returned.
    
    
    
  • 3.7.4 The Cname_to_comp Function
    
    
    • Purpose: Look up the number corresponding to a name.
    • symbolic prototype --> computer cname_to_comp (char *a)
    • "char *a" is the name of a computer (host name).
    • "computer" is the ID number of a computer (host id) returned.
    
    
    
  • 3.7.5 The Send Function
    
    
    • Purpose: Send data over a connection.
    • symbolic prototype --> int send (connection con, char *buffer, int length, int flags)
    • "connection con" is the connection over which to send.
    • "char *buffer" is the base address of an array containing the characters to be sent.
    • "int length" is the number of characters to be sent.
    • "int flags" is a special code -- normally zero.
    • "int" is the number of characters transferred by send, or negative value if an error occurs.
    
    
    
  • 3.7.6 The Recv and Recvln Functions
    
    
    • Purpose: Read data that has arrived on a network connection.
    • symbolic prototype --> int recv(connection con, char *buffer, int length, int flags)
    • Purpose: Read an entire line of data that has arrived on a network connection.
    • symbolic prototype --> int recvln(connection con, char *buffer, int length)
    • "connection con" is the connection from which to read.
    • "char *buffer" is the base address of an array into which the characters are to be copied.
    • "int length" is the capacity of the buffer.
    • "int flags" is a special code -- normally zero.
    • "int" is the number of characters copied into the buffer, or 0 if eof has been reached, or a negative value to indicate an error condition.
    
    
    
  • 3.7.7 The Send_eof Function
    
    
    • Purpose: The caller uses this function to inform the party at the other side of the connection that the caller will send no more characters.
    • symbolic prototype --> int send_eof(connection con)
    • "connection con" is the connection to send on.
    • "int" is the return value -- negative to signal an error condition, else nonnegative.
    
    
    
  • 3.7.8 Summary of API Types
    
    
• 3.8 Code For An Echo Application
  
  
  
  • 3.8.1 Example Echo Server Code: echoserver.c
    
    
  • Example Call: echoserver 20000
    
    
  • 3.8.2 Example Echo Client Code: echoclient.c
    
    
  • Example Call: echoclient pollux.csustan.edu 20000
    
    
  • One Lesson Taught by This Example: A receiver cannot assume that data will arrive in the same size pieces it was sent.
    
    
• 3.9 Code For A Chat Application
  
  
  • 3.9.1 Example Chat Server Code: chatserver.c
    
    
  • Example Call: chatserver 25000
    
    
  • 3.9.2 Example Chat Client Code: chatclient.c
    
    
  • Example Call: chatclient pollux.csustan.edu 25000
    
    
• 3.10 Code For A Web Application
  
  
  • 3.10.1 Example Web Client Code: webclient.c
    
    
  • Example Call: webserver 27000
    
    
  • 3.10.2 Example Web Server Code: webserver.c
    
    
  • Example Call: webclient pollux.csustan.edu /index.html 27000
    
    
• 3.11 Managing Multiple Connections With The Select Function
  
  
  • The typical OS makes available a function called select() which a process can use to determine which of several connections have data available to read.
    
    
  • By using select() a process can manage multiple network connections.
    
    
• 3.12 Summary