Programming Servers

1
Programming Servers

• October 2003

2
Programming the Server

• What happens on the server when the client tries
  to establish a rendezvous ?
• The server starts listening to requests on a
  ServerSocket
• After accepting the request the resulting
  connection is attached to another (normal) socket
  (same type as clients socket)

3
Sockets at the Server Side (1)

• The server should start by creating a server
  socket bound to a certain port according to the
  protocol of the service.
• ServerSocket listening
• listening new ServerSocket(5555)
• This will create the socket but the server is
  still not listening. To do this we should apply
  the following method to the socket
• Socket toClient listening.accept()
• This sentence works the following way
• accept blocks the execution of the program until
  there is a petition for a rendezvous from a
  client (with calling new Socket(host, 555)
• When the requirement arrives, a tcp connection is
  established between the two computers. The client
  receives in its socket one end of this link and
  the server the other. The server sides socket
  (from the Socket class) is chosen conveniently by
  the system

4
Sockets at the Server Side(2)

• At the server side we can apply the same methods
  as we did at the client side. Particularly we may
  need to open an input and an output data stream.
• After this, the server should implement the
  communication protocol which was established and
  published (by any other possible mean). It is
  important that both side follow this protocol in
  order not to block the communication and/or miss
  some data. This mean nothing else than following
  the turn taking rules of writing to and reading
  from the socket and the format of the data to be
  exchanged.
• Note that the server socket (and port) at which
  the server was originally listening to requests
  is not used anymore. This is a design issue (why
  ?)

5

A Date Server
We will program now a date server for a computer
which has no one
3) answer with the date in another socket
4) close the connection
Client
Date server
13
1) Create the server socket 2) start listening
DateClient2
DateServer
6

An Echo Server
We will program now an echo server for a computer
which has no one
4) answer with the same
3) Request a line
Client
Date server
7
1) Create the server socket 2) start listening
Do 3 4 until client disconnects or sends a line
with
EchoServer
EchoClient2
7
Something rather simple to start

• The TalkServer waits for someone wishing to
  communicate
• The TalkClient asks for a host name and tries
  the redezvous
• After the communication is set up, everything
  the client user types in will be transmitted to
  the talk server and this will display it on the
  screenboard

Bla bla from keyboard
Bla bla
Talk Server
Talk client
8
Schema of both programms
Open server socket port 4444 While(true)
accept call open reading from socket
while (true) read line from socket
if (line.equals(bye)) break
write line to screen //end of the
call
snew Socket(args0,4444) open writing to
socket while (true) read line from
keyboard write to socket if
(line.equals(bye)) break
TalkClient
TalkServer
9
Sockets File transfer

• We will now develop programs for transmitting
  files
• In the first case, the program receiving the file
  starts listening for someone who wants to upload
  a file
• The sender knows where (hostname and port number)
  the server is listening and sends a rendezvous
  request
• The data transfer is done at the byte level in
  order to allow the transfer of non textual files

10
Uploading files

• The sender tries a
• rendezvous with receiver

• The reciver starts listening for
• Requests to send (upload) files

4) Send bytes
3) Read bytes from file
5) Write bytes in file
Repeat 3,4,5 until all the file is transmitted
ArchEnviador.java
ArchRecibidor.java
11
Version 2 Requesting files

• The file server
• Starts listening for requests on a known port
• When a request is accepted, a string
  corresponding to a filename is read
• Opens locally a file with this name, reads it
  and sends it to the client (byte-wise)
• The file client
• Tries a rendezvous with the server
• Reads a filename from keyboard and send it to the
  server
• Reads bytes from socket and write them to a file

12
Requesting files by their names
1) Filename from keyboard
2) Request file
4) Send file
3) Read File
5) Write file
Repeat 3,4,5 until all the file is transmitted
ArchServidor.java
ArchCliente.java
13
A more robust version
1) Sends filename
2) Answers OK (or not OK)
3) Opens another socket
4) Send file
ArchClienteRobust.java
ArchServidorRobust.java
14
Servers with or without state ?

• What is a state of a server ?
• The state is the information that servers keep
  about the interaction has occurred with the
  clients
• What for is it used ?
• Generally it will make the the management of the
  dialogue more efficient event in the case small
  amount of information is kept and maintained it
  will reduce the amount of information that has to
  flow between client and server to accomplish a
  certain task
• Answers from the server will be faster
• Why is it generally avoided ?
• Its a source for errors messages from the client
  may get lost, arrive duplicates, or array in
  disorder. Clients can crash and reboot, which may
  cause in certain cases the information kept on
  the servers to be erroneous, and also their
  responses

15
An example of using state for file transfer

• The file server should waits for a client
  request. It accepts 2 types of commands from the
  client reading from and writing into a file. The
  sever executes this command and returns the
  outcome of the operation to the client
• Situation without maintaining a state
• For reading, the client must always specify the
  name of the file, position in the file to start
  reading and the number of bytes (lines) to read.
• For writing, the client must provide the name of
  the file, the position in the file to start
  writing and the data that will be written

16
Situation with state

• When the client opens a file an entry is created
  in the table. The entry has a file handle and the
  current position for reading/writing (initially
  0). The client receives the handle as response.
• When the client wants to read data from the file,
  it just sends the handle and the number of bytes
  (lines). This is used by the server in order to
  know exactly which bytes to read. It has to
  change the position value
• When the client wants to write data on a file it
  provides the handle and the data. The server uses
  this and the table informatio to update the file
• When the clients closes a file is has to send a
  message in order to delete the entry from the
  table

17
The stateless server for remote files
Requirement to open XYZ
A CLIENT
A SERVER
?
Response file XYZ exists and ready
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
18
The server does not remember the former
requirements
Requirement read from XYZ starting from byte 0 ,
50 bytes
A CLIENT
A SERVER
?
Response the content (byte array)
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
19
All information bust be provided again !
Requirement read from XYZ starting from byte 50
, 50 bytes
A CLIENT
A SERVER
?
Response the content (byte array)
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
20
This may cause a lot of network traffic,
especially if there are many clients
Requirement read from XYZ, starting from byte N,
50 bytes
A CLIENT
A SERVER
?
Response the content (byte array)
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
21
Stateful Server Manintains a table
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
Pointer file Pos
0 XYZ 0
1 ZXY 50
Req. open XYZ
A CLIENT
A SERVER
?
Response file pointer for XYZ
22
The information which clients has to prive is
lesser
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
Pointer File Position
0 XYZ 50
1 ZXY 50
Req. 0, read 50
A CLIENT
A SERVER
?
Response the content
23
The information in the table must be updated
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
Pointer File Position
0 XYZ 100
1 ZXY 50
Req. 0, read 50
A CLIENT
A SERVER
?
Response the content
24
It is important to close the file
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
Pointer File Position
0 XYZ 100
1 ZXY 50
Req. 0, read 50
A CLIENT
A SERVER
?
Response the content
25
Possible sources for errors

• The net may send the request two times (if an ack
  does not arrive UDP)
• The client program may crash and reboot
• The client computer crashes before it can close
  the file
• Another client may connect to the same socket
  (UDP)
• In a real internet network, where mashines
  can crash and reboot, and the messajes may get
  lost, duplicated, or in a incorrect order, to
  maintain a fault tolerant server with state may
  be extreamly difficult.

26
1 An attempt of writing a file server with state

• This implementation will server sequential text
  file (can be easily changed)
• It receives requests for opening a file for
  reading or writing, read next line, write line.
• The state is stored in a hashtable which
  contains objects of the classes BufferedReader
  and PrintWriter
• See

FileServerWitState.java
2 An example of a file server without state

• This implementation will server random access
  files (can be easily changed)
• It receives requests for reading/writing a
  certain number of bytes from/into a file
• See fileservernostate.java

FileServerNoState.java
27
Architecture of a generic file server
Directory service
Aplication
Flat file service
Client Module
28
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é

29
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

30
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 users rights is made every
  time the file is accessed.
• The second one is the most used (in NFS AFS)
  because its simplicity

31
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

32
The NFS
Application
Virtual System
Virtual System
Server NFS
Sist Local
Sist Local
Client NFS
33
Caracteristics of the NFS

• Communication is implemented over RPC and is
  open. Resides in the servers 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

34
Cache in NFS

• Unix provides standard Cache mechanisms buffer
  cache, read ahead, delayed write
• NFS Cache on Clients 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 servers 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 lt t) o (Tmcliente Tmserver).
  Normally t will be 3-30 secs for files and 30-60
  for directories

35
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

36
The AFS Architecture
Application
Unix Kernel
Vice
Local Sist
Venus
Unix Kernel
37
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 clients 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