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

Lecture 17

Client/Server ProgrammingChat

CPE 401 / 601Computer 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.


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.


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.


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 !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);


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


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


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.


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 ?


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!


TCP sockets programming

Common problem areas:

null termination of strings.

reads don’t correspond to writes.

synchronization (including close()).

ambiguous protocol.


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!


Server Design


IterativeConnectionless

IterativeConnectionless

IterativeConnection-Oriented

IterativeConnection-Oriented

ConcurrentConnection-Oriented

ConcurrentConnection-Oriented

ConcurrentConnectionless

ConcurrentConnectionless

Concurrent vs. Iterative


Iterative

Small, fixed size requestsEasy to program

Iterative

Small, fixed size requestsEasy to program

Concurrent

Large or variable size requestsHarder to program

Typically uses more system resources

Concurrent

Large or variable size requestsHarder to program

Typically uses more system resources

Connectionless vs.Connection-Oriented


Connection-Oriented

EASY TO PROGRAMtransport protocol handles the tough stuff.

requires separate socket for each connection.

Connection-Oriented

EASY TO PROGRAMtransport protocol handles the tough stuff.

requires separate socket for each connection.

Connectionless

less overheadno limitation on number of clients

Connectionless

less overheadno 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!


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


Concurrent ServerDesign Alternatives

One child per client

Spawn one thread per client

Preforking multiple processes

Prethreaded Server


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


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


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.


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.


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


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.


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


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


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.


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 onlyaudioimagesanything

•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

ClientClient

ClientClient

ClientClient

ClientClient

ClientClient

ClientClient

ClientClientClientClient

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

ClientClient

ClientClient

ClientClient


ClientClient

ClientClient

ClientClient

ServerServer

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

ClientClient

ClientClient

ClientClient


ClientClient

ClientClient

ClientClient

ServerServer

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

ClientClient

ClientClient

ClientClient

ClientClient


ClientClient

ClientClient

ServerServerClientClient

ClientClient

ClientClient


ClientClient

ClientClient

ServerServerServerServer

ServerServer ServerServerClientClient

ClientClient

ClientClient

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

ServerA

ServerA

ServerB

ServerB

IRC Network

ClientClient

I want to be the_oneI want to be the_one

ClientClient

I want to be the_oneI 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

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

Documents

Transcript of Lecture 17 Client/Server Programming Chat CPE 401 / 601 Computer Network Systems slides are modified...