Lecture 17 ClientServer Programming Chat

1
Lecture 17Client/Server ProgrammingChat

• CPE 401 / 601Computer Network Systems

slides are modified from Dave Hollinger
2
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.

3
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.

4
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.

5
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-gts_port is the port number in network
  byte order.

6
Specifying a Local Address

• When a client creates and binds a socket, it
  must specify a local port and IP address
• Typically a client doesnt care what port it is
  on
• haddr-gtport htons(0)

give me any available port !
7
Local IP address

• A client can also ask the operating system to
  take care of specifying the local IP address
• haddr-gtsin_addr.s_addr
• htonl(INADDR_ANY)

Give me the appropriate address
8
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.

9
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

10
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.

11
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 ?

12
Partial Close

• One solution is for the client to shut down only
  its 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!

13
TCP sockets programming

• Common problem areas
• null termination of strings.
• reads dont correspond to writes.
• synchronization (including close()).
• ambiguous protocol.

14
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!

15
Server Design
Iterative Connectionless
Iterative Connection-Oriented
Concurrent Connection-Oriented
Concurrent Connectionless
16
Concurrent vs. Iterative
Concurrent Large or variable size
requests Harder to program Typically uses more
system resources
Iterative Small, fixed size requests Easy to
program
17
Connectionless vs.Connection-Oriented
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
18
Statelessness

• State Information that a server maintains about
  the status of ongoing client interactions.
• Connectionless servers that keep state
  information must be designed carefully!

Messages can be duplicated!
19
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.

20
Concurrent ServerDesign Alternatives

• One child per client
• Spawn one thread per client
• Preforking multiple processes
• Prethreaded Server

21
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()

22
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

23
Prefork()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.

24
Prefork()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.

25
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
• doesnt worry about clients

26
Sockets library vs. system call

• A preforked TCP server wont 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.

27
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

28
Whats 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

29
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.

30
(No Transcript)
31
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.

32
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

33
Message Types

• Some options
• text only
• audio
• images
• anything
• MIME Multipurpose Internet Mail Extensions

34
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?

35
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?

36
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?

37
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?

38
Peer-to-Peer Service Architecture
Client
Client
Client
Client
Client
Client
Client
Client
39
Peer-to-Peer Service Architecture (cont.)

• Each client talks to many other clients.
• Whos on first?
• Is there a well known address for the service?
• How many peers can we keep track of?

40
Client/Server
Client
Client
Client
Server
Client
Client
Client
Client
Client
41
Client/Server

• Server is well known.
• Life is easier for clients
• dont need to know about all other clients.
• Security is centralized.
• Server might get overloaded?

42
Hybrid Possibility
Client
Client
Client
MESSAGES
Server
Client
Client
CONTROL
Client
Client
Client
43
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

44
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.

45
IRC Architecture
Client
Client
Client
Client
Client
Client
Client
Server
Server
Server
Client
Client
Client
Client
Client
Client
Client
Client
Server
Server
Client
Client
Client
46
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.

47
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.

48
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.

49
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.

50
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.

51
Nickname Collision
I want to be the_one
Client
Server A
Server B
I want to be the_one
Client
52
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!)

53
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.

54
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

55
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

56
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.