Implementing a concurrent file server (as an extension of Thread)

• Define a new Class as an extension of the Thread class which has a socket as Object variable.

• Program a constructor which receives a socket as parameter.

• Program the run methods to attend the client connected at the other extreme of the socket.

• Program a main method which consists of an infinite while. Inside the while program the acceptance of a new client, the creation of a new thread with the socket obtained, and the starting of the thread execution.

• The client does not change, in fact, it does not know if it is being served concurrently or in parallel

• See: MultiArchServidorThread.java &MultiArchServidor.java

It is now easy to extend this to a chat system

Hello

Hello

Hello

Hello

Hello

Conditions for implementing a chat system

Server must be listening to requests of new clients AND to messages which are sent by already connected

Client must be listening to messages from the server AND to the keyboard for messages the user wants to transmit.

There are many approaches for implementing this in TCP/IP

No one is the “absolute correct” solution, all them have their advantages and drawbacks

Normally (like everywhere in computers) “faster” solutions will use more memory

Solution 1 The server:

1. A thread listens to new clients trying to join the chat party

2. When a new clients connects, a PrintWriter and a BufferedReader for that client are created. The print Writer is kept in a vector

3. A thread is created and receives a pointer to the PrintWriters’ vector and the BufferedReader. It reads the input from the client and writes it to all PrintWriters (clients)

The client 1. Graphical interface for reading lines from the keyboard (there is

a thread which triggers the execution of the actionPerformed method) and sends it to the server

2. A thread will read input from the server and display it on a text area

See: Chat1Server.java, Chat1ClientThread.java & Chat1Client

Solution 1 Schema

Client1

Client2

Client3

New Client

Thread

PrintWriter

BufferedReader

Solution 2 The server:1. The server has only one thread listening at one port for attending

all the requests of the clients.

2. The clients contact the server for registering (reg), sending a message (msg) or logging out (des)

3. The server keeps a PrintWiter vector to keep track about which clients participate in the chat party. Additionally, it keeps a vector with the nicknames of the clients

The client 1. Graphical interface for reading lines from the keyboard (there is

a thread which triggers the execution of the actionPerformed method) and sends it to the server. It also shows the nicknames of the participants

2. A thread will read input from the server. This can be a message (msg) or a refreshment of the login list

See: CICChat.java & CICServer.java

Solution 2 Schema

Client1

Client2

New Client

Solution 2

Client1

Client2

Client3

Peer-to-peer solution for TCP/IP• Every program should be client and server at the

same time• When a new member wants to join the party,

he/she shoud contact anyone of the group and ask for the list of contacts

• After retrieving the list of contacts (hostnames or addresses) he/she should open an input and output channel with everyone (including the one who provided the list)

Peer-to-peer solution: a user starts a chat party by listening on a port for others wanting to join

A user wanting to join contacts the initiator. An InputStream and an OutputStream is

opened on each

A third user may contact anyone and recover the list of participants, in this case each one

has the address of the other in the list

Then contacts all of them opening Input/Output sreams. All them now have two entries on their

participant list

Particularities of this implementation• The program is written in the ChatPtP.java file• In order to allow testing in one computer, it is necessary to give the

port number at which the program will listen for newcomers • java ChatPtP localport starts a new Chat party • java ChatPtP remotehost remoteport localport joins an existing

party (on remotehost at remoteport a program is waiting for new members)

• The is one thread for listening to newcomers• Another listens for input on keyboard and sends it to all connected

participants• There is one thread listening for input for each of the other

participants • Not very easy, isn’t it ?

Problems of this implementation• What happens if one user leaves the chat party ?• What happens if during the second connection

phase (retrieving the list and contacting the participants) another newcomer joins the party by asking a third one for the list ?

• This is a very critical problem which has been more or less addressed in some (sometimes hard to understand) papers.

Hausaufgabe 1: ftp client und server (ArchClientRobust & ArchServerRobust ergänzen)

• Der Client kann Dateien hoch oder runterladen– PUT filename– GET filename– Die Dateien werden durch einen neuen socket

geschickt/empfangen

• Kann auch die liste der Dateien anfordern– DIR

Hausaufgabe 2: Erweitrn des Peer-to-peer TCP/IP Chat programs um:

(ChatPtP.java)• Das Programm soll eine graphische

Benutzerschnittstelle haben wie beim CICChat• Diese Schnittstelle muss auch zeigen, die

“Nocknames” aller Teilnehmern• Ein Teilnehmer muss sich von der Gruppe

“verabschieden” bevor er die Gruppe verlässt (das will noch längst nicht alle Probleme lösen aber einige schon)

A concurrent web server• This will be implemented only for HTML files and classes (like servlets),

but it is easily extensible for attending different types of requirements • For each client a new thread is created• The process is according to the type of the request

HttpProcessorprocessRequest()

HttpFilebrowser

Httpd (server)

thread

HttpInputStream

HttpOutputStream

HttpClass

HttpException

Echo

HttpClassProcessor

Implementing state in a web server

• The server must keep tracking of the different users that contact it

• The client must submit this information

• The Echo2 class keeps track of a “shopping cart” for different users

• The client must submit a request like:user=username&product=productcode&qtty=number

Architecture of a generic file server

Client Module

Aplication Directory service

Flat file service

Components• Flat File Service: Implements the operations which work

directly on the files. It uses a Unique File Identifier (UFID). A new one is generated for each new file

• Directory Services: is a FFS client , provides a mapping between the UFID and the textual names of the files. It also porvides the necessary functions for managing directories and obtain UFID.Directories are stored as plain files.

• Client module: Runs in every clinet computer, integrates and extends the FFS and DS operations in an interface application used by programmers. Contains information for localizing files over the network. Provides efficiency by implementing a caché

A model for an FFS interface• read(FileId, i, n) : attempts to read up to n bytes from a file

starting from the byte in the position i.

• write(FileId, i, Datos): writes a data sequence starting from the position i into the specified file

• create() : creates a new file (empty) and returns its UFID

• delete(FileId) : deletes the file

• getAttributes(FileId) : returns a structure containing the file attributes

• setAttributes(FileId, attr) : sets the file attributes according to what is stored in the structure

Access Controls• On a local file system it is necessary check the access rights

of the file user only when it is opened and the rights are kept until the file is closed

• On a distributed system the checking are made at the server side. There are two strategies used in order to keep the server stateless:– The checking is done when the filename is converted to the UFID and

the result is packed as a “capacity” which is returned to the client. The client uses this capacity for each further access.

– The checking of the user’s rights is made every time the file is accessed.

• The second one is the most used (in NFS & AFS) because its simplicity

Model for the interface

• Lookup(Dir, File) localises the name of the file in the directory UFID

• AddName(Dir, Name, File) If Name was not in the directory, the pair(Name,File) is added modifying the corresponding file

• UnName(Dir, Name) the pair (Name, file) is deleted from the directory

• getNames(Dir) turns the list of names in the directory

The NFS

Application

Virtual System

SistLocal

ClientNFS

Virtual System

ServerNFS

SistLocal

Caracteristics of the NFS• Communication is implemented over RPC and is open. Resides in the

server’s kernel • The identification of the files is by file handlers containing following

information:

• Filesystem identifier• i-node number or file• i-node generation number

• The “state” is kept in the client in a v-node• Client authentication is done in every access.Client provides ID and

group ID• Flat file & directory services are integrated• The mount service provides a link to a remote system

Cache in NFS• Unix provides standard Cache mechanisms: buffer cache, read ahead,

delayed write

• NFS Cache on Client’s side: data for writing are stored in the cache memory and are written when a commit takes place (buffer full or closing the file)

• NFS Cache on server’s side: results form read, write, getattr, lookup and readdir are stored locally. This can introduce some inconsistencies with the versions stored at the different clients’ machines because writings in one client are not distributed at the moment to the others. Clients are responsible for maintaining their caches updated. This is done with the help of timestamps: – Tc= time of last synchronization of the cache, – Tm= time of modification

– At a certain time T the cache will be still valid if (T - Tc < t) o (Tmcliente = Tmserver). Normally t will be 3-30 secs for files and 30-60 for directories

The AFS• Aims to a better performance in situations of scalability • Principles

– Whole-file serving: the content of the whole file is transferred to the client (even if the client has requested a small part of it)

– Whole-file caching: The file transferred are stored in the local cache memory. The cache is almost permanent.

• Procedure– When the client opens a remote file, the whole content is ttransferred if

it was not there already – Read/write operation are done locally– With a close, a copy of the file is transmitted to the server

The AFS Architecture

Application

Unix Kernel

LocalSist

Venus

Vice

Unix Kernel

Consistency of the Cache• Every time a file is transmitted from the server to a client a callback promise is

provided which guarantees that if other client modifies the file, this one will be notified

• The callback status can be either valid or cancelled • When the file is transferred to the client the callback is put on valid. When a

callback is received from the server (another client did modify the file) the callback promise is put on cancelled

• Every time the client wants to open a file, it searches it first in the cache. It if is there the callback promise status is looked, if it is still valid, the cache is used by the client, if it is not there or the callback is cancelled, a new version is transferred from te server

• If the client’s computer reboots,it asks for a timestamp for every file in the cache to the server. If it is consistent with the local timestamp the callback is put on valid, if not on cancelled