Unidad Ii

Sistemas Distribuidos I - Unidad II Jorge Guerra Guerra
52 Sistema a Distancia

Segunda Unidad
Comunicacin entre procesos

Propsitos

Esta unidad estudia las caractersticas de la comunicacin entre procesos,
presentando los diferentes modelos de implementacin y sus parmetros mas
conocidos. Se estudian los fundamentos para la implementacin de sockets y su
uso bajo diferentes lenguajes de programacin. Se mostrar las caractersticas del
modelo Peer to Peer como una alternativa importante de aplicaciones distribuidas.
El estudiante podr implementar soluciones informticas utilizando cualquier tipo de
socket para las operaciones de comunicacin de procesos que necesite realizar.
Sumario

Caractersticas de la comunicacin entre procesos. Medio de comunicacin, mtricas
de medicin, relacin con la calidad del envio de mensajes. Capa de transporte:
caracterstica y protocolos, tipo de servicios en el nivel transporte. Sockets
implementacin y tipos, ejemplos de cdigo usando socket.


Leccin 4
Caractersticas de la comunicacin entre procesos

Del captulo anterior podemos resumir que la funcin principal de todo Sistema
Distribuido es el de permitir que un proceso llamado cliente pueda comunicarse
con otro proceso servidor, diciendo por ello, que no solamente es importante que el
mensaje enviado por el emisor llegue al receptor, sino que dicho mensaje sea
entendido para poder ser procesado por el servicio solicitado y generar por lo tanto
una salida.

La comunicacin entre procesos trata bsicamente del problema de establecer
conexin entre cliente y servidor nicamente, por lo que daremos por sentado dos
conceptos importantes:

a) El cliente de alguna manera conoce la localizacin del servidor que posee el
servicio en el que est interesado.
b) El cliente enva su mensaje al servidor y dicho mensaje llega tal cual es, no
considerndose participacin alguna del medio de comunicacin que permite su
envo.

Esto quiere decir, que en este captulo no estaremos considerando aun la
participacin del MIDDLEWARE dentro de las operaciones de comunicacin de
procesos, dicha funcin se ver en otro captulo ms adelante.

4.1 Generalidades sobre comunicacin entre procesos

Una definicin que se puede establecer sobre el trmino comunicacin entre
procesos nos dice que, es la cooperacin entre procesos para lograr un objetivo
global. Podramos decir que dicho objetivo sera la ejecucin de un servicio, lo que
podra dar dos escenarios:

a) Un proceso cliente enva un mensaje solicitando un servicio a un proceso
servidor esperando una respuesta de este.
b) Un proceso servidor que necesitando completar la operacin que est ejecutando
para generar respuesta a una peticin de servicio enva un mensaje a otro proceso
servidor pidiendo ejecucin de una operacin la cual entregara datos necesarios
para la culminacin y generacin de respuesta.

Esto quiere decir que, cada proceso realiza una labor definida y en forma conjunta
logra el objetivo global sealado lneas arriba.

Existen dos formas de comunicacin de procesos:

a) Procesos locales: Se establece que el proceso emisor y receptor se encuentran
en el mismo computador, por lo tanto, ocupando el mismo bloque de memoria. A
esta categora pertenecen las aplicaciones de tipo Standalone las cuales no son
motivo de este captulo.
b) Procesos remotos: Se establece que el proceso emisor y receptor se encuentran
en equipos computacionales diferentes y que por lo tanto se requiere de un medio
de comunicacin que permita el envo de los mensajes entre ellos. A esta categora
pertenecen las aplicaciones basadas en LAN y WAN.

Se debe mencionar tambin que la implementacin de la comunicacin entre
procesos es un concepto diferente al utilizado por el mecanismo de comunicacin

del sistema operativo que puede estar usando la maquina cliente o la mquina
servidor. Adems se considera una relacin entre la comunicacin y la
sincronizacin entre procesos de tal manera que se establecen dos conceptos:

a) si queremos sincronizar debemos establecer comunicacin, esto se debe a que
no existe un reloj global en el Sistema Distribuido.
b) si queremos comunicar debemos establecer un sincronismo entre los procesos.

Dentro de la nocin de comunicacin entre procesos se establecen dos modalidades
de interaccin:

1) Unicast: es la tpica comunicacin entre un proceso emisor con un proceso
receptor como se muestra en la figura siguiente:

Fig.35 Comunicacin Unicast

2) Multicast: Cuando un proceso emisor enva un mensaje a varios procesos
receptores, como en el grfico siguiente:

Fig.36 Comunicacin multicast

4.2 Implementacin de la comunicacin entre procesos

Como se indic en el capitulo anterior los Sistemas Distribuidos pretenden integrar
aplicaciones de diferente tecnologa y plataforma no importando la ubicacin en la
que se encuentren, por lo que se hace indispensable la disponibilidad de un sistema
de comunicacin eficiente. Por lo tanto, el medio de comunicacin se considera
(cableado o por aire) la espina dorsal de un Sistema Distribuido, por lo que se hace
indispensable establecer mtricas o unidades de medicin que permitan medir la
eficiencia del funcionamiento y caractersticas de lo que se considera la capa 1, 2 y
3 del modelo OSI. De acuerdo a [Colouris et al,2005], estos valores se les
denomina factores de comunicacin, los cuales pueden clasificarse de la siguiente
manera:

a) De rendimiento, tenemos latencia (tiempo de espera del proceso cliente hasta
recibir respuesta del proceso servidor); ratio de transferencia (velocidad de envo
de un mensaje medido en bit por segundo); ancho de banda (cantidad de bits
enviados por unidad de tiempo).
b) Escalabilidad, mide el aumento de clientes que pueden acceder a los servicios
disponibles (escalabilidad horizontal); o el aumento de servicios a que los clientes
pueden acceder sin problemas dentro del entorno distribuido (escalabilidad
vertical).
c) Fiabilidad, mide la perdida de datos de un mensaje durante su envo, su unidad
es bits por cada 10
6
bits.

d) Seguridad, define criterios de seguridad del mensaje enviado a travs del medio
de comunicacin como mtodo descifrado o encriptacin, generacin de certificado
o firma digital, etc.
e) Calidad de servicio, capacidad de establecer mecanismos de reserva y garanta
del ancho de banda usado para la comunicacin.
f) Comunicacin en grupo, capacidad del emisor de envo de mensajes en modo
Unicast (solo a un receptor) o multicast (a varios receptores de manera
simultnea).

4.3 Modelos de comunicacin entre procesos

Establecida las caractersticas de comunicacin entre procesos se definen dos
modelos bsicos para establecimiento de dicha comunicacin, el modelo de
memoria compartida y el modelo de paso de mensajes.

4.3.1 Memoria compartida

En este modelo el proceso cliente y el proceso servidor comparten una zona comn
en que los mensajes podrn ser compartidos entre ambos, considerada como zona
pblica en la que el cliente deposita su mensaje y el servidor lo recoge, colocando
posteriormente en dicha zona. El modelo centralizado en funcin al Mainframe es
un buen ejemplo de este modelo, ya que todos los terminales tontos estaban
fsicamente conectados a ste computador, manejndose como punto central y su
memoria estaba disponible para todos ellos. Actualmente, el modelo de base de
datos distribuida es un moderno ejemplo de memoria compartida, ya que los
clientes en esta implementacin pueden acceder a los datos, no importando a cual
base de datos esta accediendo ni la localizacin de esta, tanto para operaciones de
consulta, como transaccionales.

4.3.2 Paso de mensajes

En este modelo el proceso cliente y el proceso servidor se encuentran en mquinas
distintas y no tienen ningn elemento comn entre ellos, por lo que solo se servirn
del medio de comunicacin para intercambiarse mensajes. Actualmente, este es el
modelo ms utilizado en los Sistemas Distribuidos y las principales
implementaciones usan sus caractersticas. Hay tres formas de implementacin en
comunicacin con paso de mensajes y son paso de mensaje puro, llamada a
procedimientos remotos e invocacin a objeto distribuido.

Fig. 37 Paso de mensajes

4.3.2.1 Paso de mensaje puro

En esta implementacin el proceso cliente enva una cadena de caracteres con
destino a proceso servidor, posteriormente el proceso servidor devolver otra
cadena de caracteres como respuesta al envo inicial. Ambas cadenas de
caracteres sern procesadas y generadas por las personas que manejan los equipos
computacionales por lo que la implementacin de los mensajes no seguir algn
patrn especfico sino quedara a libre albedro de los usuarios humanos generar la

cadena de caracteres que convenga. Un ejemplo de esta implementacin es el chat
y el correo electrnico.

La implementacin del modelo de paso de mensaje puro se realiza a travs de los
sockets, definindose el tipo socket de acuerdo a las caractersticas dadas por la
capa de transporte.

Fig. 38 Paso de mensaje puro

Observacin: Invocacin remota, ejecucin remota de servicio.

4.3.2.2 Llamada a procedimientos remotos

En esta implementacin el proceso cliente enva un mensaje con destino a un
proceso servidor, a diferencia de la implementacin anterior dicho mensaje
contendr el nombre de un servicio solicitado del tipo Procedure y que tendr
posiblemente datos de entrada, debido a ello el proceso servidor deber realizar
una validacin previa a travs de un anlisis sintctico y semntico de dicho
mensaje antes de proceder a su ejecucin. Las primeras implementaciones
basadas en este concepto se realizaron en C++, aprovechando la particularidad de
que en este lenguaje cada operacin que el programa contena, tenia forzosamente
que tener en la parte inicial una declaracin abstracta de dicha operacin lo cual
era de una gran utilidad debido a que bastaba con revisar el inicio del programa
para verificar la existencia o no del servicio a consultar.

RPC es la tecnologa ms conocida para este tipo de implementacin

Fig. 39 Llamada a procedimientos

Observacin: Invocacin remota, ejecucin remota de servicio.

4.3.2.3 Invocacin a objeto distribuido

En esta implementacin el proceso cliente solicita un servicio a un proceso servidor
de manera similar a la llamada a procedimientos remotos reseada lneas atrs,
pero con una diferencia fundamental: los servicios a consultar son mtodos, por lo
tanto son pertenecientes a una clase existente en dicho proceso servidor. Debido a
ello, necesariamente debe instanciarse la clase referida generando por ello un
objeto que residir en la mquina donde est el proceso cliente y mediante dicho
objeto se podr solicitar el servicio requerido y posteriormente recoger los
resultados.

CORBA, RMI, DCOM, son ejemplos de esta implementacin.


Fig. 40 Invocacin a objetos remotos

Observacin: Invocacin local, ejecucin remota de servicio.

4.4 Arquitectura de comunicaciones

La implementacin de una infraestructura de comunicaciones destinada a ser
posible la comunicacin entre un proceso emisor y uno receptor es una tarea
primordial en todo Sistema Distribuido, y esto corresponde a las capas 1 y 2 del
modelo OSI (nivel fsico y de enlace). Existen dos modelo definidos para una
arquitectura de comunicaciones eficiente y son el modelo cliente/servidor y el Peer
to peer.

4.4.1 Modelo cliente/servidor

Este modelo define dos roles diferentes para la interaccin entre procesos: cliente
quien es el que solicita el servicio y enva una peticin proporcionando el nombre de
la operacin y los datos necesarios para su ejecucin; el proceso servidor quien
proporciona el servicio a ejecutar y enva como respuesta el resultado. En la figura
siguiente se muestra un diagrama esquemtico de dicho modelo.

Fig. 41 Modelo cliente/servidor bsico

Este modelo bsico solo es til en una comunicacin de tipo mono cliente, es decir,
solo atiende a un cliente por vez. Por esta razn, se desarrollaron modelos
alternativos que mejoraron el concepto inicial.

4.4.1.1 Modelo con proxy o cach

En este modelo el proceso cliente deja su peticin en un servidor intermedio
denominado servidor proxy, el cual utilizando un mecanismo de cola de mensajes
pone las peticiones en una secuencia de llegada para que posteriormente el
servidor que contiene el servicio los atienda respetando dicha secuencia. Este
modelo permite la ejecucin de servicios de mltiples servidores mejorando por ello
el modelo bsico. Si el servidor proxy posee memoria de alta velocidad se le
denomina cach lo cual optimiza mas el rendimiento de la ejecucin del servicio.
Es la primera implementacin multiproceso desarrollada, posteriormente se
mejorara este modelo incluyendo la utilizacin de hilos para la asignacin por parte
de los clientes de un tiempo de ejecucin de servicio hacia el servidor, llegndose a

una implementacin de tipo concurrente. En la figura siguiente se muestra su
implementacin.

Fig. 42 Modelo proxy

4.4.1.2 Modelo multicapa

En este modelo el proceso servidor no necesariamente tiene la capacidad de poder
ejecutar de manera completa el servicio solicitado por el servidor, debiendo en
algn momento convertirse en un cliente temporal que solicita apoyo a otro
servidor. Una particularidad de este modelo es que la interaccin entre servidores
es totalmente transparente al cliente por lo que no se requiere por parte de ste
ninguna invocacin o solicitud de servicio especial para la ejecucin. Existen varias
implementaciones conocidas que utilizan este modelo como por ejemplo la llamada
a un servicio perteneciente a una aplicacin web y que posteriormente dicha
aplicacin solicita datos a un manejador de base de datos, a continuacin un grfico
que muestra esta implementacin.

Fig. 43 Modelo multicapa

4.4.2 Modelo Peer to peer

Alternativamente al modelo cliente/servidor descrito lneas anteriores, surge el
modelo Peer to peer cuya particularidad principal es la utilizacin del rol entidad
para describir a los participantes de la comunicacin entre procesos. Esto se debe
a que no existe un cliente permanente o un servidor permanente debido a que un
proceso que solicita el servicio podra en otro momento proveer de servicios si as
fuera necesario.

En esta implementacin cada una de las entidades establece coordinacin con las
dems en una configuracin de tipo todos contra todos. Un ejemplo de esta
implementacin son las redes de comparticin de archivos, tambin conocidas con

el nombre de redes P2P, que saltaron a la fama por su uso masivo en comparticin
de msica, videos o documentos, nombres famosos de este tipo de redes son
Napster, Emule, Ares, etc. Como implementacin de software libre existe un
software denominado JXTA de Sun Microsystems y que se puede considerar como
una API destinada a crear redes del tipo P2P, como por ejemplo Jabber producto de
mensajera instantnea construido en software libre. A continuacin un grfico que
representa este modelo:

Fig. 44 Modelo P2P

4.5 Fundamentos sobre comunicacin entre procesos

Para entender la lgica que est detrs de la implementacin de una comunicacin
entre procesos se necesita conocer algunos conceptos sobre teora de la
informacin y criterios de telecomunicaciones que researemos a continuacin.

4.5.1 Elementos de la comunicacin entre procesos

Dado que en un ambiente distribuido la comunicacin entre procesos se realizar
entre diferentes maquinas, para establecer dicha comunicacin de modo eficiente
se requerirn, tres elementos fundamentales, [Cisco,2007] como lo indica:

a) Red de comunicaciones: Es el medio fsico a travs del cual el mensaje enviado
por el emisor hacia el receptor viajara. Esta red puede ser cableada o
inalmbrica[Schwartz, 1994].
b) Lenguaje comn de comunicacin: Se deber establecer un lenguaje que tanto
el emisor como el receptor reconozcan y utilicen para el entendimiento del mensaje
que se transmitir.
c) Protocolo de transporte: Se definir una forma comn de envo de mensajes de
tal manera que tanto en el lado emisor (que generalmente convertir el mensaje en
paquetes para su envo) como el receptor (que recibir dichos paquetes y mediante
un algoritmo de reconstruccin recuperara el mensaje original), utilizaran tanto
para la solicitud de servicio como para la recepcin de la respuesta.

La ausencia de cualquiera de estos tres elementos traer como consecuencia la
imposibilidad de la comunicacin entre procesos.

4.5.2 Niveles de comunicacin

Tomando como base [Tschudin,2000], la comunicacin entre procesos una vez
definida necesitara de un conjunto de elementos necesarios para el establecimiento
del envo y recepcin de mensajes, que son los siguientes:

a) Los extremos de la comunicacin entre procesos: En esta categora pertenecen
el emisor que es el proceso que enva el mensaje conteniendo generalmente una

solicitud de servicio; proceso receptor cuya funcin es recibir el mensaje enviado
por el emisor.
b) Cola de mensajes: Existen dos la cola de mensajes salientes, utilizada por el
emisor para colocar all los mensajes que se van a enviar al receptor; cola de
mensajes entrantes, utilizada por el receptor para recuperar los mensajes enviados
por los diferentes emisores. Generalmente las colas de mensajes guardan de
manera secuencial los mensajes de acuerdo a su llegada.
c) Primitivas de funcin: Son las operaciones que se utilizan dentro de la ejecucin
de una comunicacin entre procesos. Son dos, enviar (send) operacin por la cual
el emisor enva su mensaje con destino al receptor; recibir (receive) operacin por
la cual el receptor recupera el mensaje que le ha sido enviado, un grfico que
representa estos elementos se muestra a continuacin.

Fig. 45 Diagrama bsico de comunicacin de procesos

4.5.3 Tipos de comunicacin

La comunicacin entre procesos en su implementacin se clasifica en dos tipos
caractersticos que son [Dragoni,2010]:

a) Comunicacin sncrona: En esta comunicacin el emisor enva su mensaje con
destino al receptor y mientras espera la llegada de la respuesta, dicho emisor se
bloquea, es decir no hace absolutamente nada, mientras dure el tiempo de espera.
Para la implementacin de este tipo de comunicacin la operacin recibir debe
estar en estado bloqueante, mantenindose la operacin enviar como no
bloqueante.
b) Comunicacin asncrona: En esta comunicacin el emisor enva su mensaje con
destino al receptor y a continuacin regresa a ejecutar otras operaciones de su
cdigo sin esperar una recepcin inmediata de respuesta. Cuando el receptor enve
la respuesta con destino al emisor ste ser notificado mediante algn mecanismo
(por ejemplo una interrupcin enmascarable), con el fin de que suspenda
temporalmente las operaciones que est realizando y proceda a la recuperacin de
la respuesta transmitida. Para la implementacin de este tipo de comunicacin la
operacin de enviar y recibir son no bloqueantes.

Considerando los tipos de comunicacin definidos y los niveles de comunicacin
descritos lneas arriba, podemos establecer un modelo representativo de la
comunicacin entre procesos la cual se muestra en la figura siguiente:

Fig.46 Primitivas de funcin para comunicacin entre procesos

Se establece un orden de invocacin para la comunicacin entre procesos que seria
de la siguiente manera:
a) Conecta (): Iniciar conexin/aceptar conexin
b) Enva ()/recibe
c) Desconecta ()

Finalmente, un trmino utilizado dentro de la definicin de la comunicacin entre
procesos es la sincronizacin, la cual se define como esperar a que ciertos eventos
se produzcan para continuar con la ejecucin de una operacin. En la ejecucin de
la sincronizacin pueden ocurrir las siguientes acciones:
a) Una operacin de espera podra conducir a un bloqueo de una operacin
b) otro caso puede ser que la espera sea de tipo activa lo que conducira a un bucle
infinito.
c) en el caso de una espera inactiva la gestin de esta se realiza desde el Sistema
Operativo.

4.5.4 Localizacin y nomenclatura de los procesos

Establecido ya el mecanismo de comunicacin entre procesos el paso siguiente
seria definir de manera clara la ubicacin del proceso al quien se le va a enviar el
mensaje y para el caso de proceso receptor la ubicacin del proceso cliente que
solicita la respuesta al mensaje inicial, para ello se utilizan dos cdigos que
permiten determinar la ubicacin exacta de los procesos participantes en el
intercambio de mensajes y estos son la direccin IP y el puerto.

a) Direccin IP: Las direcciones IP son una serie de cuatro cifras 0..255 (4 bytes,
32 bits) separadas por puntos. Existe una direccin IP especial: 127.0.0.1 que
referencia siempre nuestra mquina local. Por ello, tiene asociado el nombre
"localhost". Segn[Schneider,2008] la finalidad de la direccin IP es identificar a
cada uno de los equipos de computo que pertenecen a la red por lo que dicha
direccin tiene que ser obligatoriamente nica de lo contrario se generara una
situacin que se conoce con el nombre de conflicto de direcciones IP cuya nica
solucin posible es que a una de las maquinas se le asigne una direccin IP nueva y
que no sea utilizada por ninguna de las otras mquinas.
b) Puerto: Si bien es cierto la direccin IP permite localizar la mquina en donde se
encuentra el proceso tanto emisor como receptor dicha ubicacin es parcial ya que
un equipo de computo posee mltiples procesos que se estn ejecutando en ese
momento y no sera posible determinar cul es el proceso que contiene el servicio
solicitado por lo que se utiliza un cdigo nico para identificar a cada proceso
existente en el computador. Este cdigo de identificacin se conoce con el nombre
de puerto y generalmente est asignado de antemano por el fabricante de la
aplicacin que genera el proceso. Dado que el concepto de puerto es muy

importante mostramos a continuacin algunos puertos conocidos de algunas
aplicaciones comunes del mundo informtico.

FTP (21) WWW(80) IMAP(143) POP3(110)
SMTP(25) SSH(22) TeInet(23) MysqI(3306)

Observacin: Los puertos del 1 al 1024 estn reservados para el Sistema
Operativo, por lo que los dems se pueden usar para cualquier aplicacin.

4.5.5 Modelo TCP/IP

Desde el advenimiento de las primeras redes WAN homogneas por parte de IBM,
UNISYS y otros se ha intentado siempre desarrollar un modelo de construccin de
aplicaciones para trabajar en WAN. Todo esto trajo como consecuencia la
implantacin de un modelo de referencia para comunicaciones en entorno WAN y
uso de tecnologa heterognea a este modelo de referencia se le llamo OSI y estaba
conformado por 7 capas que son: fsico, enlace, red, transporte, sesin,
presentacin, aplicacin. Una de las implementaciones prcticas del modelo OSI
fue la aparicin del sistema operativo UNIX que fue considerado el primer sistema
operativo de red para plataformas heterogneas y que fue un impulso decisivo para
la implementacin de lo que ms adelante seria la Internet.

Con la llegada de la web y su rpida adopcin como el MIDDLEWARE ms utilizado
para soluciones de tipo distribuidas, una de las consecuencias fue la utilizacin de
un modelo de referencia simplificado del modelo OSI original que manteniendo los
niveles de seguridad que OSI implanto no tena la complejidad de las mltiples
capas que este modelo exiga. El nuevo modelo de referencia se llamara TCP/IP
que solo posee 4 capas que son acceso al medio, Internet, transporte y aplicacin.
Una diferencia saltante fue la obligatoriedad en el uso del protocolo IP en la capa de
Internet (la anterior capa de red en OSI) y la adopcin del protocolo TCP y UDP
como los nicos protocolos de la capa de transporte.

El modelo TCP/IP mantendra la utilizacin de las cabeceras (headers) como forma
de comunicar a la capa anloga en el servidor de las operaciones protocolos que la
misma capa en el emisor est utilizando. En la figura siguiente se muestra la
estructura del modelo TCP/IP.

Fig. 47 Modelo TCP/IP

En la siguiente figura se muestra la forma como el mensaje es enviado del emisor
al receptor mediante las capas del modelo TCP/IP obsrvese la presencia de las
cabeceras durante la generacin del mensaje a transmitir.


Fig. 48 Envo de mensajes usando TCP/IP

En el siguiente grfico se muestra el modelo TCP/IP y la forma como este se
relaciona tanto con el Sistema Operativo como con los programas que el usuario
utiliza para generar sus mensajes o solicitud de servicio.

Fig. 49 Estructura interna y protocolos del modelo TCP/IP

4.5.6 Algoritmos para el paso de mensajes

Los modelos de comunicacin basados en cliente/servidor con paso de mensajes
pueden ser representados mediante algoritmos que describen el comportamiento
tanto del proceso cliente como del proceso servidor, para explicar el funcionamiento
debemos tomar en cuenta la presencia de los siguientes componentes como son:
los procesos cliente y servidor, el mensaje enviado (msg) y las primitivas de
funcin send y receive. El siguiente grfico representa el modelo sealado.


Fig.50 Algoritmos de envo y recepcin para comunicacin de procesos

Los algoritmos mostrados en el grfico anterior funcionan de la siguiente manera:

1) Servidor inicia sus operaciones creando el repositorio de entrada op y el
repositorio de salida ack.
2) Servidor activa la funcin receive en la que recibir las peticiones atraves del
repositorio op, por lo tanto, pasara a estado bloqueado.
3) Cliente crea su repositorio de salida msg y su repositorio de entrada reply.
4) Mediante alguna operacin interna se genera el dato a transmitir el cual ser
cargado en el repositorio msg.
5) Cliente activa la funcin send enviando el mensaje almacenado en el
repositorio msg con destino a servidor.
6) Cliente activa la funcin receive esperando la respuesta que ser recibida
atraves del repositorio reply, por lo que cliente entra en estado bloqueado.
7) Debido a que el repositorio op ya no esta vacio, debido al envo de mensaje
del cliente, servidor sale del estado bloqueado.
8) Servidor realiza operacin de validacin del dato recibido en op, si dicho
dato es vlido, se ejecuta el servicio solicitado y la respuesta generada se
carga en el repositorio ack; si no es vlido se genera un mensaje error
informando el hecho, el cual ser cargado en el repositorio ack.
9) Servidor activa la funcin send enviando mensaje de respuesta atraves del
repositorio ack, posteriormente regresa a estado inicial para atender a otros
clientes.
10) Debido a que el repositorio reply ya no est vaco debido a la llegada del
mensaje enviado por servidor, cliente sale del estado bloqueado.
11) Se revisa el mensaje recibido en el repositorio reply, si es vlido se extrae el
dato y se incorpora en el proceso cliente; si el mensaje no es vlido se
activaran las operacin de correccin y posiblemente de retransmisin y tal
vez se empiece nuevamente el proceso de comunicacin.

4.6 Capa de transporte

Como se indic durante el desarrollo de esta segunda unidad uno de los cambios
ms importantes que se han dado, sobre todo a la aparicin del Middleware web ha
sido el paso del modelo de referencia OSI de 7 capas al modelo de referencia
TCP/IP de 4 capas. Sin embargo, independientemente de cualquiera de los dos

modelos la capa de transporte ha permanecido inalterable en cuanto a su propsito
y operaciones.

La capa de transporte tiene la misin de establecer la forma de enviar el mensaje
producido en la capa de aplicacin, para ello establece las siguientes operaciones:

i. la divisin del mensaje a enviar en unidades ms pequeas denominadas
paquetes.
ii. En el proceso emisor estos paquetes sern enviados mediante un criterio de
transmisin determinado con destino al proceso receptor. En el proceso
receptor la operacin consiste en recuperar los paquetes recibidos y mediante
un algoritmo de reconstruccin regenerar el mensaje original.

Dentro de esta lgica de funcionamiento es indispensable la conversin del mensaje
en paquetes porque de esta forma se garantiza que en caso de una falla de envo o
recepcin de un paquete determinado pueda haber la posibilidad de retransmitir
dicho paquete y no el mensaje completo.

De acuerdo a las caractersticas de funcionamiento existen dos formas de uso de los
servicios de la capa de transporte que son: los servicios orientados a conexin y los
servicios orientados a no conexin.

4.6.1 Servicios orientados a conexin

En esta modalidad de servicio el cliente establece una operacin previa de conexin
con el servidor en la que se definen y sincronizan parmetros como la ruta que se
va a seguir desde cliente a servidor y los nodos intermedios por los que va a pasar
el mensaje, la direccin IP y el puerto que tiene cada uno de los procesos y la
solicitud para poder enviar mensajes. A esta operacin se le denomina sincronismo
y tiene por objeto configurar de manera adecuada tanto al cliente como al servidor
mediante un camino construido (stream) por el que se enviar tanto la solicitud de
servicio como la respuesta del mismo. A continuacin se enva el mensaje por
parte del cliente el cual ser enviado de manera secuencial, es decir, paquete por
paquete y de manera ordenada, el que ser recibido por el servidor teniendo este la
capacidad de retransmitir cualquier paquete que considere no vlido. Al enviar el
bit de stop el cliente est informando que ya termin de transmitir el mensaje,
teniendo el servidor la caracterstica de procesar el mensaje y generar la salida, el
cual ser enviado al cliente por el mismo procedimiento de transmisin indicados
anteriormente.

Podemos indicar las principales caractersticas de los servicios orientados a
conexin como las siguientes:

a) envo de paquetes en forma secuencial
b) camino o ruta de envo predefinida entre cliente/servidor (stream)
c) capacidad de retransmisin
d) es confiable y es poco probable la perdida de paquetes
e) el algoritmo de recuperacin del mensaje recibido es sencillo

El protocolo utilizado en los servicios orientados a conexin es TCP, cuyos
diagramas de tiempo mostramos a continuacin:


Fig.51 Protocolo TCP

4.6.2 Servicios orientados a no conexin

A diferencia del modo anterior en este tipo de servicio el cliente no realiza ningn
tipo de sincronismo previo con el servidor, debido a ello el servidor no conoce la
existencia de un proceso cliente que podra enviarle mensajes o de lo contrario
establecer un mecanismo de espera con tiempo indeterminado (generalmente un
bucle infinito) en la probabilidad de un futuro pedido de servicios.

Por otro lado, el proceso cliente enva todos los paquetes pertenecientes al mensaje
en forma simultnea con direccin al servidor, lo que provocar que cada paquete
tenga, por su cuenta que seguir una ruta dentro de la red para llegar a su destino.
Esto implica de que no necesariamente todos los paquetes enviados por el cliente
llegarn al servidor, adems no llegaran en un orden establecido sino de acuerdo a
ciertos criterios como el nmero de nodos de la red empleados para llegar, la
calidad del medio de comunicacin utilizado, el nivel de ruido dentro de dicho medio
de comunicacin y otros, por lo que es ms dificultoso recomponer el mensaje
original por parte del receptor.

Las caractersticas ms importantes de los servicios orientados a no conexin son:
a) No hay camino predeterminado entre cliente y servidor
b) La transmisin de los mensajes es de tipo paralela o simultnea
c) Cada paquete toma su propio camino para llegar a su destino
d) Es poco confiable
e) El algoritmo de recuperacin del mensajes es ms complejo utilizando para
ello un algoritmo de ordenamiento

El protocolo que se utiliza en los servicios orientados a no conexin se denomina
UDP, el cual tiene un diagrama de tiempo que se muestra a continuacin:


Fig.52 Protocolo UDP

4.6.3 Datagrama

Una de las principales caractersticas del protocolo UDP es como ya se indico
anteriormente de que cada paquete del mensaje original sigue un camino a travs
de la red para llegar al proceso receptor, algunos lograran llegar otros no, debido a
ello si con los paquetes que se han recibido el receptor logra reconstruir el mensaje
original se considera de que todas estas rutas seguidas por los paquetes pueden ser
representados por una ruta equivalente de tipo virtual que los represente, ruta que
unira al proceso emisor con el proceso receptor a este camino virtual se le conoce
con el nombre de datagrama y es de gran importancia en telecomunicaciones para
medir la eficacia de los servicios orientados a no conexin.

4.6.4 TCP Transaccional

Si bien es cierto, que el protocolo TCP tiene mejores caractersticas en lo que a
confiabilidad, capacidad de retransmisin y recuperacin de informacin posee
frente al protocolo UDP, este ltimo lo supera largamente al TCP en trminos de
performance ya que es mucho ms rpido y es el favorito en lo que es bsqueda de
informacin a travs de la web, como ejemplo tenemos su presencia en Yahoo,
Google y otros de las mismas caractersticas.

En un intento de compatibilizar las mejores caractersticas de ambos protocolos en
1992, se publican las especificaciones del protocolo TCP para transacciones
(T/TCP), [Stacey,2000] el cual manteniendo los criterios de sincronismo planteados
por TCP reduce en forma notable el tiempo de transmisin y recepcin de mensajes
de una forma cercana al utilizado por el protocolo UDP. Esto lo logra
empaquetando toda la sealizacin que hay entre cliente y servidor en tres
mensajes definidos a diferencia de los nueve del anterior TCP. En el siguiente
grfico se muestra el diagrama de tiempos del protocolo indicado:


Fig.53 Protocolo T/TCP



Leccin 5

Sockets

Definida las caractersticas de la comunicacin entre procesos y establecido el rol
que juega la capa de transporte para establecer la forma de envo de los mensaje
sea usando TCP o UDP, debe definirse el punto de entrada mediante el cual el
proceso receptor recibe los mensajes o el punto de salida mediante el cual el
proceso emisor enva sus llamadas de servicio. Este punto se denomina socket y
est ligado a un punto de acceso a comunicaciones. Errneamente se piensa en el
socket como un conector fsico que permite el acceso de un perifrico al
computador, sin embargo, el socket se debe ver ms como un cdigo que se
encuentra ligado al valor de dos recursos fundamentales para la comunicacin, por
un lado la direccin IP que identifica la mquina donde se encuentra el proceso a
comunicar, y por otro lado el puerto que identifica al proceso que se encuentra
dentro de la mquina previamente identificada.

Estrictamente hablando un socket se considera como un extremo de una conexin
de comunicacin entre dos computadoras. Por otro lado, si lo vemos del punto de
vista de la programacin un socket representa el mecanismo para transferir datos
de una computadora a otra.

Fig.54 Puertos y sockets

En el presente grfico se muestra la forma como el socket participa como elemento
fundamental dentro de la comunicacin de procesos, debido a que es el medio a
travs del cual el proceso cliente enviar su mensaje que ser recibido por un
punto de entrada del servidor.

Los sockets pueden ser construidos utilizando diferentes lenguajes de
programacin, sin embargo, los ms conocidos para su implementacin son el C y
el Java. Una particularidad sobre este tema la brinda el sistema operativo UNIX
que considera al socket como un descriptor de archivo el cual se representa como
un nmero entero asociado a un archivo abierto. Ejemplos de este uso los tenemos
en los archivos de impresin, utileras de red tales como rlogin o ftp.

Dentro del modelo de referencia OSI el socket se muestra por encima de la capa de
transporte y debajo de la capa de aplicacin, como se muestra en la figura
siguiente:


Fig.55 Ubicacin del socket dentro del modelo TCP/IP

Un socket se caracteriza por tres atributos especificos dominio, tipo y protocolo,
segn [Baena,2001]:

a) Dominio: Especifica el medio de comunicacin de la red que el socket va a
utilizar. De acuerdo a ello los dominios pueden ser:
AF/UNIX, utilizados para el manejo de archivos para el sistema operativo
UNIX
AF/INET, utilizados como sockets de red para acceso a Internet en el
sistema operativo UNIX
AF/ISO, utilizado como protocolo estndar en el modelo de referencia
OSI
AF/NS, utilizado en las redes de tipo XEROX

b) Tipo: Define las caracteristicas de la comunicacin entre procesos en la que
es usado un socket, es decir el tipo de comunicacin que se realizara entre
cliente y servidor. Estas caracteristicas pueden ser:
Fiabilidad de la transmisin
Definicin de la forma como los datos seran enviados
Verificacin de no duplicacin de datos
Establecimiento del modo conectado en la comunicacin, es decir la
capacidad de informar que ya se establecio la comunicacin
Capacidad de enviar mensajes especiales como sincronismo,
confirmacin de envo o recepcin, o envo de mensajes urgentes.
De acuerdo a lo indicado los sockets tienen los siguientes tipos disponibles:
Tipo SOCK/DGRAM, sockets que envian mensajes de tipo datagrama de
tamao limitado
Tipo SOCK/STREAM, para comunicaciones fiables y que utilizan la
caracteristica de modo conectado usando dos vias (envio-respuesta) y
con tamao variable en el mensaje
SOCK/RAW, permite la comunicacin de procesos utilizando para ello
protocolos de mas bajo nivel, por ejemplo la capa de red, en este caso el
protocolo IP.
SOCK/SEQPACKET, este socket tiene caracteristicas muy parecidas al
SOCK/STREAM la diferencia radica en que este socket solo maneja
mensajes de tamao fijo.

c) Protocolo: La capa de transporte proporciona el protocolo necesario para el
uso del socket. Dicho protocolo en el modelo TCP/IP sera UDP o TCP, los
cuales son estudiados en cursos de telecomunicaciones o telemtica. En el
caso de UNIX y en sistemas basados en el modelo OSI se utilizar el
protocolo definido por defecto.



5.1 Socket tipo Datagrama

El socket de tipo Datagrama (SOCK/DGRAM), es el socket utilizado por los servicios
orientados a no conexin reseados lineas arriba, utilizan como protocolo de
transporte a UDP (User Datagram Protocol) el cual tiene un funcionamiento que
describiremos a continuacion:

Cada vez que se envia un datagrama se debe enviar la localizacion del
socket emisor (direccion IP y Puerto) y ademas la localizacion del socket
receptor, por lo que el mensaje transmitido tendra un tamao mayor que el
enviado por el protocolo TCP.
Al no haber establecimiento de conexin previo entre emisor y receptor UDP
toma menos tiempo para enviar el mensaje.
Hay un limite de tamao en los datagramas el cual es de 64KB para enviar a
una localizacion determinada.
UDP es un protocolo que envia los paquetes de manera simultanea por lo
que no se garantiza que lleguen en el mismo orden que fueron enviados.
Los datagramas son paquetes de informacion del tipo enviar y olvidar, es
decir despues de enviar la informacion no hay manera de saber si dicha
informacion llego correctamente.
UDP es un protocolo bastante sencillo de utilizar y que tiene una menor
sobrecarga sobre la conexin lo cual lo hace ideal tanto para comunicacin
entre procesos cliente/servidor sobre una red LAN como para la
implementacion de busquedas de gran volumen como los usados en google,
yahoo y otros.

5.1.1 Implementacion de Sockets UDP en Java

El lenguaje Java provee de la librera java.net para la implementacin de sockets
tanto para el protocolo TCP o UDP.

Fig.56 La librera java.net

Tanto para los sockets TCP como UDP es importante de la utilizacin de la clase
InetAddress la cual es utilizada para obtener la direccion IP de la mquina a la que
se desea accesar. Esta clase tiene dos metodos importantes:

static InetAddress getByName(String host) Obtiene una direccin IP en
base al nombre (dominios o nmeros).
static InetAddress getLocalHost() Obtiene la direccin IP local.

Para el caso de protocolo UDP se utilizan dos clases:

DatagramSocket: Genera el socket del emisor y del receptor
DatagramPacket: Contiene el mensaje a ser enviado o a ser recibido

La relacin entre estas clases se muestra en el grfico siguiente:

Fig.57 Uso de datagramas

A continuacin se muestra un flujograma que explica la creacin y funcionamiento
de los sockets utilizando las dos clases anteriormente mencionadas:

Fig.58 secuencia de operaciones socket UDP

Del presente grfico se describe el funcionamiento de los sockets:

Se crea el socket UDP de servidor asignndosele a este un puerto disponible
de uso
A continuacin el servidor crea el datagram de recepcin de mensajes, el
cual sera el medio por el que se recibir los datos del emisor
El servidor ejecuta el metodo receive() ponindose en estado bloqueado

El Cliente genera su socket UDP para envio de datos, en este caso el sistema
operativo de cliente asigna automticamente el puerto de salida de dicho
socket
El cliente genera el datagrama de salida destinado al envio del mensaje
El cliente carga el mensaje en el datagrama y a continuacin ejecuta el
mtodo send() con el que se transmite el mensaje al servidor
El cliente crea el datagrama de recepcin por el que va a recuperar la
respuesta enviada del servidor y ejecuta el mtodo receive() quedando por
lo tanto en estado bloqueado
El servidor al recibir el mensaje enviado por el cliente sale del estado
bloqueado recupera el mensaje procesa y genera la respuesta solicitada
El servidor crea el datagrama de salida en el cual cargar la respuesta
generada y posteriormente ejecuta el mtodo send() transmitiendo el
mensaje solicitado y terminando su operacin
El cliente al recibir la respuesta enviada por el servidor sale del estado
bloqueado recupera la respuesta y prosigue sus operaciones normales,
culminando la comunicacin

Como se observa en el diagrama presentado la informacion a transmitir se asocia a
un objeto de la clase DatagramPacket la particularidad radica en el que el mensaje
tiene que ser convertido obligatoriamente en array de bytes por ello la
implementacin de la clase DatagramPacket depender de la direccin de la
transmisin de mensajes, de acuerdo a esto:
a) si se va a recibir datos el metodo a usar es:
DatagramPacket (bytes[] mensaje, int n)
b) si se va a transmitir datos el mtodo es:
DatagramPacket (bytes[] mensaje, int n, InetAddress destino, int
puerto)

Donde:

mensaje array que contiene el mensaje a transmitir o recibir
n tamao maximo del datagrama que va a enviar o recibir el mensaje
destino la direccion IP de la maquina receptora del mensaje
puerto habilitado por el receptor y que permite accesar al servicio

Otros mtodos utilizados para la comunicacin via UDP son los siguientes:
DatagramSocket(int puerto,InetAddress dir): Crea un socket UDP con un
enlace a la direccin y puerto indicados. La direccin y puerto son opcionales en el
caso del socket cliente (se elige uno libre).
void send(DatagramPacket paquete): Enva el datagrama a la direccin del
paquete.
void receive(DatagramPacket paquete): Se bloquea hasta la recepcin del
datagrama.
void setSo Time Out (int timeout): Permite establecer el tiempo de espera
(delay en milisegundos) para recibir una respuesta valida, pasado ese tiempo se
activara una excepcin. Si su valor es cero se considera infinito.
5.1.2 Cdigo de ejemplo de socket UDP
A continuacion se muestra un ejemplo en Java de implementacion de una
comunicacin entre procesos usando sockets UDP.

Inicialmente mostramos el cliente UDP el cual tendra como funcin enviar un
mensaje atraves de una interface grfica que debera llegar a un servidor receptor.
// Java core packages
package lab2;
import java.io.*;
import java.net.*;
import java.awt.*;
import java.awt.event.*;

// Java extension packages
import javax.swing.*;

public class ClienUDP extends JFrame {
private JTextField enterField;
private JTextArea displayArea;
private DatagramPacket sendPacket, receivePacket;
private DatagramSocket socket;

// set up GUI and DatagramSocket
public ClienUDP()
{
super( "Cliente UDP" );

Container container = getContentPane();

enterField = new JTextField( "Ingrese su mensaje aqui:" );

enterField.addActionListener(

new ActionListener() {

// create and send a packet
public void actionPerformed( ActionEvent event )
{
// create and send packet
try {
displayArea.append(
"\nEnviando paquete conteniendo: " +
event.getActionCommand() + "\n" );

// get message from textfield and convert to
// array of bytes
String message = event.getActionCommand();
byte data[] = message.getBytes();

// create sendPacket
sendPacket = new DatagramPacket(
data, data.length,
InetAddress.getLocalHost(), 5200 );

// send packet
socket.send( sendPacket );

displayArea.append( "Paquete enviado\n" );

displayArea.setCaretPosition(
displayArea.getText().length() );
}

// process problems creating or sending packet
catch ( IOException ioException ) {
displayArea.append(
ioException.toString() + "\n" );
ioException.printStackTrace();
}

} // end actionPerformed

} // end anonymous inner class

); // end call to addActionListener

container.add( enterField, BorderLayout.NORTH );

displayArea = new JTextArea();
container.add( new JScrollPane( displayArea ),
BorderLayout.CENTER );

setSize( 400, 300 );
setVisible( true );

// create DatagramSocket for sending and receiving packets
try {
socket = new DatagramSocket();
}

// catch problems creating DatagramSocket
catch( SocketException socketException ) {
socketException.printStackTrace();
System.exit( 1 );
}

} // end Client constructor

// wait for packets to arrive from Server,
// then display packet contents
public void waitForPackets()
{
// loop forever
while ( true ) {

// receive packet and display contents
try {

// set up packet
byte data[] = new byte[ 100 ];
receivePacket =
new DatagramPacket( data, data.length );

// wait for packet

socket.receive( receivePacket );

// display packet contents
displayPacket();
}

// process problems receiving or displaying packet
catch( IOException exception ) {
displayArea.append( exception.toString() + "\n" );
exception.printStackTrace();
}

} // end while

} // end method waitForPackets

// display contents of receivePacket
private void displayPacket()
{
displayArea.append( "\nPaquete recibido:" +
"\nDesde el servidor: " + receivePacket.getAddress() +
"\nPuerto del Host : " + receivePacket.getPort() +
"\nLongitud: " + receivePacket.getLength() +
"\nConteniendo:\n\t" +
new String( receivePacket.getData(), 0,
receivePacket.getLength() ) );

}

// execute application
public static void main( String args[] )
{
ClienUDP application = new ClienUDP();

application.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE );

application.waitForPackets();
}

} // end class Client
A continuacion mostraremos el codigo del servidor UDP correspondiente a la
operacin que se esta realizando:
package lab2;
// Java core packages
import java.io.*;
import java.net.*;
import java.awt.*;

// Java extension packages

public class ServUDP extends JFrame {

private JTextArea displayArea;
private DatagramPacket sendPacket, receivePacket;
private DatagramSocket socket;

// set up GUI and DatagramSocket
public ServUDP()
{
super( "Servidor UDP" );

displayArea = new JTextArea();
getContentPane().add( new JScrollPane( displayArea ),
BorderLayout.CENTER );
setSize( 400, 300 );
setVisible( true );

// create DatagramSocket for sending and receiving packets
try {
socket = new DatagramSocket( 5200 );
}

// process problems creating DatagramSocket
catch( SocketException socketException ) {
socketException.printStackTrace();
System.exit( 1 );
}

} // end Server constructor

// wait for packets to arrive, then display data and echo
// packet to client
public void waitForPackets()
{
// loop forever
while ( true ) {

// receive packet, display contents, echo to client
try {

// set up packet
byte data[] = new byte[ 100 ];
receivePacket =
new DatagramPacket( data, data.length );

// wait for packet
socket.receive( receivePacket );

// process packet
displayPacket();

// echo information from packet back to client
sendPacketToClient();
}

// process problems manipulating packet
catch( IOException ioException ) {

displayArea.append( ioException.toString() + "\n" );
ioException.printStackTrace();
}

} // end while

} // end method waitForPackets

// display packet contents
private void displayPacket()
{
displayArea.append( "\nPaquete recibido:" +
"\nDel cliente: " + receivePacket.getAddress() +
"\nPuerto del cliente: " + receivePacket.getPort() +
"\nLongitud: " + receivePacket.getLength() +
"\nConteniendo:\n\t" +
new String( receivePacket.getData(), 0,
receivePacket.getLength() ) );
}

// echo packet to client
private void sendPacketToClient() throws IOException
{
displayArea.append( "\n\nEnvio de confirmacion al cliente..." );

// create packet to send
sendPacket = new DatagramPacket( receivePacket.getData(),
receivePacket.getLength(), receivePacket.getAddress(),
receivePacket.getPort() );

// send packet
socket.send( sendPacket );

displayArea.append( "Paquete enviado\n" );
}

// execute application
public static void main( String args[] )
{
ServUDP application = new ServUDP();

application.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE );

application.waitForPackets();
}

} // end class Server

5.2 Socket Stream

El socket Stream es el socket utilizado por los servicios orientados a conexin y
cuya principal caracterstica es el mtodo de establecimiento de conexin conocido

con el nombre de sincronismo. En el proceso de sincronismo el emisor como el
receptor solicitan conexin entre ellos envindose parmetros con los cuales ambos
se identifican de prosperar este proceso se crea un camino a travs de la red que
permitir el envo y recepcin de mensajes. Este camino se le conoce con el
nombre de Stream. En el siguiente grafico se muestra el conjunto de operaciones
para la comunicacin entre procesos usando sockets TCP.

Fig.59 Secuencia de operaciones socket TCP

Utilizando el presente grfico, la secuencia de operaciones del socket TCP ser de la
siguiente manera:
El servidor comienza el proceso creando un socket al que posteriormente
debera conectarse el cliente, este socket tendra un puerto definido para el
servicio al que se desea accesar.
A continuacin se ejecuta el metodo accept() con el cual el socket del
servidor estara en posicion de recepcion quedando por lo tanto en estado
bloqueado.
El cliente crea su socket TCP especificando direccion IP y nmero de puerto
del proceso servidor al que desea accesar. Esto provocar que el cliente
TCP establezca conexin con el servidor.
Cuando es contactado por el cliente el servidor crea un nuevo socket para
que este proceso pueda comunicarse con el cliente, el cual sera instanciado
por el emisor para poder comenzar el envio del mensaje.
El cliente carga en el Stream el mensaje a ser transferido, para ello en el
paquete utilizara los metodos writeXXX.
A continuacin el cliente cierra el paquete conteniendo el mensaje usando el
mtodo flush() con lo cual se enva el paquete con destino al servidor.
El servidor recibe el mensaje enviado desde el stream, extrae el mensaje
utilizando los metodos readXXX, procediendo por lo tanto a generar la
respuesta del mismo.
El mensaje de respuesta es cargado en el stream para ser enviado con
destino al cliente completando su operacin.
El cliente que estaba en el estado de recepcion recibe la respuesta enviada
atraves del stream y la recupera terminando el proceso.

5.2.1 Implementacion de socket TCP usando Java

Para la creacin de los sockets TCP en Java se van a utilizar dos clases de sockets,
una para el cliente y otra para el servidor.


Para el cliente:
Socket(InetAddress dir, int puerto)
Crea un socket stream para el cliente conectado con la direccin y puerto
indicados. Existen otros constructores con diferentes argumentos.

Para el servidor:
ServerSocket(int puerto)
Crea un socket stream para el servidor. Existen otros constructores con
diferentes argumentos.
Socket accept()
Prepara la conexin y se bloquea a espera de conexiones. Equivale a listen
y accept de BSD Sockets. Devuelve un Socket.

La diferencia fundamental que existe entre los sockets TCP y UDP radica en el
medio donde se envia los mensajes. En UDP son los datagramas mientras que en
TCP el medio es el stream, el cual posee dos vias de comunicacin una para
transmisin y otra para recepcin, como se muestra en el siguiente grfico:

Fig.60 Uso de stream en comunicaciones TCP

En cada extremo del stream se va a considerar un punto de acceso sea para
ingreso de datos o sea para envio de datos; las caractersticas son:

El punto de ingreso de datos se denomina InputStream
El punto de envio de datos se denomina OutputStream
Si el mensaje recibido contiene datos de tipo simple el paquete sera del tipo
DataInputStream
Si el mensaje recibido contiene datos de tipo objeto el paquete sera del tipo
ObjectInputStream
Si el mensaje a transmitir contiene datos de tipo simple el paquete que los
contiene sera del tipo DataOutputStream
Si el mensaje a transmitir contiene datos de tipo objeto el paquete que los
contiene sera del tipo ObjectOutputStream.

Adems de ello, se utiliza para la implementacin de la comunicacin via streams
los siguientes mtodos:

Accept() activa el socket del servidor y lo asocia a un objeto de la clase
Socket la cual se conectara cuando establezca comunicacin con el socket
del cliente durante la operacin de sincronismo, mientras tanto el proceso
servidor queda bloqueado

ReadXXX() operacin que permite leer el contenido de un InputStream cuyo
dato de entrada puede ser de tipo object o tipo data. En caso que no hayan
datos mantiene el bloqueo del socket
WriteXXX() copia los datos a enviar al paquete de transmision de acuerdo al
tipo de dato, ya sea object o data. Si el paquete ya esta lleno se bloquea
Flush() cierra el OutputStream conteniendo el paquete a enviar y ejecuta el
proceso de transmision con destino al socket del receptor.

A continuacin se muestra un ejemplo de implementacin para una comunicacin
utilizando socket de tipo stream.

Aqu el cdigo del cliente TCP

/*
* ClienteTCP.java
*
* Created on 01 de julio del 2010, 10:59
*/
package lab2;
import java.io.*;
import java.net.*;
/**
*
* @author Jorge Guerra
*/
public class ClienteTCP extends javax.swing.JDialog {
String respuesta;
/** Creates new form ClienteTCP */
public ClienteTCP(java.awt.Frame parent, 81ransmi modal) {
super(parent, modal);
initComponents();
}

/** This method is called from within the constructor to
* initialize the form.
* WARNING: Do NOT modify this code. The content of this method is
* always regenerated by the Form Editor.
*/
private void initComponents() {//GEN-BEGIN:initComponents
jScrollPane1 = new javax.swing.JscrollPane();
texto = new javax.swing.JtextArea();
jLabel1 = new javax.swing.Jlabel();
mensaje = new javax.swing.JtextField();
direccion = new javax.swing.JtextField();
81ransm = new javax.swing.JtextField();
enviar = new javax.swing.Jbutton();

getContentPane().setLayout(new java.awt.FlowLayout(java.awt.FlowLayout.CENTER, 3,
15));

setDefaultCloseOperation(javax.swing.WindowConstants.DISPOSE_ON_CLOSE);
setTitle(Cliente TCP Sistemas Distribuidos);


jScrollPane1.setHorizontalScrollBarPolicy(javax.swing.JscrollPane.HORIZONTAL_SCROLL
BAR_ALWAYS);

jScrollPane1.setVerticalScrollBarPolicy(javax.swing.JscrollPane.VERTICAL_SCROLLBAR_
ALWAYS);
jScrollPane1.setMinimumSize(new java.awt.Dimension(200, 200));
jScrollPane1.setPreferredSize(new java.awt.Dimension(400, 200));
jScrollPane1.setViewportView(texto);

getContentPane().add(jScrollPane1);

jLabel1.setFont(new java.awt.Font(Verdana, 1, 12));
jLabel1.setText(Mensaje a enviar:);
getContentPane().add(jLabel1);

mensaje.setPreferredSize(new java.awt.Dimension(270, 21));
getContentPane().add(mensaje);

jLabel2.setText(Direccion:);

direccion.setPreferredSize(new java.awt.Dimension(150, 21));
getContentPane().add(direccion);

jLabel3.setText( Puerto:);

82ransm.setPreferredSize(new java.awt.Dimension(100, 21));
getContentPane().add(82ransm);

enviar.setFont(new java.awt.Font(Verdana, 1, 12));
enviar.setText( enviar );
enviar.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
enviarActionPerformed(evt);
}
});

getContentPane().add(enviar);

java.awt.Dimension screenSize = java.awt.Toolkit.getDefaultToolkit().getScreenSize();
setBounds((screenSize.width-471)/2, (screenSize.height-418)/2, 471, 418);
}//GEN-END:initComponents

private void enviarActionPerformed(java.awt.event.ActionEvent evt) {//GEN-
FIRST:event_enviarActionPerformed
enviamos();
}//GEN-LAST:event_enviarActionPerformed

/**
* @param args the command line arguments
*/

public static void main(String args[]) {
new ClienteTCP(new javax.swing.Jframe(), true).show();
}

public void enviamos() {
String dir =direccion.getText();
int p=Integer.parseInt(83ransm.getText());
String men=mensaje.getText();
transmitimos(dir,p,men);
mensaje.setText();
}

public void transmitimos(java.lang.String direc, int pto, java.lang.String chamullo) {
try{
Socket soc=new Socket(InetAddress.getByName(direc),pto);
OutputStream salida=soc.getOutputStream();
ObjectOutputStream 83rans= new ObjectOutputStream(salida);
DataInputStream recoger=new DataInputStream(soc.getInputStream());
envio.writeObject(chamullo);
envio.flush();
respuesta = El numero devuelto por el servidor es : +recoger.readInt();
System.out.println(respuesta);
soc.close();
mostrando(respuesta);
}catch(Exception e){
e.printStackTrace();
}
}
public void mostrando(String m) {
// Despliega un mensaje en el rea de texto
texto.append(m+\n);
}

// Variables declaration do not modify//GEN-BEGIN:variables
private javax.swing.JtextField direccion;
private javax.swing.Jbutton enviar;
private javax.swing.Jlabel jLabel1;
private javax.swing.JscrollPane jScrollPane1;
private javax.swing.JtextField mensaje;
private javax.swing.JtextField 83ransm;
private javax.swing.JtextArea texto;
// End of variables declaration//GEN-END:variables

}

A continuacin el cdigo del servidor TCP

/*
* ServidorTCP.java
*
* Created on 01 de julio del 2010, 11:49
*/

package lab2;
import java.io.*;
import java.net.*;
/**
*
* @author Jorge Guerra
*/
public class ServidorTCP extends javax.swing.Jdialog implements Runnable{
private Thread hilo;
private ServerSocket servidor= null;
private Socket pedido = null;
private ObjectInputStream entra=null;
private DataOutputStream sale=null;
int numero=0;
/** Creates new form ServidorTCP */
public ServidorTCP(java.awt.Frame parent, 84ransmi modal) {
super(parent, modal);
initComponents();
}

/** This method is called from within the constructor to
* initialize the form.
* WARNING: Do NOT modify this code. The content of this method is
* always regenerated by the Form Editor.
*/
private void initComponents() {//GEN-BEGIN:initComponents
84ransm = new javax.swing.JtextField();
jScrollPane1 = new javax.swing.JscrollPane();
mensajes = new javax.swing.JtextArea();
conectar = new javax.swing.Jbutton();
desconectar = new javax.swing.Jbutton();

getContentPane().setLayout(null);

setDefaultCloseOperation(javax.swing.WindowConstants.DISPOSE_ON_CLOSE);
try{
setTitle(Servidor: +InetAddress.getLocalHost().getHostName());
}catch(Exception e){
}
jLabel1.setText(Puerto:);
jLabel1.setBounds(110, 30, 70, 16);

getContentPane().add(84ransm);
84ransm.setBounds(200, 30, 70, 21);

jLabel2.setText(Mensajes recibidos:);

jLabel2.setBounds(130, 90, 170, 16);

jScrollPane1.setViewportView(mensajes);

getContentPane().add(jScrollPane1);
jScrollPane1.setBounds(70, 110, 310, 50);

conectar.setFont(new java.awt.Font(Verdana, 1, 10));
conectar.setText(conectar);
conectar.addActionListener(new java.awt.event.ActionListener() {
conectarActionPerformed(evt);
}
});

getContentPane().add(conectar);
conectar.setBounds(90, 180, 90, 23);

desconectar.setFont(new java.awt.Font(Verdana, 1, 10));
desconectar.setText(desconectar);
desconectar.addActionListener(new java.awt.event.ActionListener() {
desconectarActionPerformed(evt);
}
});

getContentPane().add(desconectar);
desconectar.setBounds(270, 180, 110, 23);

java.awt.Dimension screenSize = java.awt.Toolkit.getDefaultToolkit().getScreenSize();
setBounds((screenSize.width-520)/2, (screenSize.height-304)/2, 520, 304);
}//GEN-END:initComponents

private void desconectarActionPerformed(java.awt.event.ActionEvent evt) {//GEN-
FIRST:event_desconectarActionPerformed
desconectamos();
}//GEN-LAST:event_desconectarActionPerformed

private void conectarActionPerformed(java.awt.event.ActionEvent evt) {//GEN-
FIRST:event_conectarActionPerformed
conectamos();
}//GEN-LAST:event_conectarActionPerformed

/**
* @param args the command line arguments
*/
public static void main(String args[]) {
new ServidorTCP(new javax.swing.Jframe(), true).show();
}

public void run() {
String recibido;
while (true) {
System.out.println(run);
String texto=;

if (servidor != null) {
try{
pedido=servidor.accept();
InputStream entrada=pedido.getInputStream();
entra =new ObjectInputStream(entrada);
recibido=(String)entra.readObject();
creaArchivo(recibido);
System.out.println(Esto se le envio al servidor para procesar: +recibido);
sale=new DataOutputStream(pedido.getOutputStream());
numero++;
sale.writeInt(numero);
sale.writeUTF(recibido);
mensajes.append(\nMensaje no. +numero+ de cliente +pedido);
mensajes.append(\nDice: +recibido);
sale.flush();
pedido.close();
} catch (Exception e) {System.out.println(error +e+\n);};
}

try {
hilo.sleep(100);
}catch (Exception e) {System.out.println(fin hilo);};
}
}

public void iniciar() {
//desconectar.setEnabled(false);
hilo=new Thread(this);
hilo.start();
}

public void conectamos() {
abrir();
int p=Integer.parseInt(puerto.getText());
try {
servidor=new ServerSocket(p);
//servidor.setSoTimeout(1000);
} catch (Exception e1) {};
iniciar();
}

public void desconectamos() {
try {
cerrar();
servidor.close();
servidor=null;
}catch (Exception e2) {};
}

public void abrir() {
conectar.setEnabled(false);
desconectar.setEnabled(true);
mensajes.append(Servidor conectado,esperando consultas);
}


public void cerrar() {
conectar.setEnabled(true);
desconectar.setEnabled(false);
mensajes.append(Servidor desconectado);
}
public void creaArchivo(String men) {
try{
FileWriter fw=new FileWriter(C:/mensaje.txt,true);
fw.write(men+\n);
fw.close();
}catch(Exception e){}
}
// Variables declaration do not modify//GEN-BEGIN:variables
private javax.swing.Jbutton conectar;
private javax.swing.Jbutton desconectar;
private javax.swing.JscrollPane jScrollPane1;
private javax.swing.JtextArea mensajes;
private javax.swing.JtextField 87ransm;
// End of variables declaration//GEN-END:variables

}

5.3 Sockets Raw

El modo Raw es bsicamente una forma de poder saltar algunas de las operaciones
que el computador utiliza en la comunicacin usando TCP/IP. En vez de pasar por
cada una de las capas de este modelo en las que al mensaje a enviar se le agrega
cabeceras que van a ser leidas por la capa analoga del lado receptor, en este caso
el paquete que representa el mensaje generado por el nivel aplicacin sera enviado
sin cabeceras, por lo que a este paquete se le denomina paquete Raw.

La aplicacin que utiliza este modo de uso de comunicacin es la unica responsable
de analizar el paquete y administrar los mensajes provenientes de las capas
anteriores de la pila TCP/IP que normalmente son generados. El socket Raw es el
socket que es utilizado por la aplicacin que trabaja en modo Raw. Para esto, se
requiere un conocimiento avanzado de la forma como el sistema operativo maneja
la comunicacin entre procesos, debido a que la aplicacin en modo Raw deber
acceder a rutinas de bajo nivel proporcionadas por dicho sistema operativo.

La mayora de programas de tipo cliente/servidor le permiten al kernel manejar las
comunicaciones entre procesos por ser sencilla su implementacin, pero los
programas que manejan niveles de seguridad pueden utilizar sockets raws para
escribir sus propios paquetes.

5.3.1 Caracterisiticas e implementacin de Sockets Raw

Cuando se utiliza la capa Ipv4, esta genera una cabecera IP cuando se envia un
paquete de manera obligatoria, sin embargo, cuando el identificador de usuario es
de tipo Root o la propiedad CAP_NET_RAW esta activada, es posible abrir
conectores directos, es decir, sin cabecera IP.


Un socket Raw puede asociarse con un valor particular del campo Protocolo del
paquete IP, de esta manera todos los paquetes que se reciban y que tenga este
valor especifico de Protocolo pasaran al conector directo. En Linux se agrega una
condicin mas y es que cuando el protocolo que especifica al conector es
IPPROTO_RAW entonces el valor IP_HDRINCL estara activo y en ese caso el
conector recibira todos los paquetes independientemente del valor del protocolo.

Por otro lado, cuando se reciba paquete nuevo este sera pasado a cualquier Socket
Raw que haya sido asociado a su protocolo. Luego el kernel del sistema operativo
tambin pasar dicho paquete a cualquier otro manejador que pueda existir de ese
protocolo. No se utilizan puertos ya que en estos sockets el kernel es el encargado
de pasar la informacin de un cierto protocolo a todos los sockets que estan
escuchando el mismo protocolo, ademas no hay conexiones de red virtuales como
en modelos anteriores.

En cuanto a las comunicaciones no se usa ningun estndar ya que el programador
debe generar ste, por lo que para cada servidor debe implementarse un cliente
personalizado. Si se hace uso de protocolos ya existentes deben rellenarse los
campos de dichos protocolos manualmente ya que el kernel no realiza esta
operacin.

En sntesis, este tipo de socket proporciona tres caracteristicas no ofrecidas
normalmente por los sockets TCP o UDP:

a) permite que el programador lea o escriba mensajes ICMP (Internet Control
Messagges Protocol) e IGMP (Internet Group Messagges Protocol)
b) las aplicaciones podran escribir y leer mensajes tipo datagrama Ipv4 sin que
el nucleo genere un campo de protocolo Ipv4
c) un proceso tiene la capacidad de construir su propia cabecera Ipv4 para ello
llama al servicio apropiado con la opcion IP_HDRINCL.

Para complementar las caracteristicas, en UNIX la creacion de los sockets raw
requiere que el usuario tenga privilegios de root y ademas utilizar el socket() de la
siguiente forma:
s=socket( AF_INET, SOCK_RAW, [protocolo])

Luego de esto, ser posible enviar o recibir datos mediante este socket. Adems,
pueden utilizarse para generar o recibir paquetes de un tipo que el kernel no
soporta de manera explcita.

5.3.1.1 Implementacin de socket raw bajo un lenguaje de programacin

En este punto evaluaremos algunos breves ejemplos de implementacion de este
socket en lenguajes como Java, C++ o C# en donde veremos ventajas o
desventajas de implementacin.

a) Lenguaje Java

Java no soporta socket raw debido a que esta implementado solo en socket TCP o
UDP. Para tal efecto, este lenguaje utiliza una interface denominada
SocketImplFactory el cual se declara de la siguiente manera:

SocketImpl createSocketImpl( )


SocketImpl es la superclase de todos las implementaciones de sockets. Un objeto
de esta clase es usado como argumento para la creacin de sockets.

Por otro lado, se han desarrollado diferentes librerias de terceros para permitir el
uso de sockets raw en Java, entre ellas, tenemos a RockSaw
(http://www.savarese.com/software/rocksaw/) el cual es proporcionado en
plataforma independiente. Consta de un archivo Jar que es de tipo
multiplataforma. A continuacion un ejemplo de codigo Java para socket raw
usando esta librera

/*
* Copyright 2004-2007 Daniel F. Savarese
* Copyright 2009 Savarese Software Research Corporation
*
* Licensed under the Apache License, Version 2.0 (the License);
package example;

import java.io.IOException;
import java.net.InetAddress;
import java.net.Inet6Address;
import java.util.Enumeration;
import java.util.concurrent.*;

import org.savarese.vserv.tcpip.*;
import com.savarese.rocksaw.net.RawSocket;
import static com.savarese.rocksaw.net.RawSocket.PF_INET;
import static com.savarese.rocksaw.net.RawSocket.PF_INET6;
import static com.savarese.rocksaw.net.RawSocket.getProtocolByName;
import static org.savarese.vserv.tcpip.ICMPPacket.OFFSET_ICMP_CHECKSUM;

/**
* <p>The Ping class is a simple demo showing how you can send
* ICMP echo requests and receive echo replies using raw sockets.
* It has been updated to work with both Ipv4 and Ipv6.</p>
*
* <p>Note, this is not a model of good programming. The point
* of the example is to show how the RawSocket API calls work. There
* is much kluginess surrounding the actual packet and protocol
* handling, all of which is outside of the scope of what RockSaw
* does.</p>
*
* @author <a href=http://www.savarese.org/>Daniel F. Savarese</a>
*/

public class Ping {

public static interface EchoReplyListener {
public void notifyEchoReply(ICMPEchoPacket packet,
byte[] data, int dataOffset,
byte[] srcAddress)
throws IOException;
}

public static class Pinger {
private static final int TIMEOUT = 10000;


protected RawSocket socket;
protected ICMPEchoPacket sendPacket, recvPacket;
protected int offset, length, dataOffset;
protected int requestType, replyType;
protected byte[] sendData, recvData, srcAddress;
protected int sequence, identifier;
protected EchoReplyListener listener;

protected Pinger(int id, int protocolFamily, int protocol)
throws IOException
{
sequence = 0;
identifier = id;
setEchoReplyListener(null);

sendPacket = new ICMPEchoPacket(1);
recvPacket = new ICMPEchoPacket(1);
sendData = new byte[84];
recvData = new byte[84];

sendPacket.setData(sendData);
recvPacket.setData(recvData);
sendPacket.setIPHeaderLength(5);
recvPacket.setIPHeaderLength(5);
sendPacket.setICMPDataByteLength(56);
recvPacket.setICMPDataByteLength(56);

offset = sendPacket.getIPHeaderByteLength();
dataOffset = offset + sendPacket.getICMPHeaderByteLength();
length = sendPacket.getICMPPacketByteLength();

socket = new RawSocket();
socket.open(protocolFamily, protocol);

try {
socket.setSendTimeout(TIMEOUT);
socket.setReceiveTimeout(TIMEOUT);
} catch(java.net.SocketException se) {
socket.setUseSelectTimeout(true);
socket.setSendTimeout(TIMEOUT);
socket.setReceiveTimeout(TIMEOUT);
}
}

public Pinger(int id) throws IOException {
this(id, PF_INET, getProtocolByName(icmp));

srcAddress = new byte[4];
requestType = ICMPPacket.TYPE_ECHO_REQUEST;
replyType = ICMPPacket.TYPE_ECHO_REPLY;
}

protected void computeSendChecksum(InetAddress host)
throws IOException

{
sendPacket.computeICMPChecksum();
}

public void setEchoReplyListener(EchoReplyListener l) {
listener = l;
}

/**
* Closes the raw socket opened by the constructor. After calling
* this method, the object cannot be used.
*/
public void close() throws IOException {
socket.close();
}

public void sendEchoRequest(InetAddress host) throws IOException {
sendPacket.setType(requestType);
sendPacket.setCode(0);
sendPacket.setIdentifier(identifier);
sendPacket.setSequenceNumber(sequence++);

OctetConverter.longToOctets(System.nanoTime(), sendData, dataOffset);

computeSendChecksum(host);

socket.write(host, sendData, offset, length);
}

public void receive() throws IOException {
socket.read(recvData, srcAddress);
}

public void receiveEchoReply() throws IOException {
do {
receive();
} while(recvPacket.getType() != replyType ||
recvPacket.getIdentifier() != identifier);

if(listener != null)
listener.notifyEchoReply(recvPacket, recvData, dataOffset, srcAddress);
}

/**
* Issues a synchronous ping.
*
* @param host The host to ping.
* @return The round trip time in nanoseconds.
*/
public long ping(InetAddress host) throws IOException {
sendEchoRequest(host);
receiveEchoReply();

long end = System.nanoTime();
long start = OctetConverter.octetsToLong(recvData, dataOffset);


return (end start);
}

/**
* @return The number of bytes in the data portion of the ICMP ping request
* packet.
*/
public int getRequestDataLength() {
return sendPacket.getICMPDataByteLength();
}

/** @return The number of bytes in the entire IP ping request packet. */
public int getRequestPacketLength() {
return sendPacket.getIPPacketLength();
}
}

public static class PingerIPv6 extends Pinger {
private static final int IPPROTO_ICMPV6 = 58;
private static final int ICMPv6_TYPE_ECHO_REQUEST = 128;
private static final int ICMPv6_TYPE_ECHO_REPLY = 129;

/**
* Operating system kernels are supposed to calculate the ICMPv6
* checksum for the sender, but Microsofts Ipv6 stack does not do
* this. Nor does it support the IPV6_CHECKSUM socket option.
* Therefore, in order to work on the Windows family of operating
* systems, we have to calculate the ICMPv6 checksum.
*/
private static class ICMPv6ChecksumCalculator extends IPPacket {
ICMPv6ChecksumCalculator() { super(1); }

private int computeVirtualHeaderTotal(byte[] destination, byte[] source,
int icmpLength)
{
int total = 0;

for(int I = 0; I < source.length;)
total+=(((source[i++] & 0xff) << 8) | (source[i++] & 0xff));
for(int I = 0; I < destination.length;)
total+=(((destination[i++] & 0xff) << 8) | (destination[i++] & 0xff));

total+=(icmpLength >>> 16);
total+=(icmpLength & 0xffff);
total+=IPPROTO_ICMPV6;

return total;
}

int computeChecksum(byte[] data, ICMPPacket packet, byte[] destination,
byte[] source)
{
int startOffset = packet.getIPHeaderByteLength();
int checksumOffset = startOffset + OFFSET_ICMP_CHECKSUM;

int ipLength = packet.getIPPacketLength();
int icmpLength = packet.getICMPPacketByteLength();

setData(data);

return
_computeChecksum_(startOffset, checksumOffset, ipLength,
computeVirtualHeaderTotal(destination, source,
icmpLength), true);
}
}

private byte[] localAddress;
private ICMPv6ChecksumCalculator icmpv6Checksummer;

public PingerIPv6(int id) throws IOException {
super(id, PF_INET6, IPPROTO_ICMPV6 /*getProtocolByName(ipv6-icmp)*/);

icmpv6Checksummer = new ICMPv6ChecksumCalculator();
srcAddress = new byte[16];
localAddress = new byte[16];
requestType = ICMPv6_TYPE_ECHO_REQUEST;
replyType = ICMPv6_TYPE_ECHO_REPLY;
}

protected void computeSendChecksum(InetAddress host)
throws IOException
{
// This is necessary only for Windows, which doesnt implement
// RFC 2463 correctly.
Socket.getSourceAddressForDestination(host, localAddress);
icmpv6Checksummer.computeChecksum(sendData, sendPacket,
host.getAddress(), localAddress);
}

public void receive() throws IOException {
socket.read(recvData, offset, length, srcAddress);
}

public int getRequestPacketLength() {
return (getRequestDataLength() + 40);
}
}

public static final void main(String[] args) throws Exception {
if(args.length < 1 || args.length > 2) {
System.err.println(usage: Ping host [count]);
System.exit(1);
}

final ScheduledThreadPoolExecutor executor =
new ScheduledThreadPoolExecutor(2);

try{
final InetAddress address = InetAddress.getByName(args[0]);

final String hostname = address.getCanonicalHostName();
final String hostaddr = address.getHostAddress();
final int count;
// Ping programs usually use the process ID for the identifier,
// but we cant get it and this is only a demo.
Final int id = 65535;
final Pinger ping;

if(args.length == 2)
count = Integer.parseInt(args[1]);
else
count = 5;

if(address instanceof Inet6Address)
ping = new Ping.PingerIPv6(id);
else
ping = new Ping.Pinger(id);

ping.setEchoReplyListener(new EchoReplyListener() {
StringBuffer buffer = new StringBuffer(128);

public void notifyEchoReply(ICMPEchoPacket packet,
byte[] data, int dataOffset,
byte[] srcAddress)
throws IOException
{
long end = System.nanoTime();
long start = OctetConverter.octetsToLong(data, dataOffset);
// Note: Java and JNI overhead will be noticeable (100-200
// microseconds) for sub-millisecond transmission times.
// The first ping may even show several seconds of delay
// because of initial JIT compilation overhead.
Double rtt = (double)(end start) / 1e6;

buffer.setLength(0);
buffer.append(packet.getICMPPacketByteLength())
.append( bytes from ).append(hostname).append( ();
buffer.append(InetAddress.getByAddress(srcAddress).toString());
buffer.append(): icmp_seq=)
.append(packet.getSequenceNumber())
.append( ttl=).append(packet.getTTL()).append( time=)
.append(rtt).append( ms);
System.out.println(buffer.toString());
}
});

System.out.println(PING + hostname + ( + hostaddr + ) +
ping.getRequestDataLength() + ( +
ping.getRequestPacketLength() + ) bytes of data).);

final CountDownLatch latch = new CountDownLatch(1);

executor.scheduleAtFixedRate(new Runnable() {
int counter = count;


public void run() {
try {
if(counter > 0) {
ping.sendEchoRequest(address);
if(counter == count)
latch.countDown();
--counter;
} else
executor.shutdown();
} catch(IOException ioe) {
ioe.printStackTrace();
}
}
}, 0, 1, TimeUnit.SECONDS);

// We wait for first ping to be sent because Windows times out
// with WSAETIMEDOUT if echo request hasnt been sent first.
// POSIX does the right thing and just blocks on the first receive.
// An alternative is to bind the socket first, which should allow a
// receive to be performed first on Windows.
Latch.await();

for(int I = 0; I < count; ++i)
ping.receiveEchoReply();

ping.close();
} catch(Exception e) {
executor.shutdown();
}
}

}

b) Lenguaje C#

En este lenguaje la construccin de un socket de tipo raw se dar utilizando el
constructor socket y posteriormente configurando este con el mtodo
SetSocketOption y luego se enviar la informacin de la cabecera IP
correspondiente, como se ve a continuacin.

Socket sok = new
Socket(AddressFamily.InterNetwork,System.Net.Socke ts.SocketType.Raw,
ProtocolType.Raw);

Parmetros
addressFamily
Tipo: System.Net.Sockets.AddressFamily
Uno de los valores de AddressFamily.

socketType
Tipo: System.Net.Sockets.SocketType
Uno de los valores de SocketType.


protocolType
Tipo: System.Net.Sockets.ProtocolType
Uno de los valores de ProtocolType.

sok.SetSocketOption(SocketOptionLevel.IP,SocketOpt ionName.HeaderIncluded,tru
e);

Es necesario precisar que la opcin IP_ HDRINCL as como los sockets raw en
general son un asunto importante de seguridad en los sistemas operativos a partir
de Windows NT y superiores, debido a ello se necesita ser miembro del grupo de
administradores para poder crear sockets de este tipo. Si se desea eliminar esta
restriccin debe cambiarse la siguiente variable de registro (mediante regedit):
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\Afd\Parameters\DisableR
awSecurity cuyo nuevo valor sera 1.

Como ejemplo de uso a continuacin se muestra un programa en C# que utiliza
socket raw (http://www.eggheadcafe.com/articles/20020209.asp).

Using System;
namespace .CBS.Util // change this to yourcompany.yourdivision.whatever
{
using System;
using System.Net;
using System.Net.Sockets;
/// <summary>
/// The Main Ping Class
/// </summary>
public class Ping
{
//Declare some Constant Variables
const int SOCKET_ERROR = -1;
const int ICMP_ECHO = 8;
/// <summary>

/// </summary>
public static void Main()
{

}

/// <summary>
/// This public method takes the hostname of the server
/// and then it pings it and shows the response time
/// Data is returned as a string. IP addresses are resolved.
/// Example usage:
/// using .CBS.Util
/// Ping p = new Ping();
/// textBox2.Text = p.PingHost(textBox1.Text);
/// </summary>
public string PingHost(string host)
{
//Declare the IPHostEntry
IPHostEntry serverHE, fromHE;
int nBytes = 0;

int dwStart = 0, dwStop = 0;
//Initialize a Socket of Type ICMP

Socket socket =
new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);
socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.SendTimeout, 1000);
// Get the server endpoint
try
{
serverHE = Dns.GetHostByName(host);
}
catch(Exception)
{

return Host not found; // uh-oh!
}
// Convert the server IP_EndPoint to an EndPoint
IPEndPoint ipepServer = new IPEndPoint(serverHE.AddressList[0], 0);
EndPoint epServer = (ipepServer);
// Set the receiving endpoint to the client machine
fromHE = Dns.GetHostByName(Dns.GetHostName());
IPEndPoint ipEndPointFrom = new IPEndPoint(fromHE.AddressList[0], 0);
EndPoint EndPointFrom = (ipEndPointFrom);
int PacketSize = 0;
IcmpPacket packet = new IcmpPacket(); // didnt know we had this in .Net, eh?
// (script kiddies: GET LOST!)
// Construct the packet to send
packet.Type = ICMP_ECHO; //8
packet.SubCode = 0;
packet.CheckSum = Uint16.Parse(0);
packet.Identifier = Uint16.Parse(45);
packet.SequenceNumber = Uint16.Parse(0);
int PingData = 32; // sizeof(IcmpPacket) 8;
packet.Data = new Byte[PingData];
//Initialize the Packet.Data
for (int I = 0; I < PingData; i++)
{
packet.Data[i] = (byte)#;
}

// Variable to hold the total Packet size
PacketSize = PingData + 8;
Byte [] icmp_pkt_buffer = new Byte[ PacketSize ];
Int32 Index = 0;
// Call Method Serialize which counts
// The total number of Bytes in the Packet
Index = Serialize(
packet,
icmp_pkt_buffer,
PacketSize,
PingData );
//Error in Packet Size
if( Index == -1 )
{
return Error Creating Packet;


}

// convert into a Uint16 array
//Get the Half size of the Packet
Double double_length = Convert.ToDouble(Index);
Double dtemp = Math.Ceiling( double_length / 2);
int cksum_buffer_length = Convert.ToInt32(dtemp);
//Create a Byte Array
Uint16 [] cksum_buffer = new Uint16[cksum_buffer_length];
//Code to initialize the Uint16 array
int icmp_header_buffer_index = 0;
for( int I = 0; I < cksum_buffer_length; i++ )
{
cksum_buffer[i] =
BitConverter.ToUInt16(icmp_pkt_buffer,icmp_header_buffer_index);
icmp_header_buffer_index += 2;
}
//Call method to return a checksum
Uint16 u_cksum = checksum(cksum_buffer, cksum_buffer_length);
//Save checksum to Packet
packet.CheckSum = u_cksum;

// Now that we have the checksum, serialize the packet again
Byte [] sendbuf = new Byte[ PacketSize ];
//again check the packet size
Index = Serialize(
packet,
sendbuf,
PacketSize,
PingData );
//if there is an error return it
if( Index == -1 )
{
return Error Creating Packet;

}

dwStart = System.Environment.TickCount; // Start timing
//send the Packet over the socket
if ((nBytes = socket.SendTo(sendbuf, PacketSize, 0, epServer)) == SOCKET_ERROR)
{
return Socket Error: cannot send Packet;
}
// Initialize the buffers. The receive buffer is the size of the
// ICMP header plus the IP header (20 bytes)
Byte [] ReceiveBuffer = new Byte[256];
nBytes = 0;
// Receive the bytes
bool recd =false ;
int timeout=0 ;

// loop for checking the time of the server response
while(!recd)
{

nBytes = socket.ReceiveFrom(ReceiveBuffer, 256, 0, ref EndPointFrom);
if (nBytes == SOCKET_ERROR)
{
return Host not Responding ;

}
else if(nBytes>0)
{
dwStop = System.Environment.TickCount dwStart; // stop timing
return Reply from +epServer.ToString()+ in
+dwStop+ms. Received: +nBytes+ Bytes.;

}
timeout=System.Environment.TickCount dwStart;
if(timeout>1000)
{
return Time Out ;

}
}

// close the socket
socket.Close();
return ;
}
/// <summary>
/// This method get the Packet and calculates the total size
/// of the Pack by converting it to byte array
/// </summary>
public static Int32 Serialize(IcmpPacket packet, Byte[] Buffer,
Int32 PacketSize, Int32 PingData )
{
Int32 cbReturn = 0;
// serialize the struct into the array
int Index=0;
Byte [] b_type = new Byte[1];
b_type[0] = (packet.Type);
Byte [] b_code = new Byte[1];
b_code[0] = (packet.SubCode);
Byte [] b_cksum = BitConverter.GetBytes(packet.CheckSum);
Byte [] b_id = BitConverter.GetBytes(packet.Identifier);
Byte [] b_seq = BitConverter.GetBytes(packet.SequenceNumber);

Array.Copy( b_type, 0, Buffer, Index, b_type.Length );
Index += b_type.Length;

Array.Copy( b_code, 0, Buffer, Index, b_code.Length );
Index += b_code.Length;

Array.Copy( b_cksum, 0, Buffer, Index, b_cksum.Length );
Index += b_cksum.Length;


Array.Copy( b_id, 0, Buffer, Index, b_id.Length );
Index += b_id.Length;
Array.Copy( b_seq, 0, Buffer, Index, b_seq.Length );
Index += b_seq.Length;
// copy the data
Array.Copy( packet.Data, 0, Buffer, Index, PingData );
Index += PingData;
if( Index != PacketSize/* sizeof(IcmpPacket) */)
{
cbReturn = -1;
return cbReturn;
}
cbReturn = Index;
return cbReturn;
}
/// <summary>
/// This Method has the algorithm to make a checksum
/// </summary>
public static Uint16 checksum( Uint16[] buffer, int size )
{
Int32 cksum = 0;
int counter;
counter = 0;
while ( size > 0 )
{
Uint16 val = buffer[counter];
cksum += Convert.ToInt32( buffer[counter] );
counter += 1;
size -= 1;
}
cksum = (cksum >> 16) + (cksum & 0xffff);
cksum += (cksum >> 16);
return (Uint16)(~cksum);
}
} // class ping
/// <summary>
/// Class that holds the Packet information
/// </summary>
public class IcmpPacket
{
public Byte Type; // type of message
public Byte SubCode; // type of sub code
public Uint16 CheckSum; // ones complement checksum of struct
public Uint16 Identifier; // identifier
public Uint16 SequenceNumber; // sequence number
public Byte [] Data;
} // class IcmpPacket
}

c) Lenguaje C/C++


En este lenguaje la implementacin de los sockets en general utilizan el mismo
mtodo, lo que diferencia a los diversos tipos es la variable type. El cdigo de
creacin es el siguiente:

#include <sys / type s . h>
#include <sys / s o cke t . h>
int s o cke t ( int domain , int type , int pr o t o c o l ) ;

En este cdigo el valor de domain sera PF_INET, el valor de type es SOCKRAW y
por otro lado, el valor de protocol define que protocolo se va a utilizar con este
socket. Los valores que pueden colocarse son los siguientes:

enum(
IPPROTO IP = 0 , /_TCP 101rans p r o t o c o l _/
IPPROTO ICMP = 0 , /_ICMP p r o t o c o l _/
IPPROTO TCP = 0 , /_TCP p r o t o c o l _/
IPPROTO UDP = 0 , /_UDP p r o t o c o l _/
IPPROTO IPV6 = 0 , /_ Ipv6 p r o t o c o l _/
IPPROTORAW = 0 , /_RAW p r o t o c o l _/
) ;

A continuacin se mostrar un ejemplo de cdigo utilizando C para este tipo de
socket (http://www.scribd.com/doc/18015337/Raw-Sockets-Programming-with-C-
spanish).

#include <stdio.h>
#include <string.h>
#include<linux/ifether.h>
/* Librera de los sockets */
#include <sys/socket.h>
#include <net inet/in.h>
/*Para obtener datos de capa 3 */
#include <net inet/ip.h>
/*Para obtener datos de capa 4 */
/*Usaremos la estructura BSD para TCP hdr */
#define FAVOR BSD
#include <net inet/tcp.h>
#include <un s td . h>
/*Puerto a l cual se va a enviar el paquete */
#define P 22
101ran =0;
/* Recordemos que al no tener el stack TCP/IP */
/* implementado tendremos que hacer el checksum */
/* manualmente con ayuda de esta funcin */
unsigned short csum (unsigned short _buf , int nwords ) f
unsigned long sum;
for ( sum = 0 ; nwords > 0 ; nwords++)
sum += _ buf++;
sum = ( sum >> 16) + ( sum & 0 x f f f f ) ;
sum += ( sum >> 16) ;
return ~sum;
g
int main ( int argc , char [] argv ) f
int one = 1 ;
const int _ val = &one ;

p r i n t f ( Ini c i amos envio de paquetes nn ) ;
/*Creamos e l s o c k e t crudo , e l cual implementar_a TCP/IP */

int s = s o cke t (PF INET, SOCKRAW, IPPROTO TCP) ;
/*Creamos un b u f f e r que contendr_a l a s cabeceras , IP y TCP */
/*adem_as d e l payload */
char datagram [ 4 0 9 6 ] ;
/*En e s t e caso iremos d e l p r o t o c o l o m_as bajo a l m_as a l t o
por l o que empezaremos con IP , a l c r ear una e s t u c t u r a i p */
struct ip _ iph = ( struct ip _) datagram ;
/*Usaremos una e s t u c t u r a de s o c k e t para e l env__o de paque t e s
*/
struct s o ckaddr in s I n ;
/*Usaremos l a f ami l i a INET a l t ene r que s a l i r por l a red */
s I n . s I n f ami l y = AF INET;
/*Se e s cog e un pue r to d e s t ino a l que se enviar_an l o s paque t e s
*/
s I n . s I n p o r t = htons (P) ;
/*Escogemos l a IP d e s t ino de nue s t r o s paque t e s */
s I n . s in addr . s addr = ine t addr ( 1 3 2 . 2 4 8 . 5 9 . 1 ) ;
/*Ponemos e l b u f f e r con l o s header s en cero */
memset ( datagram , 0 , 4096) ;
/* Hasta e s t a p ar t e podr_an pensar que no hemos hecho nada
d i f e r e n t e
ya que se usa una e s t r u c t u r a s o c k a d d r in para e l e g i r d e s t ino y
todo
parece s e r l o mismo , pero ahora tendremos e l c o n t r o l de l o s
campos
de l a s cab e c e ras IP y TCP, para e n v i a r l o s por l a red */
/* Por l o que empezamos a r e l l e n a r l o s manualmente */
/**/
/* HEADER IP */
iph>i p h l = 5 ;
/* Se e s cog e l a v e r s i _on de Ipv4 */
iph>ip v = 4 ;
/* Se e s cog e e l Type o f Se r v i c e */
iph>i p t o s = 0 ;
/* Se da l a l o n g i t u d de l a cab e c e ra IP */
iph>I p l e n = s izeof ( struct ip ) + s izeof ( struct tcphdr ) ;
p r I n t f ( Esta e s l a l ong I tud I p l e n %d nn , iph>I p l e n ) ;
/* I d e n t i f i c a d o r d e l paque t e */
iph>I p I d = htonl (54321) ;
/* Se da e l o f f s e t d e l paque t e */
iph>i p o f f = 0 ;
/* Ponemos e l t ime t o l i v e */
iph>i p t t l = 255;
/* Se e soc g e e l p r o t o c o l o a usar */
iph>ip p = 6 ; // 6 a l s e r TCP / e t c / p r o t o c o l
/* Moment_aneamente pones e l checksum a cero */
iph>ip sum = 0 ;
/* Se e s cog e l a i p 102ransmi , s__ c l a r o pondremos l a que queramos
XD */
/* Pero s i queremos s a l i r por l a red , e l 102rans ISP no
p e rmi t i r _a c u a l q u i e r d i r e c c i _on en e s t e campo */
iph>I p s r c . s addr = ine t addr ( 1 9 2 . 1 6 8 . 1 . 7 0 ) ;

/* Se d e f i n e l a ip d e s t ino mediante l a e s t r u c t u r a d e f i n i d a
ant e r iorment e */
iph>I p d s t . s addr = s I n . s in addr . s addr ;
/**/
/* HEADER TCP */
/*Ahora crearemos la estrutura TCP */
struct tcphdr _ tcph = ( struct tcphdr _) ( datagram + iph>
I p h l _4 ) ;
p r I n t f ( Esta es la 103ransmisi s t r u c t ip %d nn , s izeof (_ iph ) ) ;
p r I n t f ( Esta es la l ong I tud s t r u c t tcphdr %d nn , s izeof (_
tcph ) ) ;
/* Se da e l pue r to or i g en d e l paque t e */
tcph>t h s p o r t = htons (45521) ;
/* Se da e l pue r to d e s t ino d e l paque t e */
tcph>th dpor t = htons (P) ;
/* Se da e l n_umero de s e 103ransm ia d e l paque t e */
tcph>th s e q = random( ) ;
/* N_umero de l a s e 103ransm ia ACK */
tcph>103ransm = 0 x00000000 ;
tcph>th x2 = 0 ;
/* Se da e l o f f s e t de l a cab e c e ra TCP (5_4) */
tcph>t h o f f = 5 ;
/* Ponemos para l a p e t i c i _o n de una conexi_on */
tcph>t h f l a g s = TH SYN;
/* Indicamos e l tama~no de l a ventana */
tcph>th win = 0 x018f ;
/* Si ponemos e l checksum TCP a cero aunque digan que
e l s t a c k l o r e l l e n a en l o p e r s ona l no me funcion_o , por
PARTE 3. RAW SOCKET ? 25
l o que tuv e que hacer e l checksum */
checksum c o r r e c t o */
tcph>th sum = 0 x60fa ;
tcph>th urp = 0 ;
/*Se da e l checksum d e l paque t e y se i n c l u y e en e l campo */
iph>ip sum = csum ( ( unsigned short _) datagram , iph>I p l e n
>> 1) ;
p r I n t f ( Checksum ip %x nn , iph>ip sum) ;
/* Al usar IP HDRINCL l e decimos que estamos
inc luy endo e l header IP en e l paque t e */
I f ( s e t s o c k opt ( s , IPPROTO IP, IP HDRINCL, val , s izeof ( one )
) < 0)
p r I n t f ( 103ransm : No s e modi f I c_o e l s o cke t nn ) ;
while ( I !=10) f
i++;
I f ( sendto ( s , datagram , ( iph>I p l e n ) , 0 , ( struct sockaddr _)
&s in , s izeof ( s I n ) ) < 0)
printf ( Paquete no se ha podido enviar nn ) ;
el se
printf ( Paquete enviado nn ) ;
}
return 0 ;
}


5.4 Socket Seqpacket

Este tipo de socket tiene caracteristicas similares al socket stream pero con la
diferencia de que el tamao de los mensajes siempre sera fijo.

Su funcionamiento depender del sistema operativo en el cual se est trabajando,
en el caso de windows la API de comunicaciones WinSock mantiene el control de los
mensajes y en el cual basicamente se indica de que para cada operacin send()
sta sera recibida con una sola operacin receive(). Esta forma de trabajo podria
ser modificada con el bit MSG_PARTIAL el cual permitiria multiples envios dentro de
un unico mensaje y nuevamente sera recibida con un unico receive().

En el sistema operativo Linux se configura la operacin socket para utilizar el tipo
Seqpacket de acuerdo al dominio con que se quiera trabajar algunos valores son los
siguientes:

Dominio PF_INET6: Permite servicios de tipo TCP para sockets de tipo Ipv6.
Se utiliza el protocolo TCP/IP y en el los limites del mensaje a enviar se
conservan y se mantiene la secuencia de datos definida.
Dominio PF_X25: Permite servicios de tipo TCP para el protocolo X25, Este
servicio est orientado a conexin y es seguro as como los lmites del
mensaje a enviar se conservan y se mantiene la secuencia de datos
definida.
Dominio PF_IPX: Para protocolo IPX, se usa en socket de paquetes
secuenciales.
Dominio PF_IrDA: Soporta subsistema IrDA usando un socket stream que
preserva los limites del mensaje (en comunicaciones infrarrojas).
Dominio PF_NetROM: Para protocolo NetROM de radio amateur.

A continuacin se muestra un fragmento de cdigo C# que permite crear un socket
de tipo Seqpacket para uso:

listeningSock = new Socket(AddressFamily.InterNetwork,
SocketType.Seqpacket, ProtocolType.Unspecified);
// Bind to the local IP Address
listeningSock.Bind(ipLocal);
// Start listening
// WARNING ONLY 10
listeningSock.Listen(10);
// Now begin receiving connections
listeningSock.BeginAccept(new AsyncCallback(OnConnectionRequest), null);

Una observacin importante, la semntica Seqpacket solo es soportada por
NetBIOS de acuerdo a ello solo puede ser utilizado de la siguiente manera:

Socket sock = new Socket(AddressFamily.NetBios, SocketType.Seqpacket,
ProtocolType.Unspecified);



Resumen

La comunicacin entre procesos es uno de los mecanismos ms importantes para el
funcionamiento de los Sistemas Distribuidos, trata sobre la forma como un cliente
puede comunicarse con un servidor para ello esta comunicacin tendr 3
caractersticas fundamentales: dominio, tipo y protocolo.

El medio a travs del cual la comunicacin de procesos se realiza es mediante el
socket conformado por la direccin IP que identifica la maquina que participa en la
comunicacin y el puerto que identifica al proceso participante, tanto en emisin
como en recepcin.

Los sockets pueden presentarse en cuatro tipos: tipo datagrama (que usa el
protocolo UDP), tipo stream (que usa el protocolo TCP), tipo raw (que no utiliza
cabeceras ni de transporte ni red), Seqsocket (similar al stream, pero que maneja
mensaje de tamao fijo).

Hay sockets como el de tipo raw que no son soportados por el lenguaje Java y
requieren de una implementacin especial, o como los de seqsocket que su
funcionamiento depende del sistema operativo que se est utilizando. En el caso
de TCP o UDP Java utiliza la librera Java.net para implementar sockets de esas
caractersticas.

Los sockets de tipo datagrama son poco confiables envan sus paquetes de manera
simultnea y tiene un algoritmo de reconstruccin de mensaje ms complicado que
el socket de tipo TCP, el cual enva los paquetes de modo secuencial a travs de un
mecanismo de flujo de bytes (stream) el cual fue creado previamente durante la
etapa de sincronismo, tiene la capacidad de retransmisin y su algoritmo de
recuperacin de mensaje es sencillo.

En cada tipo de sockets hay una operacin que realiza la tarea de transmitir el
mensaje que generalmente es de tipo no bloqueante, por otro lado, existir una
operacin que recupera el mensaje recibido que generalmente es de tipo
bloqueante.

Finalmente, los sockets realizan intercambio de mensajes en el nivel ms bajo
(generalmente entre las capas dos, tres y cuatro del nivel OSI), mejorndose esta
implementacin con el concepto URL que se ver posteriormente.



Lectura

Interoperabilidad de aplicaciones Ipv4 e Ipv6

Durante los primeros 1990 se hicieron obvios varios problemas de la
implementacin de IP desplegada, Ipv4 como el escaso espacio de direccionamiento
y la gestin del encaminamiento. Con la intencin de resolverlos se desarrollaron
algunos mecanismos especficos, como por ejemplo Network Address Translation
(NAT), que es en la actualidad uno de los ms extendidos. Sin embargo, NAT
elimina el servicio de comunicacin entre entidades finales y rompe el modelo de
comunicacin extremo a extremo inicialmente planteado en IP. La demanda de
comunicacin entre sistemas finales de las nuevas aplicaciones Peer-To-Peer (P2P)
y la necesidad de calidad de servicio en las comunicaciones, han impulsado el
desarrollo de Ipv6.

Actualmente millones de mquinas estn conectadas a Internet usando Ipv4 y es
imposible realizar el cambio a Ipv6 de forma inmediata. La transicin se est
realizando de forma gradual, primero portando la infraestructura de red, junto con
sus servicios bsicos y en segundo lugar, las aplicaciones.

Una de las principales preocupaciones durante el perodo de transicin es la
interoperabilidad entre las aplicaciones ya existentes y las nuevas desarrolladas
para Ipv6. En la mayora de los casos la interoperabilidad de aplicaciones se
consigue utilizando nodos que implementen ambos protocolos, es decir, nodos
duales que puedan comunicarse utilizando tanto Ipv4 como Ipv6. Los nodos con
pila dual proporcionan un mecanismo para permitir a las aplicaciones Ipv4
comunicarse con aplicaciones Ipv6 utilizando el protocolo Ipv4 para el intercambio
de paquetes entre los nodos finales. Sin embargo, en los escenarios en los que la
conectividad entre los nodos origen y destino slo es posible utilizando Ipv6, la pila
dual no ser suficiente para establecer la comunicacin y se necesitar algn
mecanismo de transicin adicional.

El objetivo de este trabajo es permitir la interoperabilidad de aplicaciones Ipv4 e
Ipv6 cuando slo es posible utilizar una infraestructura de red Ipv6, sin cambiar el
cdigo fuente de las mismas. En muchos casos no se dispone del cdigo fuente, o
existe un problema de licencias que impide modificarlo. Adems, existen casos en
los que, aunque se dispone del cdigo, portarlo a la nueva interfaz de Ipv6,
distribuirlo e instalarlo puede resultar un trabajo costoso que requiera demasiado
tiempo. Por estos motivos, el caso de estudio de este trabajo es de especial
relevancia durante el perodo de transicin, permitiendo convivencia de
aplicaciones, o partes de una aplicacin, ya portadas a Ipv6 con aplicaciones Ipv4
existentes.

La mayora de los mecanismos de transicin de Ipv6 se han desarrollado para
conectar redes Ipv4 con redes Ipv6 y basan su funcionamiento en entidades
situadas en un punto intermedio de la red que realizan algn tipo de
procesamiento, por ejemplo tneles o traduccin de protocolos, para permitir su
comunicacin. El objetivo de este trabajo no es estudiar mecanismos de transicin
para la interoperabilidad de redes, sino la comunicacin entre aplicaciones
heterogneas Ipv4 e Ipv6 sobre una red que permite nicamente conectividad
Ipv6, sin modificar ningn elemento intermedio de la red, donde muchas veces no
tenemos la posibilidad de cambiar la configuracin.


Partiendo del escenario caso de estudio en el que existen aplicaciones Ipv4 que
necesitan comunicarse con aplicaciones Ipv6 sobre una red Ipv6, lo ms sencillo es
introducir una traduccin Ipv4/Ipv6 en el nodo donde se ejecuta la aplicacin Ipv4.
Parece requisito indispensable que el nodo que realiza la traduccin tenga instalada
la doble pila, Ipv4 para permitir que la aplicacin se ejecute correctamente e Ipv6
para establecer las comunicaciones.

Eva M. Castro, Jess Gonzlez, Gregorio Robles, Toms de Miguel (2004) Grupo de
Sistemas y Comunicaciones, Dpto. Informtica, Estadstica y Telemtica
Universidad Rey Juan Carlos, Madrid, Espaa. Pp 1-6.


Autoevaluacin

1. No es caracterstica de comunicacin de procesos:

a. Latencia b. Paquete c. Sincronismo d. stub

2. Indicar la afirmacin correcta:

a. No es posible tener latencia en un sistema P2P
b. Send() es mtodo de envio en Raw
c. Puerto 80 es reservado por el S.O.
d. Datagrama es concepto definido para P2P

3. Permite que un servidor pueda aceptar datos de varios clientes.

a. Stub b. Proxy c. Entidad d. Transparencia

4. No es tipo de socket :

a. SEQSOCKET b. DATAGRAM c. ACCEPT d. STREAM

5. P2P utiliza sockets para comunicacin entre entidades :

a. Siempre b. Nunca c. En caso de transmisin
d. En caso de recepcin

6. Tipo de socket que no es soportado por Java:

a. UDP b. Raw c. Datagrama d. TCP

7. Dentro de la creacin de un objeto Java ServerSocket, no usa la siguiente
llamada a mtodo:
a. socket b. bind c. accept d. listen

8. En el protocolo orientado a conexin:

a. el cliente no confirma si el mensaje llega a su destino
b. los mensajes estn garantizados para llegar de manera ordenada.
c. no hay necesidad de interrumpir la conexin
d. el transporte es ms barato pero menos fiable que a travs del servicio
de circuito virtual.

9. Los protocolos TCP y UDP en que capa del modelo de referencia OSI
ocupan?
(a) UDP: capa de red (3); TCP: capa de transporte (4).
(b) UDP: capa de transporte (4); TCP: capa de transporte (4).
(c) UDP: capa de red (3); TCP: capa de red (3).
(d) UDP: capa de transporte (4); TCP: capa de red (3).


10. Qu secuencia de llamadas a mtodo realiza: establecer un socket
orientado a conexin, lo nombra, establece recepcin de conexiones, y
espera una conexin entrante?
(a) connect, bind, listen, accept.
(b) socket, bind, recv, accept.
(c) connect, bind, recv, listen.
(d) socket, bind, listen, accept.

Claves: 1:d; 2:c; 3:b; 4:c; 5:a; 6:b; 7:a; 8:b; 9:b; 10: d.


Exploracin on line

http://www.linuxjournal.com/article/3075
http://www.kohala.com/start/ttcp.html
http://www.rabbit.com/documentation/docs/manuals/TCPIP/Introduction/tcpintro.p
df
http://www.tcpipguide.com/free/
http://www.savarese.com/software/rocksaw/
http://www.eggheadcafe.com/articles/20020209.asp
http://www.scribd.com/doc/18015337/Raw-Sockets-Programming-with-C-spanish

Referencia bibliogrfica

[Tenembaum et al, 2008] Tenenbaum A. M., Van Steen M.,(2008) Sistemas
Distribuidos. Principios y paradigmas, 2 Ed. Prentice Hall, Cap. 1: Introduccin, pp.
2-30.

[Colouris et al,2005] Colouris G., Dollimore J., Kingberg M., (2005) Distributed
Systems, Concepts and Design, 4a Ed., EEUU, Addison Wesley. Cap. 3: Networking
and Internetworking .pp 67-70.

[Schwartz, 1994] Schwartz Mischa (1994) Redes de Telecomunicaciones, 1 Ed.
Addison Wesley Iberoamericana, Cap.7: Nivel de transporte.

[Tschudin,2000] Christian Tschudin (2000), From Shannon to network
architectures. Computer Networks, Dept of Computer Systems, Uppsala University,
pp 2-14.

[Cisco,2007]Cisco Networking Academy (2007) Comunicacin a travs de la red.
Aspectos bsicos de networking: Captulo 2.

[Dragoni,2010] Dragoni Nicola (2010) Interprocess Communication, Embedded
Systems Engineering, Universidad Tecnica de Dinamarca. Disponible en
http://www2.imm.dtu.dk/courses/02222/Spring_2010/W3L1/Chapter_04.pdf.

[Schneider,2008] Schneider F.(2008) Application, Transport, Network and Link
Layers, curso de Sistemas Operativos. Universidad de Cornell, EEUU. Disponible en
http://www.cs.cornell.edu/Courses/cs414/2004su/slides/16_networklayers.pdf.

[Stacey,2000] Stacey M. (2000) T/TCP: TCP for Transactions, Revista Linux
Journal, Nro. 70. pp 45-55.

[Baena,2001] Baena J. (2001). Desde SOCKETS hasta Componentes Distribuidos
como fundamento de Sistemas Distribuidos. Sistemas Distribuidos, Universidad
EAFIT.

Unidad Ii

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unidad Ii

Uploaded by

Copyright:

Available Formats

Sistemas Distribuidos I - Unidad II Jorge Guerra Guerra

You might also like