Transcript Lecture #17

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);
give me any available port !
Client/Server Issues
6
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);
Give me the appropriate address
Client/Server Issues
7
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
Iterative
Connectionless
Iterative
Connection-Oriented
Concurrent
Connectionless
Concurrent
Connection-Oriented
Client/Server Issues
15
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
Client/Server Issues
16
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
Client/Server Issues
17
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!
Client/Server Issues
18
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
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.
Client/Server Issues
23
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.
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
Client
Client
Client
Client
Client
Client
Client
Client
Chat
38
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
Client
Client
Client
Server
Client
Client
Client
Client
Client
Chat
40
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
Client
Client
Client
MESSAGES
Server
Client
Client
CONTROL
Client
Client
Client
Chat
42
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
Client
Client
Client
Client
Client
Server
Server
Client
Client
Client
Client
Client
Server
Client
Client
Client
Client
Client
Server
Server
Client
Client
Client
Chat
45
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
I want to be the_one
Client
IRC Network
Server
A
Server
B
I want to be the_one
Client
Chat
51
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