1 ===============================
2 Sistemas Distribuidos I (75.74)
3 ===============================
5 -------------------------
6 Práctica de sockets y RPC
7 -------------------------
9 :Author: Leandro Lucarella (77891)
14 La práctica se divide en componentes comunes y específicos:
17 Funciones comunes, para salida formateada usando write(2).
20 Funciones generales de sockets.
23 Programas pertenecientes a la primera parte, el servidor iterativo concurrente
24 utilizando TCP. Se compone de 3 programas:
30 Servidor concurrente tipo inetd (hace un fork(2) para cada nueva conexión
31 llamando a serverhandler).
34 Servidor iterativo encargado de manejar la conexión.
37 Programas pertenecientes a la segunda parte, el servidor utilizando RPC
38 Se compone de 2 programas:
44 Servidor RPC con las funciones remotas.
50 Para compilar los programas basta con usar `make`.
56 Ambas versiones del programa se utilizan de igual forma. Hay que correr primero
57 el servidor y luego el cliente. El cliente toma la entrada del usuario por
58 entrada estándar. Se aceptan comandos del tipo::
60 OPERACION PARTE1 PARTE2 ... PARTEN
62 Donde OPERACION es: put, find o del. put agrega un string al set, enviando N
63 mensajes al servidor (uno por cada parte y enviando una marca de fin en el
64 último para que se procese), el string es la concatenación de todas las partes).
65 put devuelve 0 si tuvo éxito o 1 si ya había un string igual. find se fija si un
66 string determinado, retornando 0 si está o 1 si no. del elimina un string del
67 set, retornando 0 si se tuvo éxito o 1 si no se encontró.
69 El programa se detiene (enviando un comando QUIT) cuando se ingresa una línea
70 vacía o se cierra la entrada estándar.
72 Para hacer pruebas exhaustivas se provee de un script llamado test.sh (en ambas
73 variantes de la práctica) que corre varios clientes simultáneamente realizando
74 operaciones al azar. El servidor debe ser lanzado antes.
80 El protocolo tiene como objetivo manipular un set de datos (un conjunto de
81 strings) en el servidor. Hay 3 operaciones soportadas: PUT, FIND y QUIT. Cada
82 operación viene acompañada por un id de cliente, una marca de fin, y una
83 porcion del string a agregar/buscar/quitar. La operación se concreta recién al
84 recibir la última porción del string (indicado por la marca de fin) y el string
85 utilizado para la operación es la concatenación de las porciones recibidas en
86 cada mensaje. El paquete de "request" tienen entonces la siguiente estructura::
88 +----------+---------+----------+----------+---------------+
89 | type | end | clientid | lenght | payload (opt) |
90 +----------+---------+----------+----------+---------------+
91 /- 2 bits -/- 1 bit -/- 5 bits -/- 1 byte -/- 0-255 bytes -/
95 Es el tipo de mensaje: PUT (0), FIND (1), DEL (2), QUIT (3).
98 Marca de fin, indica cuando se está enviando la última porción de un comando.
104 Tamaño del payload en bytes.
107 Fragmento del string que compone el comando.
110 Al recibir la última porción, el servidor procesa el pedido y envía una
111 respuesta con el resultado. El paquete de la respuesta se compone únicamente de
112 un int (entero de 4 bytes). Cada valor es un código de resultado. En general
113 siempre el valor 0 se usa para indicar operación exitosa. En caso de error los
114 siguientes resultados están definidos:
126 Esta variante es prácticamente igual a la anterior sólo que se utilizan llamadas
127 a procedimientos remotos para enviar cada comando. La firma de estos
128 procedimientos (hay uno por cada comando o "type") es::
130 int prodedimiento(string payload, int end, int clientid);
132 A excepción del QUIT que sólo lleva como parámetro al clientid. Al ser cada
133 fragmento de un comando una llamada a procedimiento remoto, siempre se obtiene
134 un resultado, pero el resultado que vale es el de la última llamada (la que
135 lleva end en 1) ya que es en este momento cuando se realiza el procesamiento.
136 Para implementar esto se utilizaron archivos temporales para ir "acumulando" los
137 fragmentos del comando, utilizando un archivo por cada cliente conectado para
138 evitar "colisiones". Los códigos de retorno utilizados son los mismos que en la
139 variante anterior y toda la semántica del protocolo es también la misma.
142 .. vim: filetype=rst :