Escuela Politcnica Nacional

Aplicaciones Distribuidas

Rodolfo Lpez


Anlisis de Sistemas


ESFOT


Titulo

Sockets


Problema
En el mundo de las telecomunicaciones cada vez va evolucionando a pasos
agigantados por lo que los sistemas distribuidos se estn posicionando
cada vez ms fuertemente en este mbito y los sockets juegan un papel muy
importante en este mbito pero muchos profesionales de las TICs no
conocen de manera detallada el funcionamiento de los mismos.

Objetivos especficos:
1. Conocer que es un socket sus caractersticas y propiedades.
2. Saber los tipos de sockets que existen.
3. Saber porque se usan los sockets en sistemas distribuidos
4. Cmo funcionan los sockets
5. Conocer la filosofa cliente servidor.
6. Ventajas de usar sockets

Resumen
Para que dos programas puedan comunicarse entre s es necesario que se
cumplan ciertos requisitos:
Que un programa sea capaz de localizar al otro.
Que ambos programas sean capaces de intercambiarse cualquier
secuencia de octetos, es decir, datos relevantes a su finalidad.
Para ello son necesarios los dos recursos que originan el concepto
de socket:
Un par de direcciones del protocolo de red (direccin IP, si se
utiliza el protocolo TCP/IP), que identifican la computadora de
origen y la remota.
Un par de nmeros de puerto, que identifican a un programa dentro
de cada computadora.
Los sockets permiten implementar una arquitectura cliente-servidor. La
comunicacin debe ser iniciada por uno de los programas que se denomina
programa "cliente". El segundo programa espera a que otro inicie la
comunicacin, por este motivo se denomina programa "servidor".
Un socket es un proceso o hilo existente en la mquina cliente y en la
mquina servidora, que sirve en ltima instancia para que el programa
servidor y el cliente lean y escriban la informacin. Esta informacin ser
la transmitida por las diferentes capas de red.

Desarrollo

LOS SOCKETS.
Los sockets no son ms que puntos o mecanismos de comunicacin entre
procesos que permiten que un proceso hable ( emita o reciba informacin )
con otro proceso incluso estando estos procesos en distintas mquinas.
Esta caracterstica de interconectividad entre mquinas hace que el
concepto de socket nos sirva de gran utilidad. Esta interfaz de
comunicaciones es una de las distribuciones de Berkeley al sistema UNIX,
implementndose las utilidades de interconectividad de este Sistema
Operativo ( rlogin, telnet, ftp, ... ) usando sockets. Un socket es al
sistema de comunicacin entre ordenadores lo que un buzn o un telfono
es al sistema de comunicacin entre personas: un punto de comunicacin
entre dos agentes ( procesos o personas respectivamente ) por el cual se
puede emitir o recibir informacin. La forma de referenciar un socket por
los procesos implicados es mediante un descriptor del mismo tipo que el
utilizado para referenciar ficheros. Debido a esta caracterstica, se podr
realizar redirecciones de los archivos de E/S estndar (descriptores 0,1 y
2) a los sockets y as combinar entre ellos aplicaciones de la red. Todo
nuevo proceso creado heredar, por tanto, los descriptores de sockets de
su padre.

Propiedades
Las propiedades de un socket dependen de las caractersticas del protocolo
en el que se implementan. El protocolo ms utilizado es Transmission
Control Protocol; una alternativa comn a ste es User Datagram
Protocol.
Cuando se implementan con el protocolo TCP, los sockets tienen las
siguientes propiedades:
Son orientados a la conexin.
Se garantiza la transmisin de todos los octetos sin errores ni omisiones.
Se garantiza que todo octeto llegar a su destino en el mismo orden en que
se ha transmitido.
Estas propiedades son muy importantes para garantizar la correccin de
los programas que tratan la informacin.
El protocolo UDP es un protocolo no orientado a la conexin. Slo se
garantiza que si un mensaje llega, llegue bien. En ningn caso se garantiza
que llegue o que lleguen todos los mensajes en el mismo orden que se
mandaron. Esto lo hace adecuado para el envo de mensajes frecuentes
pero no demasiado importantes, como por ejemplo, un streaming de audio.
Caractersticas
Todo socket viene definido por dos caractersticas fundamentales:
1 - El tipo del socket, que indica la naturaleza del mismo, el tipo de
comunicacin que puede generarse entre los sockets.
2 - El dominio del socket especifica el conjunto de sockets que pueden
establecer una comunicacin con el mismo.
Tipos de sockets
Define las propiedades de las comunicaciones en las que se ve envuelto
unsocket, esto es, el tipo de comunicacin que se puede dar entre cliente y
servidor.
Estas pueden ser:
- Fiabilidad de transmisin.
- Mantenimiento del orden de los datos.
- No duplicacin de los datos.
- El "Modo Conectado" en la comunicacin.
- Envo de mensajes urgentes.
Los tipos disponibles son los siguientes:
* Tipo SOCK_DGRAM: sockets para comunicaciones en modo no
conectado, con envo de datagramas de tamao limitado (tipo telegrama ).
En dominios Internet como la que nos ocupa el protocolo del nivel de
transporte sobre el que se basa es e lUDP.
* Tipo SOCK_STREAM: para comunicaciones fiables en modo
conectado, dedos vas y con tamao variable de los mensajes de datos. Por
debajo, en dominios Internet, subyace el protocolo TCP.
* Tipo SOCK_RAW: permite el acceso a protocolos de ms bajo nivel
como el IP( nivel de red )
*Tipo SOCK_SEQPACKET: tiene las caractersticas
del SOCK_STREAM pero adems el tamao de los mensajes es fijo.
Uso
Se usan sockets porque es el unico medio de comunicacin entre
procesos.
Funcionamiento
La comunicacin entre procesos a travs de sockets se basa en la filosofa
CLIENTE-SERVIDOR: un proceso en esta comunicacin actuar
de proceso servidor creando un socket cuyo nombre conocer el proceso
cliente, el cual podr "hablar" con el proceso servidor a travs de la
conexin con dicho socket nombrado.
El proceso crea un socket sin nombre cuyo valor de vuelta es un
descriptor sobre elque se leer o escribir, permitindose una
comunicacin bidireccional, caracterstica propia de los sockets y que los
diferencia de los pipes, o canales de comunicacin unidireccional entre
procesos de una misma mquina.
El mecanismo de comunicacin va sockets tiene los siguientes pasos:
1) El proceso servidor crea un socket con nombre y espera la
conexin.
2) El proceso cliente crea un socket sin nombre.
3) El proceso cliente realiza una peticin de conexin al
socket servidor.
4) El cliente realiza la conexin a travs de su socket mientras
el proceso servidor mantiene el socket servidor original con nombre.
Es muy comn en este tipo de comunicacin lanzar un proceso hijo, una
vezrealizada la conexin, que se ocupe del intercambio de informacin con
el proceso cliente mientras el proceso padre servidor sigue aceptando
conexiones.
Para eliminar esta caracterstica se cerrar el descriptor del socket
servidor con nombre en cuanto realice una conexin con un proceso socket
cliente.
-> Todo socket viene definido por dos caractersticas fundamentales:
- El tipo del socket, que indica la naturaleza del mismo, el tipo de
comunicacin que puede generarse entre los sockets.
- El dominio del socket especifica el conjunto de sockets que pueden
establecer una comunicacin con el mismo.
FI LOSOFI A CLI ENTE-SERVI DOR:

Servidor.

Vamos a explicar el proceso de comunicacin servidor-cliente en modo
conectado, modo utilizado por las aplicaciones estndar de Internet
(telnet, ftp). El servidor es el proceso que crea el socket no nombrado y
acepta las conexiones a l.
El orden de las llamadas al sistema para la realizacin de esta funcin es:
1) int socket ( int dominio, int tipo, int protocolo )
crea un socket sin nombre de un dominio, tipo y protocolo especfico
dominio : AF_INET, AF_UNIX
tipo : SOCK__DGRAM, SOCK__STREAM
protocolo : 0 ( protocolo por defecto )

2) int bind ( int dfServer, struct sockaddr* direccServer, int longDirecc )
nombra un socket: asocia el socket no nombrado de descriptor dfServer con la
direccin del socket almacenado en direccServer. La direccin depende de si estamos
en un dominio AF_UNIX o AF_INET.
3) int listen ( int dfServer, int longCola )
especifica el mximo nmero de peticiones de conexin pendientes.

4) int accept ( int dfServer, struct sockaddr* direccCliente, int* longDireccCli)
escucha al socket nombrado servidor dfServer y espera hasta que se
reciba la peticin de la conexin de un cliente. Al ocurrir esta incidencia, crea
un socket sin nombre con las mismas caractersticas que el socket servidor
original, lo conecta al socket cliente y devuelve un descriptor de fichero que
puede ser utilizado para la comunicacin con el cliente.




El Cliente.

Es el proceso encargado de crear un socket sin nombre y posteriormente
enlazarlo con el socker servidor nombrado. O sea, es el proceso que demanda
una conexin al servidor. La secuencia de llamadas al sistema es:

1) int socket ( int dominio, int tipo, int protocolo ) crea un socket sin nombre
de un dominio, tipo y protocolo especfico
dominio : AF_INET, AF_UNIX
tipo : SOCK__DGRAM, SOCK__STREAM
protocolo : 0 ( protocolo por defecto )

2) int connect ( int dfCliente, struct sockaddr* direccServer, int longDirecc )
intenta conectar con un socket servidor cuya direccin se encuentra
incluida en la estructura apuntada por direccServer. El descriptor dfCliente se
utilizar para comunicar con el socket servidor. El tipo de estructura depender
del dominio en que nos encontremos.
Una vez establecida la comunicacin, los descriptores de ficheros sern
utilizados para almacenar la informacin a leer o escribir.
SISTEMA DE COMUNICACIONES BINDER


Resolucin: La traduccin del nombre por el identificador de
comunicacin.
Inclusin: Aadir una pareja nombre/identificador al servidor de nombres.
Borrado: Eliminar una entrada del servidor de nombres.
Modificacin: Modificacin del nombre/identificador de una entrada.

Para acceder a un objeto remoto, el proceso cliente (que slo conoce el
nombre del recurso) debe conseguir el identificador de comunicacin del
recurso que solicita antes de comunicarse realmente con l. Para ello debe
acudir primero a los servidores de nombres intermedios necesarios hasta
conseguir dicho identificador de comunicacin, con el consiguiente tiempo
de demora debido a los tiempos de resolucin o traduccin de cada uno de
los servidores de nombres requeridos.
Cuando se est accediendo a menudo a un objeto remoto, para evitar el
tiempo de resolucin de los nombres intermedios, el proceso cliente puede
mantener una tabla cachcon los identificadores de direccin de los
objetos ms recientemente referenciados, y utilizar directamente estos
identificadores para acceder a los objetos.
SEGURI DAD

Control de acceso
. Para evitar accesos no autorizados a los recursos del sistema, un primer
paso consiste en hacer que el identificador de un recurso no se pueda
obtener fcilmente a partir de su nombre si no es a travs del servidor de
nombres. Y, por supuesto, el servidor de nombres debe ocuparse de
comprobar la identidad del cliente que solicita una resolucin de nombres
antes de darles el identificador solicitado. Los identificadores que se
comportan as, se denominan credenciales (capabilities)
. Por eso se dice que para poder acceder a un recurso o servicio,
previamente debe obtenerse la credencial correspondiente.
Ejemplo:
Credencial de Amoeba
. Cuando un cliente requiere cierto servicio, en primer lugar se identifica y
solicita la credencial correspondiente al servidor de nombres, el cual
devuelve la credencial solicitada para el cliente identificado. Una vez se
tiene la credencial, se obtiene de ella el Puerto del servidor que va a
prestar el servicio requerido, con lo que ya se le puede enviar el mensaje
con la peticin del servicio y la credencial completa.
El campo Objetolo utiliza el servidor para identificar el objeto especfico
con el que el cliente quiere realizar alguna operacin. Para el caso de un
archivo, este campo sera algo parecido a un i-nodo de Unix.
Los Derechos estn compuestos por una serie de bits que indican las
operaciones que le estn permitidas al usuario para ese objeto (por ej.
lectura, escritura, ...).
El campo Verificacin se utiliza para dar validez a la credencial. La
verificacin la establece el servidor de nombres mediante un cierto
algoritmo en funcin del resto de los campos de la credencial, y el servidor
del objeto comprueba si la verificacin que le llega efectivamente es la
correspondiente a esa credencial. De ser as, y si cuenta con los derechos
apropiados realiza la operacin solicitada; en caso contrario, devolver
algn cdigo de error al cliente.
De esta manera se evita que cualquier proceso de la red solicite
indiscriminadamente cualquier operacin, pues las credenciales solamente
las pueden construir los servidores de nombres, y solamente mediante stas
puede solicitarse operaciones a los servidores.
Tipos de datos en la comunicacin
Cliente y binder o servidor de nombres
El cliente se comunica con el servidor de nombres enviando toda su
informacin(ip,puerto) para hacer su primera peticin la cual es
procesada con el servidor de nombres para darle un id e incluir la
direccin en el servidor tambin puede ,eliminar o modificar dicha
informacin en el binder.


Codigo Tipo de dato descripcion
in char Aade un nuevo id
del char Borra un id
change char Cambia un id

Restablecimiento de comunicacin en caso de un servidor cado
1.-comprobar conexin el binder realiza esto automticamente
ping t [HOSTNAME de su Servidor Dedicado]
2.-el binder reinicia la conexion
Para descartar que la cada del servidor haya sido causada por una
posible instalacin divergente y/o por una incorrecta configuracin del
software, le pedimos llevar a cabo los siguientes pasos:
1. Establezca una conexin directa con su servidor mediante SSH-Console
y regstrese en la consola con la cuenta "root".
Si no puede establecer conexin directa con su servidor mediante SSH-
Console, cree la conexin a travs de RemoteConsole.
Si no puede establecer conexin con su servidor mediante SSH-Console ni
tampoco mediante RemoteConsole, contacte por favor con el soporte
tcnico. Nuestros expertos de STRATO le atendern gustosamente.
3.Se guarda el archivo "vi /var/log/warn" como duplicado en la carpeta
"/tmp", para que en caso de necesidad pueda envarselo por mail al
soporte tcnico. Cree el duplicado del archivo con el siguiente comando:
cp /var/log/warn /tmp


4. Busca en el archivo de trazas (log) las entradas que durante el ltimo
proceso de inicio (Boot) indiquen un error. Para ello indique el siguiente
comando:

dmesg | grep [Ee]rro
Este comando busca las entradas que contengan la palabra "Erro" o
"erro" en el archivo log del inicio.
Es posible que se muestren entradas que contengan las palabras "Error",
"error" o "erroneous". Slo las entradas que contengan las palabras
"Error", "error" o "erroneous" sern tenidas en cuenta para el anlisis de
la cada del servidor.
dmesg | grep [Ff]ault
Este comando busca las entradas que contengan la palabra "Fault" o
"fault" en el archivo log del inicio.
Es posible que se muestren entradas que contengan las palabras "Fault",
"fault" o "faulty". Slo las entradas que contengan las palabras "Fault",
"fault" o "faulty" sern tenidas en cuenta para el anlisis de la cada del
servidor.
dmesg | grep [Nn]o
Este comando busca las entradas que contengan la palabra "No" o "no"en
el archivo log del inicio.
Slo las entradas que contengan estas palabras o "none" sern tenidas en
cuenta para el anlisis de la cada del servidor.
dmesg | grep [Dd]efect
Este comando busca las entradas que contengan la palabra "Defect" o
"defect" en el archivo log del inicio.
Slo las entradas que contengan estas palabras sern tenidas en cuenta
para el anlisis de la cada del servidor.
dmesg | grep [Bb]ad
Este comando busca las entradas que contengan la palabra "Bad" o
"bad"en el archivo log del inicio.
Slo las entradas que contengan estas palabras sern tenidas en cuenta
para el anlisis de la cada del servidor.
dmesg | grep [Ff]ail
Este comando busca las entradas que contengan la palabra "Fail" o "fail"
en el archivo log del inicio.
Es posible que se muestren entradas que contengan las palabras "Failed",
"failed", "Failure" o "failure". Slo las entradas que contengan estas
palabras sern tenidas en cuenta para el anlisis de la cada del servidor.
dmesg | grep [Ii]ncorrect
Este comando busca las entradas que contengan la palabra "Incorrect" o
"incorrect" en el archivo log del inicio.
Slo las entradas que contengan estas palabras sern tenidas en cuenta
para el anlisis de la cada del servidor.

5. Guarda en la carpeta "/tmp" todas las entradas registradas durante el
ltimo proceso de inicio (Boot), para que en caso de necesidad pueda
envarselo por mail al soporte tcnico. Para ello indique el siguiente
comando:
dmesg > /tmp/dmesg


6. Establece la conexin mediante RemoteConsole en caso de que an no
lo haya hecho.


7. Reinicia el servidor indicando en la RemoteConsole el siguiente
comando:
reboot
Hinweis Se reinicia el servidor se llevar a cabo inmediatamente tras
indicar este comando.

8. Corre el proceso de inicio tanto como sea posible, hasta saber si se
puede conectar con su servidor o no. Copie todas las entradas que se
muestren en la RemoteConsole como archivos de texto,
independientemente de si la conexin resulta exitosa o no.
Hinweis Copie el contenido de la RemoteConsole en el portapapeles
marcando todas las entradas con el botn izquierdo del ratn.


9.Se revisa los avisos de error existentes en el contenido del archivo de
texto guardado.
Hinweis Si el inicio de uno o varios servicios (Daemons), programas o
scripts indican una entrada "Failed" o algn comentario similar, ha de
revisar la configuracin de estos servicios/ programas/ scripts y
corregirlos.
Hinweis STRATO no ofrecer soporte para cualquier tipo de Software que
no forme parte de la configuracin que el Servidor Dedicado tiene por
defecto.
10. Si mediante el paso arriba indicado:
a) puede localizar la causa que provoc la cada del servidor pero no
puede solucionarlo,
b) no puede localizar la causa que provoc la cada del servidor, rogamos
hacer llegar por email a nuestro servicio tcnico los siguientes archivos:
el archivo /tmp/warn
el archivo /tmp/dmesg
el archivo que contiene las entradas del proceso de inicio (Boot) de su
Servidor Dedicado
Luego de estos pasos el Binder podr saber si se puede recabar
informacin que estuvo en el servidor antes del fallo o no .lo que se
recomienda en un caso asi es siempre tener un servidor espejo para evitar
asi la perdida de informacin vital en el proceso de comunicacin entre
servidores o bien con el cliente
Fuentes
http://html.rincondelvago.com/servidor-de-nombres.html
http://www.dia.eui.upm.es/asignatu/Sis_dis/Transparencias/T3-
ServicioDeNombres.pdf
http://strato-faq.es/article/