IPC - Comunicacin entre procesos

La espina dorsal de los sistemas distribuidos son los mecanismos de comunicacin

entre procesos (interprocess communication o IPC): la posibilidad de que procesos
separados e independientes (como podr recordar el lector, los procesos son
representaciones en tiempo de ejecucin de programas) se comuniquen entre s para
colaborar en una tarea. n este captulo, se !an a !er los "undamentos, caractersticas,
paradigmas e implementaciones de los mecanismos de comunicacin entre procesos.
NOTA: #n paradigma es un modelo abstracto de cmo se reali$a una determinada
tarea.
La %igura &.' ilustra un mecanismo bsico de comunicacin entre procesos: (os
procesos independientes, con la posibilidad ejecutarse en mquinas separadas,
intercambian datos sobre una red de comunicaciones. n este caso, el proceso ' act)a
como emisor, que transmite datos al proceso &, el receptor.
%I*#+, &.': Comunicacin entre procesos
Proceso ', Proceso &, misor, +eceptor, (atos
n sistemas distribuidos, dos o ms procesos establecen una comunicacin entre ellos
por medio de un protocolo -un conjunto de reglas que deben ser obser!adas por los
participantes en la comunicacin de los datos- acordado por los procesos. #n proceso
puede ser emisor en determinados puntos durante el protocolo . receptor en otros.
Cuando la comunicacin es desde un proceso a )nicamente otro proceso, el modelo de
comunicacin entre procesos se dice que es unidifusin o unicast. Cuando la
comunicacin es desde un proceso con un grupo de procesos, el mecanismo de
comunicacin se denomina multidifusin o multicast, que ser tratado en el Captulo
/. La %igura &.& ilustra el concepto de estos dos tipos de IPC.
%I*#+, &.&.: #nicast . multicast
--
Los sistemas operati!os actuales, como #0I1 . 2indo3s proporcionan
"uncionalidades para la comunicacin entre procesos. Llamaremos a estas
"uncionalidades mecanismos de comunicacin entre procesos a ni!el de sistema
operati!o, para distinguirlos de los mecanismos de comunicacin de alto ni!el. Los
mecanismos de comunicacin a ni!el de sistema operati!o inclu.en colas de
mensajes, sem"oros, . regiones de memoria compartida. (4i el lector no 5a reali$ado
un curso de sistemas operati!os, no se preocupe si no le resultan "amiliares estos
t6rminos7 no !an a ser casos de estudio en este libro.) s posible desarrollar so"t3are
de red usando directamente estas "uncionalidades a ni!el de sistema operati!o.
jemplos de estos programas son los manejadores (drivers) de red . los programas de
e!aluacin de prestaciones.
4e pueden desarrollar tambi6n aplicaciones distribuidas mu. rudimentarias aunque
normalmente no se 5ace, debido a que la complejidad tpica de estas aplicaciones
requiere el uso de alg)n tipo de abstraccin para separar al programador de los
detalles a ni!el de sistema operati!o. l lector puede encontrar ms in"ormacin sobre
mecanismos de comunicacin a ni!el de sistema operati!o en libros sobre dic5os
sistemas operati!os.
NOTA: n ingeniera del so"t3are, se denomina abstraccin a un mecanismo para
ocultar las complejidades internas de una tarea. Por ejemplo los lenguajes de alto
ni!el, como 8a!a proporcionan una abstraccin que permite al programador tener que
comprender los detalles al ni!el del sistema operati!o.
#na interfaz de programacin de aplicaciones (application program interface o
,PI) para un mecanismo de comunicacin entre procesos, normalmente re"erido
como interfaz de programacin solamente, proporciona una abstraccin de los
detalles e interioridades de las "uncionalidades a ni!el de sistema operati!o,
permitiendo de esta "orma al programador concentrarse en la lgica de la aplicacin.
, lo largo del resto de este captulo se !an a abordar las di"erentes inter"aces de
programacin para comunicacin entre procesos.
Un arquetipo de interfaz de programacin para comunicacin
entre procesos
, continuacin se !a a presentar una inter"a$ de programacin que proporciona el
mnimo ni!el de abstraccin para "acilitar la comunicacin entre procesos. Para ello
se necesitan cuatro primiti!as bsicas. Los detalles acerca de estas operaciones (tales
como los argumentos . los !alores de!ueltos) se !ern cuando se comenten
5erramientas . "uncionalidades espec"icas a lo largo de los siguientes captulos. stas
operaciones son:
Enviar: sta operacin se in!oca por el proceso emisor con el propsito de
transmitir datos al proceso receptor. La operacin debe permitir al proceso
emisor identi"icar al proceso receptor . especi"icar los datos a transmitir
Recibir: sta operacin es in!ocada por el proceso receptor con el objeti!o de
aceptar datos de un proceso emisor. La operacin debe permitir al proceso
receptor identi"icar al proceso emisor as como especi"icar el rea de memoria
que permitir almacenar el mensaje, que posteriormente ser accedida por el
receptor.
Conectar: Para mecanismos de comunicacin orientados a cone9in deben
e9istir operaciones que permitan establecer una cone9in lgica entre el
proceso que lo in!oca . otro proceso determinado: un proceso in!oca una
operacin de solicitar-conexin (denominada conectar en adelante) mientras
que el otro proceso solicita la operacin de aceptar-conexin.
Desconectar: Para mecanismos de comunicacin orientados a cone9in, esta
operacin permite que una cone9in lgica, pre!iamente establecida, sea
liberada en ambos e9tremos de la comunicacin.
#n proceso in!olucrado en un mecanismo de comunicacin in!oca estas operaciones
en un orden determinado. La in!ocacin de cada operacin implica la ocurrencia de
un evento. Por ejemplo, una operacin de en!iar solicitada por el proceso emisor
desemboca en el e!ento de transmisin de datos 5acia el proceso receptor, mientras
tanto la in!ocacin de la operacin recibir por parte del proceso receptor implica que
dic5os datos sean entregados al proceso. s necesario indicar que los procesos
participantes in!ocan operaciones de "orma independiente, .a que no 5a. "orma de
conocer el estado del otro proceso.
:odos los paradigmas de sistemas distribuidos que se !an a !er en este libro
proporcionan, implcita o e9plcitamente, operaciones de comunicacin entre
procesos. l siguiente captulo (Captulo ;) presentarn una jerarqua de los
paradigmas de sistemas distribuidos. n los siguientes captulos, se !ern ejemplos de
cmo se utili$an estos paradigmas en protocolos, 5erramientas . "uncionalidades.
Los protocolos de ser!icio de red pueden ser implementados usando operaciones de
comunicacin entre procesos primiti!as. Por ejemplo, en el protocolo <::P bsico
(HyperText Transfer Protocol, protocolo de trans"erencia de 5iperte9to, usado de
"orma e9tensi!a en el entorno 3eb, que ser estudiado en pr9imos captulos) un
proceso, el na!egador 3eb, in!oca una operacin conectar para establecer una
cone9in lgica con otro proceso, el ser!idor 3eb, seguido de una operacin enviar
5acia el ser!idor 3eb, para transmitir los datos que representan una solicitud. l
ser!idor 3eb como respuesta in!oca una operacin en!iar para transmitir los datos
solicitados por el na!egador 3eb. ,l "inali$ar la comunicacin, cada proceso in!oca
su operacin desconectar para "inali$ar con la cone9in. La %igura &.; ilustra la
sequencia de operaciones. 4e !ern protocolos de ser!icio de red como <::P ms
adelante en este . otros captulos.
%I*#+, &.;: Comunicacin entre procesos en <::P bsico.
#n proceso, #na operacin, %lujo de datos, ser!idor 3eb, na!egador 3eb,
operaciones, aceptar cone9iones, recibir (solicitud), en!iar (respuesta), desconectar,
establecer la cone9in, en!iar (solicitud), recibir(respuesta), desconectar.
n el resto de este captulo se !an a tratar determinados aspectos cla!e de estas
operaciones de comunicacin entre procesos.
Sincronizacin de eventos
#na de las ma.ores di"icultades cuando se trabaja con mecanismos de comunicacin
entre procesos es que cada proceso in!olucrado ejecuta de "orma independiente sin
que ninguno de ellos sepa que ocurre en el proceso en el otro e9tremo.
4i tenemos en cuenta el caso del protocolo bsico <::P, tal . como lo 5emos descrito
antes, como se puede obser!ar, los dos e9tremos in!olucrados en el protocolo in!ocan
operaciones de comunicacin en un orden determinado. Por ejemplo, el proceso del
na!egador 3eb no debe in!ocar ninguna operacin enviar antes de 5aber completado
la operacin conectar. :ambi6n es importante que el ser!idor 3eb no empiece a
transmitir datos antes de que el proceso del na!egador 3eb est6 preparado. ,)n ms,
el proceso na!egador necesita conocer cundo los datos solicitados se 5an
transmitido, de tal manera que el subsiguiente procesamiento de los mismos tenga
lugar, inclu.endo el dar "ormato . mostrar los contenidos al usuario.
La "orma ms sencilla que tiene una mecanismo de comunicacin de procesos para
proporcionar sincroni$acin de e!entos es por medio de peticiones bloueantes, que
es la supresin de la ejecucin del proceso 5asta que la operacin in!ocada 5a.a
"inali$ado.
Para ilustrar el uso de las llamadas bloqueantes en la sincroni$acin de e!entos, se !a
a considerar de nue!o el caso del protocolo <::P bsico. #n proceso de na!egador
3eb in!oca una operacin bloqueante para conectar, que bloquea su posterior
ejecucin 5asta que la cone9in 5a.a sido aceptada por el lado ser!idor.
Posteriormente, el proceso na!egador in!oca una operacin recibir bloqueante, la cual
suspende la ejecucin del proceso 5asta que la operacin se 5a.a completado (con
69ito o no). La opcin de bloqueante o no bloqueante se reali$a a ni!el del sistema
operati!o . se inicia por medio de las "uncionalidades proporcionadas por el
mecanismo de comunicacin entre procesos, no por el programador. Los programas
de los dos procesos se muestran en la %igura &.=.
(urante su ejecucin, el proceso se suspende despu6s de que se in!oque cada llamada
bloqueante. Cada !e$ que se ejecuta una in!ocacin a una operacin bloqueante, la
condicin de bloqueo se inicia por las "uncionalidades de comunicacin entre
procesos en conjunto con el sistema operati!o sobre el que se apo.a. La condicin de
bloqueo termina posteriormente cuando la operacin 5a sido completada, en dic5o
instante se dice que el proceso se encuentra desbloqueado. #n proceso desbloqueado
transita al estado de listo . en su momento continuar la ejecucin. n el caso de que
la operacin no pueda ser completada, un proceso bloqueado su"rir un bloueo
indefinido, durante el cual el proceso permanecer en el estado de bloqueado
inde"inidamente, a menos que se tomen las medidas de inter!encin apropiadas.
Las operaciones bloqueantes a menudo se llaman operaciones s!ncronas. Como
alternati!a, las operaciones de comunicacin entre procesos tambi6n pueden ser
as!ncronas o no bloueantes. #na operacin asncrona in!ocada por un proceso no
causar bloqueo, . por consiguiente el proceso es libre de continuar con su ejecucin
una !e$ que se in!oca al mecanismo de comunicacin para reali$ar la operacin
asncrona. 4e in"ormar posteriormente al proceso si la operacin se 5a completado .
si lo 5a sido con 69ito o no.
#n proceso puede in!ocar una operacin no bloqueante cuando el proceso puede
continuar sin esperar a que se complete el e!ento iniciado por la operacin. Por
ejemplo, la operacin recibir in!ocada por el na!egador 3eb debe esperar a la
respuesta del ser!idor para poder continuar con el procesamiento. Por el contrario, la
operacin enviar in!ocada por el ser!idor 3eb puede ser no bloqueante, porque el
ser!idor 3eb no necesita esperar a que la operacin se 5a.a completado antes de
proceder con la siguiente operacin (la operacin desconectar), de "orma que puede
continuar sir!iendo a otros procesos na!egadores.
%I*#+, &.=: %lujo de ejecucin de dos programas que inter!ienen en una
comunicacin entre procesos.
--
s responsabilidad del programador reconocer la necesidad de sincroni$acin . de
cundo una llamada es bloqueante. Por ejemplo, si se in!oca una operacin recibir no
bloqueante en el cdigo del na!egador 3eb, debido a un programador descuidado, se
asume que los datos se reciben inmediatamente despu6s de que se in!oque la
operacin, el procesamiento posterior puede mostrar datos que no sean !lidos o, peor
a)n, generar errores.
(ebido a que el uso de operaciones enviar . recibir es "undamental para los sistemas
distribuidos !amos a !er di"erentes escenarios en los cuales se usan di"erentes
combinaciones de estos modos.
Enviar sncrono y recibir sncrono
La %igura &.> es un diagrama, que a lo largo de este libro !amos a denominar
diagrama de eventos, que ilustra la sincroni$acin de los e!entos para una sesin de
un protocolo implementada por medio de una operacin enviar . una recibir
sncronas. n este escenario, la in!ocacin de la operacin recibir causa la suspensin
del proceso que la in!oca (proceso &) 5asta que se reciben los datos . se completa la
operacin. (e la misma "orma, la operacin en!iar in!ocada causa que el proceso
emisor (proceso ') se suspenda. Cuando se reciben los datos en!iados al proceso &, el
mecanismo de comunicacin entre procesos en el ordenador & en!a un asentimiento
al mecanismo de comunicacin anlogo del ordenador ', . el proceso ' puede
posteriormente desbloquearse. s necesario remarcar que el asentimiento se gestiona
por medio de los mecanismos de comunicacin de ambos ordenadores . que es
transparente para el proceso.
%I*#+, &.>: Enviar . recibir sncronos
l uso de un en!iar sncrono . un recibir sncrono es aconsejable cuando la lgica de
la aplicacin de ambos procesos necesita que los datos en!iados se reciban antes de
continuar con el procesamiento.
(ependiendo de la implementacin de las "uncionalidades de comunicacin entre
procesos, la operacin recibir sncrona puede no completarse 5asta que la cantidad de
datos esperada por el receptor 5a.a llegado. Por ejemplo, si el proceso & in!oca una
operacin de recibir para ;?? b.tes de datos, . la operacin en!iar slo transmite &??
b.tes, es posible que el bloqueo del proceso & contin)e incluso despu6s de 5aberse
entregado los primeros &?? b.tes7 en este caso, el proceso & no se desbloquear 5asta
que el proceso ' transmita posteriormente los '?? b.tes de datos restantes.
Enviar asncrono y recibir sncrono
n la %igura &./ se ilustra un diagrama de e!entos para una sesin de protocolo
implementada usando una operacin de enviar asncrona . una operacin de recibir
sncrona. Como antes, la operacin recibir bloquea al proceso que la in!oca 5asta que
lleguen datos para completar la operacin. 4in embargo, la operacin enviar in!ocada
no !a a causar que el proceso emisor se suspenda. n este caso, como el proceso
emisor no se bloquea no resulta necesario un asentimiento por parte del mecanismo de
comunicacin en el ordenador del proceso &. ste uso de una operacin de enviar
asncrona . una de recibir sncrona es apropiado cuando la lgica de la aplicacin
emisora no depende de la recepcin de los datos por parte del otro e9tremo. 4in
embargo, dependiendo de la implementacin del mecanismo de comunicacin, no se
garanti$a que los datos en!iados, realmente sean entregados al receptor. Por ejemplo,
si la operacin enviar es ejecutada antes de que la correspondiente de recibir sea
in!ocada en el otro e9tremo, es posible que los datos no se entreguen al proceso
receptor, a menos que el mecanismo de comunicacin proporcione espacio para
almacenar datos en!iados de "orma prematura.
%I*#+, &./: Enviar asncrono . recibir sncrono
Enviar sncrono y recibir asncrono
La %igura &.@ ilustra los di"erentes escenarios de un protocolo de sesin que emplee
operaciones de enviar sncrono . de recibir asncrono.
#na operacin de recibir asncrono causa que el proceso que la in!oca no se bloquee,
. el comportamiento depender muc5o de cmo se encuentre implementado el
mecanismo de comunicacin. La operacin recibir, en todos los casos, retornar
inmediatamente, e9istiendo tres posibles escenarios de qu6 ocurrira a continuacin:
Escenario 1. Los datos solicitados por la operacin del receptor .a 5an llegado
en el momento que la operacin recibir se in!oca. n este caso los datos se
entregan al proceso & inmediatamente, . el proceso ' se desbloquear por
medio de un asentamiento transmitido por el mecanismo de comunicacin del
ordenador &.
Escenario 2. Los datos solicitados por la operacin recibir no 5an llegado
toda!a7 el proceso receptor no recoge ning)n dato. s responsabilidad del
proceso receptor cerciorarse de que los datos se 5an recibido, si es necesario,
repetir el proceso 5asta que los datos 5a.an llegado. (0tese que es com)n que
el programa utilice un bucle para in!ocar a la operacin recibir repetidas !eces
5asta que el dato esperado llegue. ste t6cnica de repetir intentos se denomina
muestreo (en ingl6s polling)). l proceso ' se queda bloqueado de "orma
inde"inida 5asta que el proceso & !uel!e a in!ocar a recibir . el asentimiento
"inalmente le llega por parte del mecanismo de comunicacin del ordenador &.
Escenario 3. Los datos solicitados por la operacin recibir no 5an llegado a)n.
l mecanismo de comunicacin del ordenador & noti"icar a dic5o proceso
cuando los datos solicitados 5a.an llegado, en dic5o instante el proceso &
puede pasar a procesarlos. ste escenario requiere que el proceso &
proporcione un manejador de e!ento que puede in!ocarse por parte del
mecanismo de comunicacin para noti"icar al proceso que los datos esperados
5an llegado.
%I*#+, &.@: Enviar sncrono . recibir asncrono
Enviar asncrono y recibir asncrono
4in ning)n bloqueo en cualquiera de los dos lados, la )nica "orma en que los datos
puede entregarse al receptor es que el mecanismo de comunicacin pueda almacenar
los datos recibidos. l proceso receptor puede ser noti"icado de la llegada de los datos
(!6ase la %igura &.A). Btra alternati!a es, que el proceso receptor 5aga muestreo en
busca de la llegada de datos, para su posterior procesamiento.
%I*#+, &.A: Enviar asncrono . recibir asncrono
Temporizadores e hilos de ejecucin
,unque el bloqueo proporciona la sincroni$acin necesaria para los mecanismos de
comunicacin, es por lo general inaceptable que un proceso se quede suspendido de
"orma inde"inida. 9isten dos medidas para solucionar este problema. La primera es el
uso de temporizadores (timeouts), que se pueden utili$ar para "ijar el tiempo m9imo
de bloqueo. Los tempori$adores los proporciona el propio mecanismo de
comunicacin . pueden ser "ijados desde el programa por medio de una operacin. n
segundo lugar, un proceso puede lan$ar otro proceso "i#o o un "ilo de e#ecucin
(thread) independiente para in!ocar la operacin bloqueante, permitiendo de este
manera al 5ilo de ejecucin principal o al proceso padre del programa seguir
ejecutando otras tareas de procesamiento mientras el 5ilo de ejecucin o proceso 5ijo
se suspende. La %igura &.C ilustra este uso de los 5ilos de ejecucin.
Los tempori$adores son importantes si la ejecucin de operaciones sncronas puede
potencialmente dar como resultado un bloueo indefinido. Por ejemplo, una
operacin bloqueante de conectar puede causar que el proceso que la solicita se quede
suspendido de "orma inde"inida si la cone9in no est establecida . no se puede
establecer debido a una cada en la red de intercone9in entre ambos ordenadores. n
esta situacin, es tpicamente inaceptable para el proceso solicitante quedarse
DcolgadoE de "orma inde"inida. Los bloqueos inde"inidos pueden resol!erse usando
tempori$adores. Por ejemplo, se puede "ijar un tempori$ador de ;? segundos para la
operacin de conectar. 4i la peticin no se completa en apro9imadamente ;?
segundos, el mecanismo de comunicacin la abortar, en dic5o instante el proceso que
la solicit se desbloquear, pudiendo as continuar con su procesamiento.
%I*#+, &.C: #tili$acin de un 5ilo de ejecucin para una operacin bloqueante.
Interbloqueos y temporizadores
Btra causa para su"rir un bloqueo inde"inido son los interbloueos (deadlocs). n
comunicacin entre procesos, un interbloqueo puede causarse por una operacin
in!ocada de "orma no apropiada, qui$s por culpa de una mala interpretacin del
protocolo o por errores de programacin. La %igura &.'? muestra este caso. l proceso
' 5a in!ocado una operacin de recibir para recoger datos del proceso &. , la !e$, el
proceso & 5a in!ocado otro recibir bloqueante cuando debera ser una operacin de
enviar lo apropiado. Como resultado, ambos procesos se encuentran bloqueados a
esperas de datos del otro, cosa que nunca puede ocurrir (debido a que cada proceso se
encuentra bloqueado). n resumen, cada proceso por su parte se encontrar
suspendido inde"inidamente 5asta que salte un tempori$ador o 5asta que el sistema
operati!o aborte el proceso.
%I*#+, &.'?: #n interbloqueo causado por operaciones bloqueantes
Representacin de datos
n el ni!el "sico de una arquitectura de red (que es el ni!el ms bajo, en oposicin al
ni!el de aplicacin que es el ms alto), los datos se transmiten como seFales
analgicas, las cuales representan un flu#o binario. n el ni!el de aplicacin, se
necesita una representacin ms compleja de los datos transmitidos con el objeto de
dar soporte a la representacin de tipos de datos . estructuras proporcionadas por los
lenguajes de programacin, tales como cadenas de caracteres, enteros, !alores en
coma "lotante, !ectores, registros . objetos.
NOTA: Analgico es lo opuesto a digital: 5ace re"erencia a algo mecnico, en
oposicin a algo que representa datos. l procesamiento de seFales analgicas es un
rea de trabajo dentro de redes de computadores.
NOTA: #n flu#o binario es un "lujo de bits (? . '), tal como ??'?'...'?'?'''
4i consideramos el caso simple de dos procesos, proceso ' en el ordenador , .
proceso & en el ordenador G, que participan en un protocolo que implica el
intercambio de un !alor entero durante su ejecucin. l proceso ' calcula el !alor e
in!oca una operacin enviar para mandar el !alor al proceso &, el cual in!oca una
operacin recibir para recoger dic5o !alor, para que el proceso & realice las
correspondientes operaciones con dic5o !alor, todo de acuerdo al protocolo
establecido.
4i nos centramos en el !alor entero que el proceso ' tiene que en!iar. l !alor entero
se encuentra representado en el "ormato de representacin del ordenador ,, que es
una mquina de ;&-bits que utili$a representacin Dbig!endianE para tipos de datos de
!arios b.tes. (Los t6rminos big!endian . little!endian indican cul es el b.te ms
signi"icati!o en representaciones de !alores de !arios b.tes de tamaFo. n
arquitecturas de tipo big!endian, el b.te ms a la i$quierda Hel de menor direccinI es
el ms signi"icati!o. n arquitecturas, little!endian es el b.te ms a la derec5a el ms
signi"icati!o.)
l ordenador G, por su parte, es una mquina de '/-bits con representacin de datos
little!endian. 4upngase que el dato de ;& bits es transmitido directamente desde el
espacio de almacenamiento del proceso ' al espacio reser!ado por el proceso &.
ntonces (') '/ bits de los ;& en!iados !an a ser truncados .a que el tamaFo de un
entero en el ordenador G es de slo '/ bits . (&) el orden de los b.tes de la
representacin de los enteros debe ser intercambiado de "orma que se interprete
correctamente el mismo !alor por parte del proceso receptor.
Como se 5a !isto en el ejemplo, cuando ordenadores 5eterog6neos participan en una
comunicacin entre procesos, no basta con transmitir los !alores de los datos o las
estructuras usando "lujos de bits en crudo a menos que los procesos participantes
tomen las medidas oportunas para empaquetar e interpretar los datos de "orma
apropiada. Para nuestro ejemplo 5a. tres esquemas para 5acer esto:
NOTA: 4e denominan ordenadores 5eterog6neos a aquellos ordenadores que
disponen de di"erente 5ard3are . por tanto de di"erentes representaciones de datos.
'. ,ntes de in!ocar a la operacin enviar, el proceso ' con!ierte el !alor entero a
'/-bits en "ormato little!endian para el proceso &.
&. l proceso ' en!a los datos en ;&-bits . representacin big!endian. :ras
recibir los datos, el proceso & con!ierte el !alor a su "ormato, '/-bits . little!
endian.
;. #n tercer esquema es que los procesos cuando intercambien datos lo 5agan en
una representacin externa: los datos se !an a en!iar trans"ormados a esa
representacin . los datos recibidos se !an a interpretar con esa representacin
. se !an a traducir a la representacin nati!a.
:omando otro ejemplo, supongamos que el proceso ', ejecutndose en el ordenador
,, desea en!iar un simple carcter a al proceso &, ejecutndose en el ordenador G. l
programa para el proceso ' usa ,4CII como representacin de caracteres, mientras
que el programa del proceso & usa #nicode. l esquema ' obligar al proceso ' a
con!ertir el carcter a a #nicode antes de en!iarlo. l esquema & requerir que el
proceso & reciba el dato, . lo con!ierta de ,4CII a la representacin #nicode
correspondiente. l esquema ; e9igir que ambos e9tremos se pongan de acuerdo en
una representacin e9terna, digamos ,40.' ("bstract #yntax $otation $umber 1), de
"orma que el proceso ' con!ierta el carcter a a ,40.' antes de mandarlo, . el
proceso & con!ierta el dato recibido de ,40.' a la representacin #nicode. (La
representacin ,40.' se e9plicar en la 4eccin &./.)
NOTA: A$C%% son las siglas de "merican #tandard %ode for &nformation
&nterchange (Cdigo estndar americano para intercambio de in"ormacin), . es un
esquema de codi"icacin usado para caracteres del al"abeto ingl6s usando un rango de
!alores de ? a '&@.
NOTA: &nicode es un esquema de codi"icacin complejo que permite traducir
caracteres, no slo del al"abeto ingl6s, a !alores num6ricos entre ? . />>;>. Para una
de"inicin ms precisa, !6ase 5ttp:JJ333.unicode.org.
4i se considera otro caso ms cuando se transmite una estructura de datos, como por
ejemplo una lista de !alores, adems de lo necesario de representacin e9terna de los
!alores de datos, e9iste en este caso la necesidad de DaplanarE o seriali$ar la estructura
de datos en el e9tremo del emisor . des5acer el cambio en el otro e9tremo, para as
reconstruir los datos.
l t6rmino de empauetamiento de datos (data marshaling) se usa en el conte9to de
los mecanismos de comunicacin entre procesos para re"erirse a las trans"ormaciones
necesarias para transmitir !alores de datos o estructuras. l empaquetamiento de datos
se necesita para todos los mecanismos de comunicacin e inclu.e los pasos necesarios
para acondicionar los datos a ser transmitidos: (') seriali$acin de las estructuras de
datos, . (&) con!ersin de los !alores de datos a las representaciones e9ternas. La
%igura &.'' muestra el concepto de empaquetamiento de datos.
Para aplicaciones de red escritas en lenguajes orientados a objetos como 8a!a, unas
estructuras de datos que requieren especial atencin en lo re"erente al
empaquetamiento de datos son los propios objetos. , di"erencia de estructuras de
daos estticas como !ectores o registros, un objeto encapsula tanto datos
(representando el estado del objeto), como m6todos (representando el comportamiento
del objeto). 4i se !a a transmitir un objeto usando un mecanismo de comunicacin
entre procesos es necesario que el proceso de empaquetamiento (de nue!o aplanado .
codi"icacin) cubra tanto a los datos como a la representacin de m6todos K
inclu.endo el estado de ejecucin- de "orma que el objeto una !e$ desempaquetado
por el proceso receptor pueda "uncionar como un objeto ejecutando en el espacio de
dic5o proceso. (ebido a la complejidad e9istente, el empaquetado de objetos implica
un ma.or reto que el del resto de estructuras, se le 5a dado un nombre espec"ico:
serializacin de ob#etos Hja!a.sun.com, ''I. n 8a!a, DLa seriali$acin de objetos
soporta la codi"icacin de objetos, . de los objetos alcan$ables desde ellos, en un "lujo
de b.tes, as como el soporte complementario para su reconstruccin en un objeto ...
desde el "lujo de b.tesE H<arold,'&I.
odificacin de datos
,unque determinados programas especiali$ados puedan escribirse para reali$ar la
comunicacin entre procesos usando un esquema de representacin determinado de
mutuo acuerdo, las aplicaciones distribuidas de propsito general necesitan un
esquema uni!ersal, e independiente de plata"orma, para codi"icar el intercambio de
datos. Por esto se 5an de"inido estndares de red para la codi"icacin de datos.
%I*#+, &.'': mpaquetamiento de datos
Como se muestra en la %igura &.'&, 5a. estndares para la codi"icacin de datos
disponibles a di"erentes ni!eles de abstraccin.
,l ni!el ms simple, un esquema de codi"icacin como 'DR (External 'ata
(epresentation) Hiet".org, 'I permite que un conjunto de tipos de datos determinado .
unas estructuras espec"icas se puedan codi"icar para usarse con mecanismos de
comunicacin entre procesos. l empaquetamiento . desempaquetamiento de datos se
reali$an automticamente por las "uncionalidades de comunicacin entre procesos en
los dos e9tremos, de "orma transparente al programador.
, un ni!el de abstraccin ms alto (esto es, ocultando ms detalles7 se entrar en este
concepto con ms detalle en el pr9imo captulo), e9isten estndares como A$N()
("bstract #yntax $otation $umber 1) Hoss.com, &I. ,40.' es un estndar de B4I
()pen #ystems &nterconnection) que especi"ica la sinta9is de trans"erencia para datos
sobre una red. l estndar cubre un amplio rango de estructuras (como conjuntos .
secuencias) . tipos de datos (enteros, boolenos . caracteres) . soporta el concepto de
etiquetado de datos. Cada elemento de datos transmitido se codi"ica usando una
sinta9is que indica el tipo, la longitud, el !alor . opcionalmente una etiqueta que
identi"ica una "orma espec"ica de interpretar esta sinta9is.
, un ni!el a)n ms alto de abstraccin 5a emergido '*+ (Extensible *arup
+anguage) H3;.org, CI como lenguaje de descripcin de datos entre aplicaciones que
comparten in"ormacin, principalmente aplicaciones en Internet, usando una sinta9is
similar a <:LL (HyperText *arup +anguage), que es el lenguaje usado para
componer pginas 3eb. 1LL !a un poco ms all que ,40.' en el sentido que
permite al usuario usar etiquetas con"igurables (tales como ,mensa-e., ,de. o
,para. en el ejemplo de la %igura &.';) para especi"icar una unidad de contenido de
datos. 1LL se utili$a para "acilitar intercambio de datos entre sistemas 5eterog6neos,
para separar el contenido de una pgina 3eb (escrito en 1LL) de la sinta9is para
mostrarlo (escrita en <:LL), . para permitir que los datos se compartan entre
aplicaciones. (esde su aparicin en 'CCA, 1LL 5a ganado una atencin considerable
. en la actualidad se utili$a en un amplio rango de aplicaciones.
%I*#+, &.'&: stndares de representacin de datos de red
%I*#+, &.';: #n "ic5ero 1LL de ejemplo
<mensaje>
<a>MaryJ@BigU.edu</a>
<de>JohnL@OpenU.edu</de>
<sobre>Comunicacin entre procesos</sobre>
<texto> La espina dorsal de los sistemas distribuidos son los ... </texto>
</mensaje>
!rotocolos basados en te"to
l empaquetamiento de datos es, en el caso ms simple, cuando se intercambian
cadenas de caracteres o te9to codi"icado en una representacin de tipo ,4CII. l
intercambio de datos en te9to tiene la !entaja adicional de que puede ser "cilmente
anali$ado por un programa . mostrado a un usuario 5umano. Por eso es relati!amente
5abitual en !arios protocolos intercambiar peticiones . respuestas en "orma de
cadenas de caracteres. stos protocolos se denominan basados en texto. Luc5os
protocolos 5abituales son basados en te9to, inclu.endo %:P (/ile Transfer Protocol,
protocolo de trans"erencia de "ic5eros), <::P . 4L:P (#imple *ail Transfer
Protocol, protocolo simple de trans"erencia de correo). l lector tendr la oportunidad
de in!estigar . e9perimentar con estos protocolos en ejercicios al "inal de este
captulo, . se estudiarn !arios de estos protocolos en detalle en posteriores captulos.
!rotocolos de solicitud#respuesta
#n tipo importante de protocolos son los protocolos de solicitud-respuesta. n estos
protocolos un lado in!oca una peticin . espera una respuesta del otro e9tremo.
Posteriormente, puede ser en!iada otra solicitud, esperndose de nue!o respuesta. l
protocolo se desarrolla basndose en interacciones de este tipo 5asta que la tarea
solicitada se 5a cumplido. %:P, 5ttp . 4L:P son protocolos 5abituales del tipo
solicitud-respuesta.
$iagrama de eventos y diagrama de secuencia
#n diagrama de e!entos, .a presentado en la seccin &.&, es un diagrama que se puede
utili$ar para documentar la secuencia detallada de e!entos . bloqueos durante la
ejecucin de un protocolo. La %igura &.'= es un diagrama de e!entos para un
protocolo solicitud-respuesta en el que participan dos procesos concurrentes, , . G.
La ejecucin de cada proceso respecto del tiempo se representa usando una lnea
!ertical, que a!an$a 5acia abajo. #n inter!alo de lnea continua durante la lnea de
ejecucin representa un periodo de tiempo en el cual el proceso estaba acti!o. #n
inter!alo de lnea discontinua representa cundo el proceso est bloqueado. n el
ejemplo, ambos procesos estn inicialmente acti!os. l proceso G in!oca un recibir
bloqueante con antelacin a la solicitud ' del proceso ,. l proceso , mientras tanto
lan$a la solicitud ' que se estaba esperando, usando para ello un enviar no bloqueante
. acto seguido un recibir bloqueante a la espera de la respuesta de G. La llegada de la
solicitud ' reacti!a al proceso G que inicia el procesamiento de la solicitud antes de
in!ocar una operacin de enviar con respuesta ' para el proceso ,. l proceso G
in!oca luego un recibir bloqueante para la solicitud &. La llegada de la respuesta '
desbloquea al proceso ,, que reanuda su ejecucin para trabajar con la respuesta .
preparar la peticin &, que desbloquea al proceso G. #na secuencia similar de e!entos
se sigue.
%I*#+, &.'=: #n diagrama de e!entos
Cabe resaltar que cada turno de solicitud-respuesta enla$a una pareja de operaciones
enviar . recibir para intercambiar dos mensajes. l protocolo se puede e9tender 5asta
cualquier n)mero de turnos de intercambios con este patrn.
:ambi6n es necesario indicar que es esencial que los programas que implementan el
protocolo deben estar escritos para in!ocar las operaciones de enviar . recibir en el
orden preestablecido, de otra "orma uno o los dos procesos participantes puede
quedarse esperando por una solicitud o una respuesta que nunca llega . los procesos
pueden quedarse bloqueados de "orma inde"inida.
La %igura &.'> presenta, por medio de un diagrama de e!entos un protocolo <::P.
n su "orma ms bsica, <::P es un protocolo basado en te9to del tipo peticin-
respuesta que utili$a slo un turno de intercambio de mensajes. #n ser!idor 2eb es
un proceso que escuc5a constantemente peticiones reali$adas desde procesos
0a!egadores. #n 0a!egador 3eb establece una cone9in con el ser!idor, tras ello
in!oca una peticin en el "ormato dictado por el protocolo. l ser!idor procesa la
peticin . responde con una lnea de estado, una cabecera de in"ormacin . el
documento solicitado por el na!egador. :ras recibir la respuesta, el na!egador anali$a
el documento . lo presenta en pantalla. (4e estudiar el modelo cliente-ser!idor . el
protocolo <::P con ms detalle en el Captulo >.)
%I*#+, &.'>: (iagrama de e!entos de una sesin <::P.
#n diagrama de e!entos es una 5erramienta mu. )til para ilustrar la sincroni$acin
entre e!entos. Pero es, sin embargo, demasiado detallado para documentar protocolos
que sean complejos. #na "orma simpli"icada de este diagrama, denominada diagrama
de secuencia . parte de la notacin #LL, se usa ms 5abitualmente para denotar la
comunicacin entre procesos.
n un diagrama de secuencia, el "lujo de ejecucin de cada participante del protocolo
se representa por una lnea discontinua . no se di"erencia entre estados de bloqueo .
ejecucin. Cada mensaje intercambiado entre dos elementos se representa con una
lnea dirigida que !a entre las dos lneas discontinuas de emisor . receptor sobre la
que se aFade una etiqueta descripti!a del mensaje, tal . como se ilustra en la "igura
&.'/.
l diagrama de secuencia de una sesin <::P bsica se muestra en la "igura &.'@.
%I*#+, &.'/: #n diagrama de secuencia
%I*#+, &.'@: l diagrama de secuencia para una sesin <::P.
La "igura &.'A muestra el te9to de los mensajes intercambiados durante una sesin
<::P de ejemplo. Por medio de un cliente telnet (telnet es un protocolo utili$ado
normalmente para una sesin de terminal sobre una mquina remota), se puede
conectar a un ser!idor 3eb e introducir el te9to de una peticin <::P a mano. (La
utili$acin de telnet para comunicarse con un proceso de la "orma aqu indicada
permite 5acer pruebas con procesos !a IPC sin necesidad de escribir el programa,
pero es necesario a!isar de que 6sta no es la "orma normal de interactuar con estos
procesos. n los siguientes captulos se aprender a programar estas interacciones.)
n este caso, el ser!idor 3eb se ejecuta sobre el puerto A? de la mquina
333.csc.calpol..edu. La peticin *: JMmliuJ <::PJ'.? se teclea . en!a. La
respuesta del ser!idor 3eb se remite a continuacin. n el captulo C se estudiar el
signi"icado de las peticiones . respuestas cuando se e9ponga el protocolo <::P en
detalle.
%I*#+, &.'A: l dilogo durante una sesin <::P.
omunicacin entre procesos orientada y no orientada a
cone"in
n el captulo ' se introdujo la distincin entre comunicaciones orientadas . no
orientadas a cone9in. Namos a aplicar esta distincin a los mecanismos de IPC.
Por medio de un mecanismo de IPC orientado a cone9in, dos procesos establecen
una cone9in (la cual, como recordatorio, decamos que poda ser lgica-es decir,
implementada por so"t3are- en lugar de !erdaderamente "sica), . posteriormente
insertan datos en o e9traen datos desde dic5a cone9in. #na !e$ que la cone9in est
establecida, no es necesaria la identi"icacin de emisor . receptor.
Para el caso de una IPC no orientada a cone9in, los datos son intercambiados por
medio de paquetes independientes cada uno de los cuales necesita e9plcitamente la
direccin del receptor.
Cuando se estudie el ,PI de socOets en el captulo =, se !er cmo los mecanismos de
IPC orientados . no orientados a cone9in se proporcionan al ni!el de aplicacin.
Evolucin de los paradigmas de comunicacin entre
procesos
#na !e$ e9puesto el concepto de comunicaciones entre procesos (IPC), !eremos
di"erentes modelos, o paradigmas, por medio de los cuales la comunicacin entre
procesos se proporciona al programador que quiere utili$ar una IPC en su programa.
,l comien$o de este captulo se !io que los esquemas de codi"icacin de datos se dan
a di"erentes ni!eles de abstraccin. Lo mismo se puede decir de los paradigmas de
comunicacin entre procesos, tal . como muestra la %igura &.'C.
n el ni!el menos abstracto, la comunicacin entre procesos implica la transmisin de
ristras binarias sobre una cone9in, utili$ando una trans"erencia de datos de bajo
ni!el, serie o paralelo. ste paradigma de comunicacin entre procesos puede ser
!lido para el desarrollo del so"t3are de un driver de red, por ejemplo. #na IPC de
esta "orma cae dentro del dominio de programacin de red o de sistema operati!o . no
lo !a a cubrir este libro.
NOTA: Transferencia de datos serie se re"iere a la transmisin de datos bit a bit. Lo
opuesto a transferencia de datos serie es transferencia de datos en paralelo, en la
cual !arios bits se transmiten concurrentemente.
l siguiente ni!el es un paradigma bien conocido, denominado inter"a$ de
programacin de aplicaciones de soc,ets (el A-% de soc,ets). Por medio del
paradigma de socOets, dos procesos intercambian datos por medio de una estructura
lgica denominada soc,et, 5abiendo uno de cada tipo en cada e9tremo. Los datos a
transmitir se escriben sobre el socOet. n el otro e9tremo, un receptor lee o e9trae
datos del socOet. 4e estudiar el ,PI de socOets del lenguaje 8a!a en el pr9imo
captulo.
0B:,: 4ocOet es un termino tomado de los primeros das de las comunicaciones
tele"nicas, cuando un operador tena que establecer manualmente una cone9in entre
dos partes insertando los dos e9tremos de un cable en sendos socOets
'
.
Los paradigmas de llamadas a procedimientos remotos o de invocacin de
m.todos remotos proporcionan una ma.or abstraccin, permitiendo al proceso
reali$ar llamadas a procedimientos o la in!ocacin de m6todos de un proceso remoto,
con la transmisin de datos como argumentos o !alores de resultado. 4e estudiar una
implementacin de este paradigma, la in!ocacin de m6todos remotos en 8a!a, en el
Captulo A.
%I*#+, &.'C: Paradigmas de comunicacin entre procesos
Resumen
La comunicacin entre procesos (IPC) con"orma el eje central de la computacin
distribuida. n este captulo se 5an !isto los principios de los mecanismos de IPC,
inclu.endo lo siguiente:
Comunicacin entre procesos (IPC): La posibilidad de que procesos
independientes, . separados se comuniquen entre ellos para colaborar en una
tarea. Cuando una comunicacin se reali$a )nicamente de un proceso a otro, el
mecanismo IPC se denomina unidi"usin. Cuando la comunicacin se reali$a
entre un proceso . un grupo de procesos, el mecanismo IPC es multidi"usin.
#na ,PI bsica de "uncionalidades para IPC debe proporcionar:
'
(0. del :. 4ocOet en ingl6s signi"ica enc5u"e)
o Primiti!as de operacin: en!iar, recibir, conectarse, . desconectarse.
o La sincroni$acin de e!entos permite que procesos relacionados se
ejecuten independientemente, sin conocimiento de lo que ocurre en el
otro e9tremo. La "orma ms sencilla para que un mecanismo de
comunicacin permita sincroni$acin es por medio de bloqueos. Las
operaciones que son bloqueantes se denominan a menudo operaciones
sncronas, mientras que las que no son bloqueantes se llaman tambi6n
operaciones asncronas. Los interbloqueos pueden aparecer debido al
uso de operaciones bloqueantes. La utili$acin de 5ilos de ejecucin
(threads) o procesos permiten la reali$acin de otras tareas a un
proceso que a)n espera que una operacin bloqueante se complete.
o l empaquetamiento de datos (data marshaling) necesario para
preparar los datos para su transmisin por red, est compuesto por los
siguientes pasos: (i) seriali$acin de las estructuras de datos, . (ii)
con!ersin de los !alores de datos a una representacin e9terna o de
red.
9isten di"erentes esquemas de representacin de datos de red a di"erentes
ni!eles de abstraccin. ,lgunos de los ms conocidos son 4un 1(+(External
'ata (epresentation), ,40.' ("bstract #yntax $otation $umber 1) and 1LL
(Extensible *arup +anguage).
l empaquetamiento de datos es ms sencillo cuando los datos a transmitir son
una secuencia de caracteres o te9to representado por medio de una
codi"icacin de tipo ,4CII. Los protocolos que utili$an te9to se denominan
protocolos basados en te9to.
Los protocolo del tipo solicitud-respuesta son protocolos que en!an
iterati!amente mensajes de solicitud . de respuesta 5asta que se completen las
tareas.
#n diagrama de e!entos se utili$a para documentar la secuencia detallada de
e!entos . bloqueos en un protocolo. #n segmento continuo a lo largo de la
lnea de ejecucin representa el periodo de tiempo durante el cual el proceso
est acti!o. #na lnea discontinua representa que el proceso est bloqueado.
#n diagrama de secuencia es parte de la notacin #LL . se utili$a para
documentar iteraciones entre procesos que son complejas. n un diagrama de
secuencia, el "lujo de ejecucin de cada participante del protocolo se
representa por una lnea discontinua . no se di"erencia entre estados de
bloqueo . ejecucin.
Las "uncionalidades de comunicacin entre procesos pueden ser orientadas o
no orientadas a cone9in:
o Por medio de los mecanismos orientados a cone9in, dos procesos
establecen una cone9in lgica, para posteriormente intercambiar datos
insertndolos . e9tra.6ndolos de la cone9in. #na !e$ que la cone9in
se 5a establecido no es necesario identi"icar a emisor . receptor.
o n el caso de mecanismos no orientados a la cone9in, los datos se
intercambian por medio de paquetes independientes, cada uno de los
cuales necesita identi"icar al receptor.
Las "uncionalidades de tipo IPC pueden clasi"icarse de acuerdo a sus ni!eles
de abstraccin, .endo desde trans"erencia de datos serieJparalelo, al ni!el ms
bajo, pasando por el ,PI de socOets al siguiente ni!el, 5asta llamadas a
procedimientos o m6todos remotos, al ni!el ms alto.
Ejercicios
'. :eniendo en cuenta el caso de la comunicacin entre 5umanos:
a. Clasi"ique cada uno de los siguientes escenarios en t6rminos de
unidifusin o multidifusin:
i. #n estudiante 5ablando con un amigo por medio de un tel6"ono
inalmbrico.
ii. #n ejecuti!o 5ablando !a con"erencia con empresarios en
!arias ciudades.
iii. #n pro"esor dando clase en un aula.
i!. #n niFo jugando con otro usando un D0alie!talieE.
!. #n presidente dirigi6ndose a la nacin en tele!isin.
b. PCmo se reali$a la sincroni$acin de e!entos . la representacin de
datos durante una sesin de una con!ersacin cara a cara, como cuando
se 5abla con alguien sentado a su ladoQ
c. PCmo se reali$a la sincroni$acin de e!entos . la representacin de
datos durante una sesin de con!ersacin a distancia, como cuando se
5abla con alguien por tel6"onoQ
d. PCmo se reali$a la sincroni$acin de e!entos . la representacin de
datos durante una reunin entre dos representantes de dos naciones que
5ablan idiomas di"erentesQ
&. l proceso , manda un mensaje sencillo al proceso G usando una llamada IPC
no orientada a cone9in. Para 5acerlo, , in!oca una operacin enviar
(especi"icando un mensaje como argumento) en alg)n instante durante su
ejecucin, . G in!oca una operacin recibir. 4uponga que la operacin enviar
es asncrona (no bloqueante) . la operacin de recibir es sncrona
(bloqueante). (ibuje un diagrama de e!entos (no un diagrama de secuencia)
para cada uno de los siguientes escenarios.
a. l proceso , in!oca la operacin enviar antes de que el proceso G
in!oque la operacin recibir.
b. l proceso G in!oca la operacin recibir antes de que el proceso ,
in!oque la operacin enviar.
;. +epita la )ltima pregunta. sta !e$ ambas operaciones (enviar . recibir) son
bloqueantes.
=. Considere el ,PI de comunicacin entre procesos siguiente:
sta ,PI en!a . recibe los mensajes de bu$ones. #n proceso puede
comunicarse con otro proceso usando un bu$n compartido por esos dos
procesos. Por ejemplo, si el proceso , desea comunicarse con los procesos G .
C, debe compartir el bu$n ' con el proceso G, . otro bu$n, el bu$n &, con
C. Los mensajes entre , . G se depositan . recogen del bu$n ', mientras que
los mensajes entre , . C se depositan . recogen del bu$n &. Bbs6r!ese la
%igura &.&?.
Las operaciones enviar . recibir se de"inen como:
en!iar(n, mensaje): n!a un mensaje al bu$n n, bloqueante (es decir, que
el emisor quedar suspendido 5asta que llegue una respuesta al bu$n
compartido)
recibir(n, mensaje): 9amina el bu$n n con antelacin a la recepcin de
un mensaje7 es tambi6n una operacin bloqueante, que signi"ica que el
proceso receptor quedar suspendido 5asta que llegue un mensaje al citado
bu$n.
#n proceso que se encuentre bloqueado a la espera de un mensaje en un
determinado bu$n no podr recibir ning)n mensaje por otro bu$n.
a. 4uponga que un proceso P espera recibir dos mensajes, uno por el
bu$n ' . otro por el bu$n &. 0o se conoce a priori ni el instante ni el
orden en el que !an a llegar los mensajes. PRu6 secuencia de enviar .
recibir, si e9iste, se puede ejecutar para asegurarse que el proceso P no
se bloquea permanentementeQ
b. PRu6 secuencia de enviar . recibir, si e9iste, debe ejecutar el proceso
P si quiere esperar por un solo mensaje bien por el bu$n ' o por el
bu$n & (o incluso) por ambosQ (e nue!o, no se conoce por adelantado
qu6 mensaje llegar primero. ,simismo, la secuencia propuesta no
debe causar un bloqueo inde"inido.
($ota: 4u respuesta debe utili$ar )nicamente las operaciones dadas en el
captulo7 no utilice 5ilos (threading) u otras "uncionalidades del sistema
operati!o).
%I*#+, &.&?: #na inter"a$ de programacin de aplicaciones IPC para el
jercicio =.
>. P4e puede dar un interbloqueo durante la comunicacin entre procesos
(utili$ando enviarJrecibir)
a. en un sistema de comunicaciones que proporciona una operacin de
enviar bloqueante . de recibir bloqueanteQ
b. en un sistema de comunicaciones que proporciona una operacin de
enviar no bloqueante . de recibir bloqueanteQ
8usti"ique su respuesta. 4i la respuesta es a"irmati!a, proporcione un ejemplo.
4i la respuesta es negati!a, d6 una bre!e argumentacin.
/. Considere el desarrollo de una ,PI de multidi"usin sobre una ,PI e9istente
de tipo unidi"usin. l ,PI de unidi"usin proporciona operaciones enviar .
recibir entre dos procesos. l ,PI de multidi"usin debe proporcionar
operaciones para (') en!iar a un grupo de procesos, . (&) recibir de un proceso
de multidi"usin. (escriba cmo proporcionara las operaciones de
multidi"usin usando las operaciones de unidi"usin )nicamente. ($ota: 4u
respuesta debe utili$ar )nicamente las operaciones dadas en el captulo7 no
utilice 5ilos (threading) u otras "uncionalidades del sistema operati!o).
@. n un sistema distribuido, tres procesos P1, P2, . P3 participan en una
comunicacin entre procesos. 4uponga que sucede la siguiente secuencia de
e!entos:
n el instante ', P3 in!oca un recibir para P2.
n el instante &, P1 env1a el mensaje m1 5acia P2.
n el instante ;, P2 in!oca un recibir para P1.
n el instante =, P2 recibe el mensaje m1.
n el instante >, P2 env1a el mensaje m1 5acia P3.
n el instante /, P3 recibe el mensaje m1. P1 in!oca un recibir para P2.
n el instante @, P2 in!oca un recibir para P3.
n el instante A, P3 env1a el mensaje m2 5acia P2.
n el instante C, P2 recibe el mensaje m2.
n el instante '?, P2 env1a el mensaje m2 5acia P1.
n el instante '', P1 recibe el mensaje m2.
a. Para cada uno de los siguientes escenarios, dibuje un diagrama de
e!entos para mostrar la secuencia de e!entos . los bloqueos .
desbloqueos de cada proceso:
i. en un sistema de comunicaciones que proporciona una
operacin de enviar bloqueante . de recibir bloqueante,
ii. en un sistema de comunicaciones que proporciona una
operacin de enviar no bloqueante . de recibir bloqueante.
b. (ibuje un diagrama de secuencia para documentar la comunicacin
entre los procesos P1, P2, . P3.
A. ste es un ejercicio sobre empaquetamiento de datos (data marshaling).
a. n el conte9to de IPC:
i. PRu6 es el empaquetamiento de datosQ <a. dos pasos dentro
del empaquetamiento de datos, nmbrelos . describa cada uno.
PPor qu6 es necesario el empaquetamiento de datosQ
ii. PRu6 es la seriali$acin de objetosQ
iii. PCmo se aplican los dos pasos del empaquetamiento de datos
a (i) un !ector de enteros, . (ii) un objetoQ (escriba en
t6rminos generales qu6 es necesario reali$ar con los datos.
b. l proceso , en!a al proceso G un )nico dato, una "ec5a. l proceso
, usa el "ormato americano de "ec5a: ,mes.2,d1a.2,a3o. (por
ejemplo, ?'J;'J&??'). l proceso G usa el "ormato europeo:
,d1a.2,mes .2,a3o. (por ejemplo, ;'J?'J&??').
i. 4uponga que no se 5a acordado una representacin e9terna de
datos.
a. PCmo , en!iara la "ec5a a G para que , no
necesite 5acer ninguna con!ersinQ
b. PCmo , en!iara la "ec5a a G para que G no
necesite 5acer ninguna con!ersinQ
ii. 4uponga que la misma "ec5a se comunica al proceso C, que
utili$a un "ormato de "ec5a del tipo: ,a3o.!,mes.!,d1a. (por
ejemplo, &??'-;'-?'). PCmo puede , en!iar la "ec5a a G . C
a la !e$ de "orma que , no tenga que reali$ar con!ersin
algunaQ
iii. (escriba una representacin e9terna de datos para la "ec5a de
"orma que cualquier proceso emisor con!ierta la "ec5a del
"ormato de representacin local al "ormato de representacin
e9terno antes de en!iarla, . que cualquier proceso receptor
con!ierta la "ec5a recibida del "ormato de representacin
e9terno al su.o propio.
Puede resultarle de inter6s la consulta de la re"erencia Hsaqqara.demon.co.uO,
'?I.
C. #tilice telnet para interactuar con un ser!idor 'aytime H+%C A/@, =I sobre una
mquina a la que tenga acceso. Los ser!idores 'aytime escuc5an el puerto ';.
(esde una !entana de consola sobre el smbolo de sistema tecl6e:
telnet <espacio> <nombre o direccin ! de la m"#uina><espacio> $%
jemplo: telnet ma#uina.uni&ersidad.edu $%
+ecopile una tra$a de la sesin . describa sus obser!aciones.
'?. (ibuje un diagrama de secuencia para el protocolo 'aytime.
''. Ps posible para un cliente 'aytime que se quede bloqueado de "orma
inde"inidaQ 9plquelo.
'&. #tilice telnet para interactuar con un ser!idor echo H+%C A/&, /I sobre una
mquina a la que tenga acceso. Los ser!idores echo escuc5an el puerto @.
a. (ibuje un diagrama de e!entos para el protocolo echo.
b. Ps posible para un cliente 'aytime que se quede bloqueado de "orma
inde"inidaQ 9plquelo.
';. Considere el protocolo %:P (/ile Transfer Protocol-Protocolo de
:rans"erencia de %ic5eros) H+%C C>C, >I
0tese que este protocolo utili$a dos cone9iones: una para transmitir las
peticiones . respuestas . otro para transmitir los "ic5eros a ser
en!iadosJrecibidos.
a. #tilice telnet para conectarse a un ser!idor %:P al que tenga acceso.
Luego solicite un mandato para listar el contenido de directorio ra$ del
ser!idor.
b. #tilice un diagrama de e!entos para describir las interacciones entre
los procesos participantes.
c. PCul es el "ormato de cada peticinQ
d. PCul es el "ormato de cada respuestaQ
e. Considere el mandato LB( del protocolo: permite especi"icar el tipo
de "ic5ero (te9to o binario) a transmitir. PCul es la representacin de
datos para cada uno de los di"erentes modos de "ic5eroQ
'=. Considere el protocolo 4L:P (#imple *ail Transfer Protocol-Protocolo
4imple de :rans"erencia de Correo) H+%C A&', ;I. #n e9tracto de la +%C de
este protocolo proporciona la siguiente sesin de ejemplo:
R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
S: HE! "-U#I$.ARPA
R: 2%0 USC-ISI.ARPA
S: MAI &R!M:'m()"-U#I$.ARPA*
R: 2%0 !+
S: RCPT T!:',(nes)USC-ISI.ARPA*
R: !+
S: -ATA
R: .%/ S0ar0 mail inp102 end 3i04 'CR&*.'CR&*
S: "la 5la 5la...
S: ...e0c. e0c. e0c.
S: .
R: 2%0 !+
S: 6UIT
R: 227 USC-ISI.ARPA Service cl(sin8 0ransmissi(n c4annel
a. #tilice un diagrama de secuencia para describir las interacciones entre
los procesos participantes.
b. PCul es el "ormato de cada peticinQ
c. PCul es el "ormato de cada respuestaQ
d. #tilice telnet para conectarse a un sistema donde usted tenga una
cuenta 4L:P, . en!ese a s mismo un correo. Con6ctese luego al
sistema . !eri"ique que el correo 5a llegado.
+ecopile una tra$a de la sesin . describa sus obser!aciones.
Referencias
(Nota: Todos los RFC (Requests for Comments) se pueden consultar en lnea en la pgina: IETF RFC
Page, http://wwwiet!org/r!cht"l)
# RFC #$#%, E&ternal 'ata Representation
( )*+,# -.er.iew,/ http://www.oss.com/asn1/overview.html
0 RFC 1(#, +2TP
% RFC 134, Protocolo 'a5ti"e
6 RFC 767, Protocolo FTP
3 RFC 13(, Protocolo Echo
4 8ohn +haple5 9ra5 Interprocess Communications in UNIX :pper +addle Prentice ;all, #774
1 RFC 4%(, Finger protocol
7 E&tensi<le 2ar=up >anguage (?2>), http://www.w3.org/X!/
#$ International 'ate For"at Ca"paign, http://www.saqqara."emon.co.u#/
## 8a.a -<@ect +erialiAation, http://$ava.sun.com/$%se/1.3/"ocs/gui"e/seriali&ation/
#( Elliotte Rust5 ;arold 'ava I/(, +e<astopol, C*: -BReill5 Press, #777