Lecture 17 Client/Server Programming Chat CPE 401 / 601 Computer Network Systems slides are modified from Dave Hollinger

Issues in Client/Server Programming  Identifying the Server.  Looking up an IP address.  Looking up a well known port name.  Specifying a local IP address.  UDP/TCP client design. Client/Server Issues 2

Identifying the Server  Options:  hard-coded into the client program.  require that the user identify the server.  read from a configuration file.  use a separate protocol/network service to lookup the identity of the server. Client/Server Issues 3

Identifying a TCP/IP server  Need an IP address, protocol and port.  We often use host names instead of IP addresses  usually the protocol is not specified by the user UDP vs. TCP  often the port is not specified by the user. Client/Server Issues 4

Services and Ports  Many services are available via “well known” addresses (names).  There is a mapping of service names to port numbers: struct *servent getservbyname( char *service, char *protocol );  servent->s_port is the port number in network byte order. Client/Server Issues 5

Specifying a Local Address  When a client creates and binds a socket, it must specify a local port and IP address  Typically a client doesn’t care what port it is on: haddr->port = htons(0); Client/Server Issues 6 give me any available port !

Local IP address A client can also ask the operating system to take care of specifying the local IP address: haddr->sin_addr.s_addr= htonl(INADDR_ANY); Client/Server Issues 7 Give me the appropriate address

UDP Client Design  Establish server address (IP and port).  Allocate a socket.  Specify that any valid local port and IP address can be used.  Communicate with server (send, recv)  Close the socket. Client/Server Issues 8

Connected mode UDP  A UDP client can call connect() to establish the address of the server  The UDP client can then use read() and write() or send() and recv()  A UDP client using a connected mode socket can only talk to one server  using the connected-mode socket Client/Server Issues 9

TCP Client Design  Establish server address (IP and port).  Allocate a socket.  Specify that any valid local port and IP address can be used.  Call connect()  Communicate with server (read, write).  Close the connection. Client/Server Issues 10

Closing a TCP socket  Many TCP based application protocols support  multiple requests and/or  variable length requests over a single TCP connection.  How does the server known when the client is done ?  and it is OK to close the socket ? Client/Server Issues 11

Partial Close  One solution is for the client to shut down only it’s writing end of the socket.  The shutdown() system call provides this function. shutdown(int s, int direction);  direction can be 0 to close the reading end or 1 to close the writing end.  shutdown sends info to the other process! Client/Server Issues 12

TCP sockets programming  Common problem areas:  null termination of strings.  reads don’t correspond to writes.  synchronization (including close()).  ambiguous protocol. Client/Server Issues 13

TCP Reads  Each call to read() on a TCP socket returns any available data  up to a maximum  TCP buffers data at both ends of the connection.  You must be prepared to accept data 1 byte at a time from a TCP socket! Client/Server Issues 14

Server Design Client/Server Issues 15 Iterative Connectionless Iterative Connectionless Iterative Connection-Oriented Iterative Connection-Oriented Concurrent Connection-Oriented Concurrent Connection-Oriented Concurrent Connectionless Concurrent Connectionless

Concurrent vs. Iterative Client/Server Issues 16 Iterative Small, fixed size requests Easy to program Iterative Small, fixed size requests Easy to program Concurrent Large or variable size requests Harder to program Typically uses more system resources Concurrent Large or variable size requests Harder to program Typically uses more system resources

Connectionless vs. Connection-Oriented Client/Server Issues 17 Connection-Oriented EASY TO PROGRAM transport protocol handles the tough stuff. requires separate socket for each connection. Connection-Oriented EASY TO PROGRAM transport protocol handles the tough stuff. requires separate socket for each connection. Connectionless less overhead no limitation on number of clients Connectionless less overhead no limitation on number of clients

Statelessness  State: Information that a server maintains about the status of ongoing client interactions.  Connectionless servers that keep state information must be designed carefully! Client/Server Issues 18 Messages can be duplicated!

The Dangers of Statefullness  Clients can go down at any time.  Client hosts can reboot many times.  The network can lose messages.  The network can duplicate messages. Client/Server Issues 19

Concurrent Server Design Alternatives  One child per client  Spawn one thread per client  Preforking multiple processes  Prethreaded Server Client/Server Issues 20

One child per client  Traditional Unix server:  TCP: after call to accept(), call fork().  UDP: after recvfrom(), call fork().  Each process needs only a few sockets.  Small requests can be serviced in a small amount of time.  Parent process needs to clean up after children!!!!  call wait() Client/Server Issues 21

One thread per client  Almost like using fork  call pthread_create instead  Using threads makes it easier to have sibling processes share information  less overhead  Sharing information must be done carefully  use pthread_mutex Client/Server Issues 22

Pre fork() ’d Server  Creating a new process for each client is expensive.  We can create a bunch of processes, each of which can take care of a client.  Each child process is an iterative server. Client/Server Issues 23

Pre fork() ’d TCP Server  Initial process creates socket and binds to well known address.  Process now calls fork() a bunch of times.  All children call accept().  The next incoming connection will be handed to one child. Client/Server Issues 24

Preforking  Having too many preforked children can be bad.  Using dynamic process allocation instead of a hard-coded number of children can avoid problems.  Parent process just manages the children  doesn’t worry about clients Client/Server Issues 25

Sockets library vs. system call  A preforked TCP server won’t usually work the way we want if sockets is not part of the kernel:  calling accept() is a library call, not an atomic operation.  We can get around this by making sure only one child calls accept() at a time using some locking scheme. Client/Server Issues 26

Prethreaded Server  Same benefits as preforking.  Can also have the main thread do all the calls to accept()  and hand off each client to an existing thread Client/Server Issues 27

What’s the best server design for my application?  Many factors:  expected number of simultaneous clients  Transaction size time to compute or lookup the answer  Variability in transaction size  Available system resources perhaps what resources can be required in order to run the service Client/Server Issues 28

Server Design  It is important to understand the issues and options.  Knowledge of queuing theory can be a big help.  You might need to test a few alternatives to determine the best design. Client/Server Issues 29

Chat: Issues and Ideas for Service Design  Pretend we are about to design a chat system.  We will look at a number of questions that would need to be answered during the design process.  We will look at some possible system architectures. Chat 31

Multi-user Chat Systems Functional Issues  Message types.  Message destinations (one vs. many groups)  Scalability (how many users can be supported)  Reliability?  Security authentication authorization privacy Chat 32

Message Types  Some options:  text only  audio  images  anything MIME: Multipurpose Internet Mail Extensions Chat 33

Message Destinations  Each message goes to a group (multi-user chat)  Can we also send to individuals?  Should we support more than one group? Are groups dynamic or static? What happens when there is nobody in a group? Can groups communicate? Can groups merge or split? Chat 34

Scalability  How large a group do we want to support?  How many groups?  What kind of service architecture will provide efficient message delivery?  What kind of service architecture will allow the system to support many users/groups? Chat 35

Reliability  Does a user need to know (reliably) all the other users that receive a message?  What happens if a message is lost?  resend?  application level or at user level?  What happens when a user quits?  Does everyone else need to know? Chat 36

Security  Authentication  do we need to know who each user is?  Authorization  do some users have more privileges than others?  Privacy  Do messages need to be secure?  Do we need to make sure messages cannot be forged? Chat 37

Peer-to-Peer Service Architecture Chat 38 Client

Peer-to-Peer Service Architecture (cont.) Each client talks to many other clients.  Who’s on first?  Is there a well known address for the service?  How many peers can we keep track of? Chat 39

Client/Server Chat 40 Client Server

Client/Server  Server is well known.  Life is easier for clients  don’t need to know about all other clients.  Security is centralized.  Server might get overloaded? Chat 41

Hybrid Possibility Chat 42 Client Server CONTROL MESSAGES

Hybrid  Clients connect to server and gather control information:  List of other clients.  List of chat groups.  Messages are sent directly (not through server).  Could use connectionless protocol UDP or transaction based TCP Chat 43

Internet Relay Chat  IRC is a widely used multi-user chat system.  Supports many chat groups (channels).  Extensive administrative controls.  Distributed service architecture.  Still in use today, although WWW based chat is now more common. Chat 44

IRC Architecture Chat 45 Client Server Client Server Client

Server Topology  Servers are connected in a spanning tree  Single path between any 2 servers.  New servers can be added dynamically support for preventing cycles in the server graph.  A collection of servers operates as a unified system,  users can view the system as a simple client/server system. Chat 46

Server Databases  Each server keeps track of  all other servers  all users (yes, really all users!)  all channels (chat groups)  Each time this information changes, change is propagated to all participating servers. Chat 47

Clients  A client connects to the system by establishing a TCP connection to any server.  The client registers by sending:  (optional) password command  a nickname command  a username command. Chat 48

Nicknames and user names  A nickname is a user supplied identifier that will accompany any messages sent.  Wizard, kilroy, gargoyle, death_star, gumby  The username could be faked,  some implementations use RFC931 lookup to check it  Users can find out the username associated with a nickname. Chat 49

Collisions  If a client requests a nickname that is already in use, the server will reject it.  If 2 clients ask for the same nickname on 2 different servers,  it is possible that neither server initially knows about the other. Chat 50

Nickname Collision Chat 51 Server A Server A Server B Server B IRC Network Client I want to be the_one Client I want to be the_one

Nickname Propagation  The command used to specify a nickname is forwarded to all other servers  using the spanning tree topology  Extra information is added by the original server:  server name connected to client with nickname.  Hop count from the server connected to the client hop count is IRC server count (not IP!) Chat 52

Channels  2 kinds of channels  local to a server start with ‘&’ character  global, span the entire IRC network start with the ‘#’ character  Users can JOIN or PART from a channel.  A channel is created when the first user JOINS, and destroyed when the last user PARTS. Chat 53

Messages  All messages are text.  A message can be sent to nicknames, channels, hosts or servers.  There are two commands for sending messages:  PRIVMSG: response provided.  NOTICE: no response (reply) generated. Avoids loops when clients are automatons Chat 54

Other Stuff  Special class of users known as Operators.  Operators can remove users!  Servers can be told to connect to another server  operators create the spanning tree  The tree can be split if a node or network fails  there are commands for dealing with this Chat 55

Problems  Scalability  Currently every server needs to know about every other server, every channel, and every user.  Path length is determined by operators, an optimal tree could be generated automatically.  Need a better scheme for nicknames  too many collisions  Current protocol means that each server must assume neighbor server is correct.  Bad guys could mess things up. Chat 56