Programming Servers

1
Programming Servers
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
3) answer with the same
2) read line
4)
Client
Date server
1) accept
7
1) Create the server socket 2) start listening
Do 2 3 until client disconnects
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
Servidores Con o sin Estado

• Qué es el Estado ?
• El estado es la información que los servidores
  mantienen acerca de la interacción que se lleva a
  cabo con los clientes.
• Para qué ?
• Generalmente se hace más eficiente el
  comporatamiento de los servidores con
  información. Información muy breve mantenida en
  el servidor puede hacer más chicos los mensajes o
  permite producir respuestas más rápido.
• Y entonces por qué se evita a veces ?
• Es fuente de errores mensajes del cliente pueden
  perderse, duplicarse llegar en desorden. El
  cliente puede caerse y rebootear, con lo cual la
  información que tiene el servidor de él es
  errónea y también sus respuestas

15
Un ejemplo del servidor de Archivos

• El servidor espera que un cliente se conecte
  por la red. El cleinte puede mandar 2 tipos de
  requerimientos leer o escribir datos en un
  archivo. El servidor realiza la operación y
  retorna el resultado al cliente.
• Situación sin guardar información acerca del
  estado
• Para leer, el cliente debe siempre especificar
  nombre de archivo, posición en el archivo desde
  dónde debe extraer los datos y el número de bytes
  a leer.
• Para escribir debe especificar el nombre completo
  del archivo, el lugar donde quiere escribir y los
  datos que quiere escribir

16
Un ejemplo del servidor de Archivos (II)

• Situación guardardando información del estado

• Cuando el cliente abre un archivo se crea un
  entrada en la tabla. A la entrada se le asigna un
  handle para identificar el archivo y se le asigna
  la posición actual (inicialmente 0). El cliente
  recibe el handler como respuesta.
• Cuando el cliente quiere extrer datos adicionales
  le envia el handle y la cantidad de bytes. Esto
  es usado por el servidor para saber gracias a la
  tabla de dónde exactamente debe extraer los datos
  (debe actualizar la posición para que para la
  próxima vez se pueda hacer lo mismo).
• Cuando el cliente termina la lectura/escritura
  envía un mensaje para sea eliminada la entrada de
  la tabla

17
Otro ejemplo consulta bases de datos

• El cliente hace consultas a bases de datos.
  En la primera consulta el resultado es muy
  grande. Quiere refinar la consulta basada e los
  resultados obtenidos hasta ahora
• Situación sin guardar información acerca del
  estado
• El servidor debe mandar todo el resultado de la
  consulta al cliente, el cliente debe mantenerla
• El cliente debería ser capaz de hacer consultas
  localmente o si no mandar la query con el
  conjunto de resultados obtenidos la vez anterior

18
Otro ejemplo carro de compras

• El servidor espera que un cliente se conecte
  por la red. Consulte los productos que hay y vaya
  seleccionando productos. El cliente se mueve
  entre la búsqueda y la selección
• Situación sin guardar información acerca del
  estado
• La lista completa de items seleccionada por el
  cliente debe ser constantemente transmitida entre
  cliente y servidor

19
Otro ejemplo transacciones bancarias

• El servidor necesita que el cliente se
  identifique con username y password para hacer
  una transacción o consulta
• Situación sin guardar información acerca del
  estado
• Por cada transacción que quiere hacer el cliente
  se va a necesitar la información de
  autentificación del cliente

20
Problemas al mantener un estado

• En el servidor de Archivo ?
• En las consultas a una base de datos ?
• En un carro de compras ?
• En transacciones ?

21
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
22
Arquitectura de un Servidor de Archivos
Servicio de Directorio
Aplicación
Servicio plano de archivo (flat)
Módulo Cliente
23
Componentes

• Flat File Service Implementa las operaciones
  directamente sobre los archivos. Trabaja con
  Unique File Identifieres (UFID). Se genera uno
  nuevo por cada archivo
• Directory Services Cliente de el FFS, provee un
  mapeo entre los UFID y los nombre textuales de
  los archivos y las funciones necesarias para
  administrar directorios y obtener las UFID. Los
  directorios se guardan como archivos planos.
• Módulo Cliente Corre en cada computador, integra
  y extiende las operaciones del FFS y DS en una
  aplicación interfaz usada por los programadores.
  Posee información acerca de la localización de
  archivos en la red. Provee eficiencia a través de
  un cache

24
Modelo de Interfaz para FFS

• read(FileId, i, n) le hasta n bytes de un
  archivo a partir de la posición i los que retorna
  en un arreglo
• write(FileId, i, Datos) escribe la secuencia de
  datos en el archivo a partir de la posición i
  extendiéndolo en caso
• create() crea un archivo nuevo de largo 0 y
  devuelve el UFID para él
• delete(FileId) borra el archivo
• getAttributes(FileId) retorna una estructura
  con los atributos
• setAttributes(FileId, attr) pone los atributos
  según la estructura

25
Controles de acceso

• En un sistema local el chequeo se hace sólo al
  abrir el archivo y los derechos se conservan
• en un sistema distribuido los chequeos se deben
  hacer a nivel de servidor. Para que el servidor
  siga siendo stateless se pueden usar 2
  estrategias
• El chequeo se hace cuando el nombre es convertido
  en UFID y el resultado es codificado en forma de
  capacidad que se retorna al cliente, el cual lo
  usa para futuros accesos
• La identificación del usuario se hace cada vez
  que se manda un request y el chequeo se hace para
  cada operación
• El segundo es más usado (en NFS y AFS) por su
  simplicidad, pero ninguno garantiza seguridad en
  el caso de identidad suplantada

26
Modelo de interfaz para Directory Service

• Lookup(Dir, File) localiza el nombre de texto en
  el directorio y retorna el UFID
• AddName(Dir, Name, File) Si Name no estaba en el
  directorio dado añade el par (Name,File) en el
  directorio modificando el archivo pertinente
• UnName(Dir, Name) el par (Name, file)
  correspondiente es borrado del directorio
• getNames(Dir) retirna la lista de nombres que
  contiene un directorio

27
Ejemplo 1 el NFS
Aplicación
Sistema Virtual
Sistema Virtual
Server NFS
Sist Local
Sist Local
Client NFS
28
Características de NFS

• La comunicación es por medio de RPC y es abierta
  en el servidor, que reside en el kernel
• La identificación de archivos es por medio de los
  llamados file handters consistentes en
• Filesystem identifier
• i-node number or file
• i-node gerneration number
• El estado se guarda en el cliente en un v-node
• Autentificación del cliente en cada llamada
  mandando user ID y group ID
• Los servicios de flat file y directory están
  integrados
• El servicio de mount provee un link a un sistema
  remoto

29
Cache en NFS

• Cache en Unix buffer cache, read ahead, delayed
  write
• Cache en servidor datos de escritura se guardan
  en memoria cache y son escritas antes del reply
  al cleinte. En la versión 3 se guarda todo en
  cache hasta que se recibe la operación commit
  para ese archivo (buffer lleno o close)
• Cache en el cliente resultados de read, write,
  getattr, lookup y readdir se almacenan
  localmente, lo cual puede introducir
  inconsistencias en versiones en los distintos
  clientes ya que escrituras de un cliente no se
  actualizan en seguida en los otros. Los clientes
  son entonces responsables de mantener
  actualizados sus caches por medio de timestamps
  Tc tiempo de la última actualización, Tm tiempo
  de modificación. A un tiempo T el cache será
  válido si (T - Tc lt t) o (Tmcliente Tmserver).
  Normalmente 3-30 seg para archivos y 30-60 para
  directorios

30
Interfaz de NFS simplificada

• read(FileId, i, n) le hasta n bytes de un
  archivo a partir de la posición i los que retorna
  en un arreglo
• write(FileId, i, Datos) escribe la secuencia de
  datos en el archivo a partir de la posición i
  extendiéndolo en caso
• create() crea un archivo nuevo de largo 0 y
  devuelve el UFID para él
• delete(FileId) borra el archivo
• getAttributes(FileId) retorna una estructura
  con los atributos
• setAttributes(FileId, attr) pone los atributos
  según la estructura

31
Ejemplo 2 El AFS

• Apunta a lograr mejor performance en situaciones
  de escalabilidad
• Whole-file serving El contenido de todo los
  directorios archivos son traspasados al cleinte
• Whole-file caching Los archivos transmitidos son
  guardados en cache local. Normalmente varios
  cientos de archivos ! El cache es casi
  permanente.
• Cuando se hace un open del archivo se transmite
  el archivo entero si no estaba
• las operaciones de escritura/lectura se hacen
  localmente
• Con el close, se transmite una copia modificada
  al servidor
• Debe

32
The AFS Architecture
Application
Unix Kernel
Vice
Local Sist
Venus
Unix Kernel
33
Consistencia del Cache

• Cada vez que se traspasa un archivo del servidor
  a un cliente se provee de una promesa de
  callback, que garantiza que cuando otro cliente
  modifique el archivo este será notificado
• El callback puede estar en dos estados valido o
  cancelado
• Cuando el archivo es traspasado al cliente el
  callback se pone en válido. Cuando se recibe un
  callback del servidor (porque el archivo fue
  modificado) se pone en cancelado
• Cada vez que el cliente abre un archivo busca si
  está en su cache. Si está se revisa el callback.
  Si está cancelado se trae una copia nueva del
  archivo, si está válido, se usa el archivo del
  cache
• Si la estación de trabajo se reinicia (por que se
  apagó o se cayó) pide para cada archivo de su
  cache el timestamp de la última modificación
• si la última modificación es consistente con la
  copia se pone el callback en válido, si no en
  cancelado