1 - TESIUAMI

Transcripción

1 - TESIUAMI

PROYECTOS DE INVESTIGACION I Y I I
QUE PARA OBTENER EL TITUL8 DE:
blCENClADO EN COMWTAClON
PRESENTAN:
Asesor:
Martin
Garcia Nava
UNIVERSIDAD A U T ~ N O M A
METROPOLITANA.
UNIDAD IZTAPALAPA
2
DIVISIóN DE CIENCIAS BASICAS E INGENIERíA
E
LICENCIATURA EN COMPUTACIóN
DOCUMENTACIóN CORRESPONDIENTE A LOS PROYECTOS DE
INVESTIGACI~N
I Y 11
I
IMPLEMENTACIÓN DE UN SHELL REMOTO
f
Benito Cruz Mendoza
José Luis Méndez Montes
i
i
Asesor: Lic. Martin Garcia Nava!
L
1994-1995
ncdíco cl prcscntc trabajo a mis llarmulos que síemprc
cstuuícros apoyirrrlome írlcorrdícíorralrtlcrtr, así cotno
tarubífrl a nrí aradrc que estuvo c o m í g o a Io largo rlcl
trabajo, y ofrczco 1111 recorrorírnícrrto ospccíal a Brísclda por
s u írrualrrablc apoyo nloral que síruíó para corlcluír cl
trabajo; fírlalnlcrrte agradezco el apoyo recíbído por mí
asesor Martítt 6arría h a . '
IIURG2UCCI6N.
PROPUESTA CORFU3SPONDIENTE A
IITVESTIGACI~N
I Y
11 DE
C O M P U T A C I ~ N QUE PRESENTAN+
B e n i t o C r u z Mcndoza y
J o s é L u i s Méndez Montes.
ASESOR: L i c . M a r t i n Garcia Nava.
'LOS PROYECTOS
LICENCIATURA
EN
~ 3 . so b j e t l v o s
y metas d e l p r o y e c t o r s o n
PRIMER TRILGSTRE
Objetivos g e n e r a l e s :
C 5 j e t i v o s particulares :
los s i g u i e n t e s :
I
:r )
rlrj
S i sterna U N i X .
s e r i e d pe r o t o c o l o s
de comunicaciones
TCP\IE'.
Meta :
i n t e g r a r l o s c o n o c i m i e n t oasd q u i r i d o s
d e cada tema m e n c i o n a deon
l o s i n c i s o s b ) y c ) a n t e r i o r e s , como
un
sistema Ú n i c o , e l cu61 podrj
ser analizado
c u i d a d o s a m e n t ep, a r oa b t e n e irn f e r e n c i a qs u fea c i l i t e n
e n l o p o s t e r i o r e l d e s a r r o l l o e implernentación reales del s h e l l
remoto.
S E G U N D O TRIMESTRE
Objetivos p a r t i c u l a r e s :
a)
D e s a r r o l lt ae ró r i c a m e n t e
implementar.
el
modelo
de
el
s hreel il n o t o
1
2
Meta :
Adquirir l a h a b i l i d a d y e : < p e r i e n c iqau e
desarrollar e
Computación.
i m p l e m e n tud
a nre t e r m i n a d
p or o y e cet n
o
se
reyuiert=ri
p a ~ a lograr
el Area d e
3.E l t e n earc c e s o
t r e s v e n t a j a s b á s i c , I;:
i )
u nraeddceo m p u t a d o r alsl e vian y d í c i t a s
a
Compartir r e c u r s o s .
ii) Aurnentar l a f i a b i l i d a d d e l s i s t e m a .
i i i ) A h o r r oe c o n 6 m i c o .
Creernos q u e l a e x p e r i e n c i aa s i m i l a d a ,
los c o n o c i m i e n t o sa c l c l u i r i d o s ,
así ccmo la d o c u l n e n t a c l .
y
e l s o f t w a er el a b o r a d o
d su r a n t e
el
d e s s r r o l l o d e l p r o y e c t o ,p u e d e na p o y a r
y b e n e f i c i a r a:
'",J
1.. E l p a í sp, o qr u e
a p a r t i rd e
l a d é c a d a d e los 9 0 ' S , se 112
n o t a d ou nc r e c i m i e n t on o t : , l b l ee n
e l á r e a d ec o m u n i c a c i o n e s ,
y t:cj~lav
e
;
KISS o r g a n i z a c i o n e s y p a r t i c u l a r e s , demandan e s t e t i p od es e r v j - c i o
de
manera u r g e n t e ,p a r al o g r a ru nm e j o rr e n d i m i e n t o
y c o m p e t i t i v i d a d . Se
n o t ea n t o n c elsna e c e s i d a dd,qe u e
e l p a í ds e s a r r o l l e
e l software
necpsario,
ara q u e ndoe p e n ddae
los p a í s e d
s e s a r r o l l a d o es ne s t e
l a v e n t a j aa d i c i o n a l
de e la h o r r oe c o n ó m i c o
que s e da al
a z p o c t a ,c o n
e v i t a r l a importaci6n.
2.L a UliM, p o r que para e l l a e sn e c e s a r i o
e s t a r :¡.nterconert_;1clc7 ;i
rlivc-1 m u n d i a l ,p o rm e d i od er e d e s
como I n t e r n e t( p o r
citar scLo una),
y s e r e q u i edpr e r s o ncaocl no n o c i m i e n t qo uds e
el. soporte
nezes3rio.
Se p l a n e ai n v e s t i g a re np r i n c i p i o ,
l a b i b l i o g r a f í ae x i s t e n t e
y los
c u a l e s s e p u e d ae n c o n t r a ra p o y od o c u m e r l t a l
o de a l . g 6 n
r, t 2.' 3
iipo
para l a e l a b o r a c i ó n
d epl r o y e c t ol;a s
ideas
bAsi~aas
' c. r l i d s s
a l e s t u d i a r y a n a l i z a tro d a
e s t a b i b l i o g r a f iq
auedar511
d e b i d m i e n t ed o c u m e n t a d a s ,e n t r e g á n d o s eu ni n f o r m eq u i - n c e n a ld u r a n t e
el
t l - i r r ; ? s t rezn
e l cual d e d e s a r r o l l e el. P r o y e c t o I . Durante. l o s d o s
p r ~ y e c t ~c se p r a c t i c a r áe n
la r e d d e l e d i f i c i o ' € 1 ' , y e n l a Irlisma s e
j.:n:zlcrnentsr& el s o f t w a cr eo r r e s p o n d i e n t T
e .a m b i édnu r a n t e
los d o s
. .
q11e
~ ~ r z \ ~ . . - . rstco s r c c i b i r á n
tanto
las a s e s o r i a s como la superv.1.:;
I . ~ I T ; ? I : ~en
S los
,r
;
,-. , ! I )
:,,T.
'p":'
'1 > - . I
cT
':
.
2)
La b i b l i o y r a f i aS.ae d q u i r i r á lni b r o s
~ - ~ e ~ u ~ r la- ilraás b i b l i o t e c a s o l u g a r e sd o n d e
o se f o t o c o p i a r j n ,
estén d i s p o n i b l e s .
y
se
D a t o s generales
Nombre :
l3ivisión :
Carrera:
r4atrícula:
Dircccihn:
T'el6ttfcno
(casa):
Pior:,bre :
Civisión:
C x - r e r a:
Matrícllla :
Dircccibn:
B e n i t o C r u z Mendoza.
CBI.
L i c e n c i ' a t u r a en C o m p u t a c i ó n .
85325233.
Calle
t iN
2 3o r t e
del Conde 2 " S e c c i ó n .
C.P. 01400.
Delegati-ón Á l v a r oO b r e y 6 n .
Mkxico D. F.
6433538.
J o s 6 L u i s M é n d e zM o n t e s .
CUI.
L i c e n c i a t u r a e n Computación.
85228824.
Calle
Oriente
229
A y r i c o l aO r i e n t a l .
C.P. 08500.
I ) ~ ~ l e g a c i . Ó nI z t a c a l c o .
F.
M b x i c o D.
5582324.
c<11..
I1
Oliv,lI.
116
Co.1
' Con ligeras rnlodificaciones con respecto al original entregado
xi
CAPÍTULO 1
PROTOCOLOS DE
COMUNICACI~N.
CONCEPTOS BÁSICOS
,
PROTOCOLOS DE COMUNICACI~N.
CONCEPTOSBÁSICOS
[TOMADO Y ADAPTADO DE Tanenbaum, Jiménez, Goscinski, Holzmann y Rifflet.]’
Por una red se entiende un conjunto de computadoras autónomas conectadas entre sí, con
capacidad de comunicación; más adelante se profundizará sobre los detalles que conciernen a
las redes. Lamayoría de las redes se organizan en una serie de capas o niveles (o módulos),
conobjeto de reducirla complejidad desu diseño. Cada capa seconstruyesobresu
predecesora. El número de capas, el nombre, contenido y función de cada una varían de una
reda otra. Sin embargo, en cualquier red, el propósito decadacapa
es ofrecer ciertos
servicios a las capas superiores (y/o viceversa), liberándolas del conocimiento detallado de
cómo se realizan dichos servicios.
Lacapa n enunamáquina
conversacon
lacapande
otra máquina. Las reglas y
convenciones utilizadas en esta conversación se conocen conjuntamente como protocolo de
que
forman
las
capas
la
capa
n,
como
se
ilustra en
la
Figura 1. A las entidades
correspondientes en máquinas diferentes se les denomina procesos pares (igual a igual). En
otras palabras, son losprocesos pares los que se comunican mediante el uso delprotocolo.
1
I
Figura 1. Capas, protocolos e interfaces.
En realidad no existe una transferencia directa de datos desde la capa n de una máquina a
la capa n de otra; sino, más bien, cada capa pasa la información de datos y control a la capa
inmediata inferior, y así sucesivamente hasta que se glcanza la capa localizada en la parte
Capitulo 1
más baja dela estructura. Debajo de la capa 1 está el medio físico, a través del cual se
realiza la comunicación real. E n la Figura 1 se muestra, mediante flechas punteadas, la
comunicación virtual, en tanto que las flechas continuas indican la trayectoria
de
la
comunicación física.
Entre cada pardecapasadyacentes
hay una interface, la cual define los servicios y
operaciones primitivasque la capa inferior ofrece a la superior. Cuando los diseñadores de
redes deciden el número de capas por incluir en una red, así como lo que cada una de ellas
deberá hacer, una de las consideraciones más importantes consiste en definir claramente las
interfacesentre capas.Hacer esto,asuvez,
requiere que cadacapa efectúe un conjunto
específico de funciones bien definidas. El diseño claro y limpio de una interface, además de
minimizar la cantidad de informaciónque debepasarse entre capas,hacemás
simple la
sustitución de la realización de una capa por otra completamente diferente (por ejemplo, todas
las lineas telefónicas se reemplazan por canales satélite). Así todo lo que se necesita de la
nueva es que ofrezca exactamente el mismo conjunto de servicios a la capa superior contigua,
tal y como lo hacía la antigua.
AI conjunto de capas y protocolos se le denomina arquitectura de la red.
Computadora A
Funciones
orientadas a
proceso
Computadora B
4
4
4
Protocolos de alto nivel
Funciones
orientadas a
proceso
Protocolos de baio nivel
Funciones
orientadas a
comunicación
~
'
Funciones
orientadas a
comunicación
4
4
I
Medio de comunicación
Figura 2. Protocolos en la intercomunicación de redes.
1
A la conexión
de
dos
ó más
redes
se
le denomina interconexión
deredes.
La
interconexión de
redes
puede
ser dividida o estratificada en funciones orientadas a
procesamiento y funciones orientadas a comunicación. Esto implica que los protocolos pueden
ser divididos en protocolos de alto nivel, relacionados con la habilidad de los sistemas para
bajo
nivel
relacionados
con
la
intercambiar información y entenderla, y protocolos de
paquetización, ruteo y la transmisión de los datos en el nivel físicos de la red (ver Figura 2).
4
Implementación de
remoto
un shell
Protocolos de comunicación. Conceptos básicos
FUNCIONES DE LOS PROTOCOLOS
Se va a considerar en seguida un conjunto de furlciones que' son la base de todos
los
protocolos. No todas las funciones están comprendidas en cada
protocolo; esto significaría
una duplicación de esfuerzos. Las funcionesquedebe
desarrollar un protocolo pueden
agruparse en las siguientes categorías:
s
1. Segmentación y reensamblado
2. Encapsulado
3. Control de conexión
4. Control de flujo
5. Control de errores
6. Sincronización
7. Secuenciamiento
8. Direccionamiento
9. Multicanalización
1O.Servicios de transmisión
Segmentación y feensamblado. Un protocolo maneja el intercambio de secuencias de
datos entre dos entidades. Usualmente, la transferencia consiste enbloquesdedatosde
tamañoacotado.Sehablademódulos
superioresque gestionanla aplicación y basan su
operación en los servicios que les proporcionan las entidades inferiores, relacionadas con la
transmisiónde
la informacióna
través de mediosfísicos.
Generalmente las entidades
superiores producen bloques que los módulos inferiores deben fragmentar en unidades de
datos más pequeñas.Esteproceso
se conoce como fragmentación o segmentación. El
proceso contrario a la segmentación es el reensamblado. Eventualmente los datos
fragmentados deben reunirse para reconstruir el bloque original dirigido a la entidad superior
en el extremo superior. Existen varias razones quejustifican la segmentación y, en su mayoría,
se relacionan con la optimización de los parámetros de rendimiento dela red.
Por convención se llamará unidad de datos del protocolo (PDU) a cada uno de
bloques intercambiadosentre las entidades de un protocolo.
los
Encapsulado. Junto a sus datos, cada PDU contiene información de control. De hecho,
algunos PDUs contienen solamenteésta y puede ser de tres tipos: de direccionamiento, donde
se indica la localización del transmisory/o receptor; de manejo de errores, quepuede ser
alguna secuencia de bits para detectar fallas en la transmisión, y finalmente, de gestión del
protocolo, incluida para poder implantar el resto ,de las funciones del protocolo. Se conoce
como encapsulado a la operación que une los datos, con la información decontrol en una sola
PDU. Se dice que la entidad que recibe los datos, generalmente desde un módulo superior, se
encarga de encapsularlosjunto a la información de control, para producir una PDU.
Control de la c.onexión. Una entidad funcional puede transmitir datos a su corresponsal
en cualquier momento y sin que medie una coordinaciónprevia; a este tipo de transferencia se
le llama sin conexión u orientado a no conexión. Como analogía se puede citar el sistema de
correo convencional. Aún cuando la operación es útil, es más común la transferencia de datos
Universidad Autónoma Metropolitana. Unidad lztapalapa
5
Capítylo 1
orientada a conexión,queesanálogo
al servicio telefónico, Este tipo de transferencia se
prefiere cuando se anticipa un intercambio por un período prolongado.
Un procedimiento orientado aconexión
secompleta
en tresfases:
establecimiento,
transferencia y desconexión.En la primeradeberáestablecerseunaasociación
lógica o
conexión entre las entidades, en seguida se entra en la fase de transferencia en la que ambas
entidades pueden intercambiar datos e información de control. Finalmente, el intercambio se
termina cuando alguno de los lados envía una petición de desconexión. Alternativamente, una
autoridad central puede forzar la terminación.
I
Confrol de flujo. Se trata de una función que realiza cualquier entidad receptora para
limitar la cantidaddedatos que recibe o la rapidez conque éstos llegan desde la entidad
transmisora.
Confrol de errores. Para prevenir del daño o pérdidadela
información, muchos
protocolos incorporan técnicas de corrección de errores, basadas en ql uso de secuencias de
verificación y la retransmisión de las PDUs defectuosas.
Sincronización. Es obvio que las entidades de un protocolo necesitan recordar un cierto
número de parámetros que pueden interpretarse como variables que definen en conjunto el
estado o la configuración del sistema. Ocasionalmente, es importante que dos entidades que
se comunican utilizando un protocolo, se encuentren en un estado bien definido, por ejemplo
durante la inicialización, enalgúnpunto
de verificación dela transferencia o durantela
terminación. Esterequerimiento
se conoce como sincronización. No es fácil lograr la
sincronización entre dos entidades pues el estado de una sólo se conoce, en el otro lado, por
las PDUs que recibe su corresponsal. Estas PDUs no llegan instantáneamente, les toma un
cierto tiempo quizá variable y en algunas ocasionesse pierden antes dellegar.
Secuenciarnienfo. Esta función permite identificar el ordenenque
se transmiten los
PDUs con datos asignándoles un número de secuencia modular. El secuenciamiento de datos
sólo tiene sentido en el contexto de transferencias orientadas a conexión y sirve para tres
propósitos principales: entrega ordenada, control de flujo y control de errores.
Direccionarnienfo. Para que
dos
entidades
puedan
comunicarse,
deben
poder
identidad del
identificarse entre sí. Por ejemplo, es necesariocomúnmenteconocerla
destinatario para encaminar la información hacia ella. Debe hacerse una distinción entre el
nombre, la dirección y las rufas. Unnombre especifica un objeto,su dirección donde se
encuentra y la ruta indica como llagar hasta él.
Mulficanalización. A la transmisión de varios flujos de información por un sólo canal
lógico o físico se la llama multicanalización. Utilizando un nombre de conexión, porejemplo, es
posible que varios flujos de datos procedentes de una misma máquina se transmitan a través
enforma vertical, entre las
deun sólo canal físico. La multicanalización también seda
entidadesfuncionales locales, cuando varias de ellas, compartenuno de los servicios de
transmisión que les proporciona una entidad inferior.
6
Implementación
de
un shell remoto
Serviciosdetransmisión.
Un protocolo puede ofrecer unavariedadde
servicios
adicionales a las entidades que utilizan sus,servicios. Se pueden citar tres ejemplos comunes:
la pn’oridad, esto quiere decir que algunos mensajes, sobre todo de control, deben entregarse
a su entidad destino con un retardo mínimo; en segundo lugar el grado de servicio que se
refiere a los requerimientos de velocidad de transmisión de datos, y finalmente, la segun’dad,
el
queson los mecanismoscon quese controla el accesoa los recursosquegestiona
protocolo.
NORMALIZACIóN DE PROTOCOLOS
En los tiemposen
queapareció
el conceptode
red,cada
compañía fabricante de
computadoras tenía sus propios protocolos; IBM por ejemplo, tenía más de una docena. Esto
dabacomo
resultado que aquellos usuarios que adquirían computadorasde
diferentes
compañías, no podían conectarlas y establecer intercomunicación con ellas. El caos generado
por esta incompatibilidad dio lugar a la exigencia de los usuarios para que se estableciera una
normalización al respecto.
I
Estanormalizaciónnosolamente
iba a facilitar la comunicación entre computadoras
construidas por diferentes compañías, sino que también traeria, como beneficio, el incremento
los productos que se ajustan adicha norma, que conduciría auna
enelmercadopara
producciónmasiva,unaeconomíade
escala,así
como otros tipos de beneficios cuya
tendencia sería disminuir su precio y alentar su posterior aceptación.
Por la forma en que son establecidas, las normas se dividen en categorías que pueden
definirse como: de facto y de jure. Las normas De Facto (del latín, que significa “del hecho”),
son aquellas que se han establecido sin ningún planeamiento formal. Las normas IBM PC y
sus sucesoras son normas de facto para pequeñas computadoras de oficina, porque docenas
de fabricantes decidieron copiar fielmente las máquinas que IBM sacó al mercado.
Por el contrario, las normas De Jure (del latín, que significa “por ley”) son normas formales,
legales, adoptadas por un organismo que se encarga de su normalización. Las autoridades
internacionales encargadas de la normalización se dividen, por lo general, en dos clases: la
establecida porconvenio entregobiernos nacionales, y la establecida sin un tratado entre
organizaciones (con afiliación voluntaria). En ,el
área
de
normalización
de
redes
de
computadoras, existen dos organizaciones principales, de los dos tipos: I S 0 (Organización
InternacionaldeNormalización),
que se puedeconsiderardeJureyCCITT(Comité
Consultivo Internacional Telegráficoy Telefónico), que es la organización de Facto.
7
Capítulo 1
I
NORMALIZACIóN ENLAS TELECOMUNICACIONES
El status legal de las compañías telefónicas en el mundo varía considerablemente de un
país a otro. Enun extremose
encuentra EstadosUnidos,que
tiene alrededorde 1600
compañías telefónicas privadas diferentes.
En el otro extremo, se consideran los paísesen los que el gobierno nacional tiene un
el correo, telégrafo y,
monopolio
completo
de
todas
las comunicaciones,
incluyendo
frecuentemente, también la radio y televisión. La mayoría de los países caen en esta última
categoría. En algunos casos, la máxima autoridad en las telecomunicaciones resulta ser una
compañía nacionalizada, en tanto que en otroses sólo una rama derivada de la estructura
gubernamental.
.Con todosestos distintos proveedoresde servicios,esclara lanecesidaddequedicho
servicio
sea
compatible
una
a
escala mundial, para asegurar
que
la
gente (y
las
computadoras)en un determinado país, pueda llamar a sus corresponsalesen otro. Esta
coordinación la ofrece una agencia de las Naciones Unidas llamada ITU (Unión Internacional
de Telecomunicaciones).
Un órgano de la ITU, el mencionado CCITTfue muy importante en lo referente a normas. El
CCITT tenía cinco clases de miembros:
miembros
A que
son
los organismos de
comunicaciones más importantes de un país;miembros B, queson los reconocidos como
administracionesprivadas (por ejemplo, AT&V); miembrosC, queson las organizaciones
a
otras organizaciones
científicas e industriales; miembros Dl que corresponden
internacionales; ymiembros E, que correspondena aquellas organizaciones cuya misión
fundamental está en otro campo, pero que están interesadas en el trabajo del CCITT. De esta
clasificación, solamente los miembros tipo A tenían derecho de voto.
La tarea del CCITT consistió en promover las recomendaciones técnicas sobre aspectos
telefónicos, telegráficos e interfaces de comunicación dedatos. Esta labor produjo normas que
tuvieron un reconocimiento internacional; dos ejemplos que se pueden citar al respecto son: la
norma V.24 (tambiénconocida como EIA RS-232, enEstados Unidos), que especifica la
distribución y significado de las diferentes puntas del conector que se utiliza en la mayoría de
las terminales asincronas, y la norma X.25, que especifica la interface entre una computadora
y una red de computadoras.
LA IS0 Y OTROS ORGANISMOS DE NORMALIZACIóN
Las normas internacionales son producidas por la IS0 mencionada anteriormente, que es
una organización voluntaria, fuera detratados y fundada en 1946, cuyosmiembros son las
organizaciones nacionalesde normalización.
a
Implementación de un shell remoto
Protocolos de comunicación.ConceDtos básicos
La IS0 emitenormasenuna
gama muy ampliade temas, quecubrendesde aquellos
referentes atuercasy tornillos (literalmente hablando), hasta los recubrirnientos depostes
telefónicos. La IS0 tiene casi 200 comités fécnicos ( X ) , cuyo orden de numeración se basa
en el momento de su creación, ocupándose cada uno de ellos de un tema especifico. Por
ejemplo, TCI trata Io referente a tuercas y tornillos (normalizando los pasos de las hélices de
los tornillos); el TC97, está relacionado con computadoras y procesamiento de
información.
se dividen en grupos de
Cadaunode los TC tiene subcomités (SC), los cualesasuvez
trabajo (WG).
Los WG, constituidos por casi 100 O00 voluntarios, distribuidos en todo el mundo, son los
queefectivamente
realizan el trabajo. Varios de estos “voluntarios” sonpor
lo general
asignados por las propias compañías, cuyos productos están en vías de normalización, para
trabajar en asuntos de la OSI; otros voluntarios son empleados de gobierno interesados en
promover que las cosas que está haciendo su país se adopten como normas internacionales.
Expertos académicos también juegan una parte muy importante y activa en la constitución de
varios WG.
La IS0 y el CCITT algunas veces cooperan (la IS01 es un miembro de clase D del CCITT),
conrespectoa
la emisión de normas sobre telecomunicaciones,con objeto de evitar el
absurdo de dos normasinternacionales oficiales, mutuamente compatibles.
El representante de Estados Unidos en la IS0 es el ANSI (Instituto Nacional Americano
de Normalización), quien a pesar de su nombre es una organización privada, descentralizada
y no lucrativa, que está constituida por fabricantes, proveedoresde servicios portadores
comunes y otros grupos interesados. Las normas del ANSI son fi-ecuentemente adoptadas por
la ISO, como normas internacionales.
El procedimiento que utiliza la I S 0 para el establecimiento de normas, está diseñado para
conseguir el mayor consenso posible del tema respectivo. El proceso se inicia cuando una de
las organizaciones
de
normalización
de
carácter nacional siente la necesidad del
establecimiento de una norma internacional enunárea
específica; formando un grupode
trabajo que llega a plantear una DP (Propuesta de Anteproyecto). Una vez que se genera la
DP, se hace circular entre todos los miembros, los cuales cuentan con seis meses, a partir de
ese momento, para plantear sus comentarios y críticas. Si una mayoría significativa aprueba la
propuesta, se produceun documento revisado, denominado DIS (Anteproyecto de Norma
Internacional), el cual circula nuevamente con objeto de tener más comentarios y realizar una
votación al respecto. Conbaseen los resultados de esta votación, se prepara, aprueba y
publica el texto final de la IS (Norma Infernacional). En algunas de las áreas, en donde existe
una gran polémica, la DP o DIS probablemente tenga que pasar por varias versiones, en su
tal
planteamiento,antes de adquirir el número de votosnecesarioparasuaprobación,de
forma que el proceso completo puedellevar varios años.
La NBS (Oficina Nacional de Normas) es una agencia del Departamento de Comercio de
Estados Unidos que emite normas obligatorias para las adquisiciones que realiza el gobierno
de Estados Unidos, con excepción de aquellas que realiza directamente el Departamento de
Defensa.
9
Capítulo 1
I
Otro participante importante enel
mundo delasnormas,es
el IEEE (Institutode
Ingenieros Eléctricos y Electrónicos), quees la organización profesional más grande del
mundo. Esta institución, además de publicar numerosas revistas y programar un número muy
grande de conferencias anuales, ha establecido un grupo dedicado al desarrollo de normas en
el área de ingeniería eléctrica y computación. La norma 802 IEEE, pafa una red de área local
(véase el capítulo de redes), es la norma clave para el desarrollo de las redes de área local.
Posteriormente, fue adoptada por la I S 0 como base para la norma I S 0 8802.
EL MODELO OS1
En1977 la IS0 designó al ComitéTécnico97
como encargado del desarrollo deuna
arquitectura para redes. El resultado desus trabajos fue el Modelo de Referencia para la
(OS])adoptadoen1983porel
CCITT comola
Interconexión de SistemasAbiertos
recomendación X.200. El modelo propone dividir el conjunto de funciones relacionadas conlos
servicios decomunicaciónen
capas o niveles funcionales de acuerdocon los siguientes
criterios:
1. Homogeneidad de las funciones contenidas encada nivel.
2. Definición de niveles entre los que las interacciones se limiten al mínimo.
3. Mantenimiento del número de niveles o estratos funcionales en
un
rango
razonable.
LOS OBJETIVOS DEL MODELO OS1
Los objetivos del modelo OS1 son (IS0 1981):
l . Proporcionar una base común para la coordinacibn del desarrollo de normas para lograr
la interacción de sistemas, mientras se permita la existencia denormaspara
ser
colocadas en la perspectiva dentro del modelo de referencia completo.
2. Identificar áreas de desarrollo o mejoramiento de normas.
3. Proporcionar una referencia común para mantener la consistencia de todas las normas
relacionadas.
4. Permitir la interconexión de sistemas de diferentes vendedores.
CONCEPTOS DEL ENFOQUE DE CAPAS
Una capa o un nivel: define un nivel de abstracción diferente, agrupando tareas
semejantes y separándolas de grupos complementarios. AI dividir en capas se prevée que los
cambios futuros de alguna de ellas no afecte el desempeño del resto. (Ver
Figura 3).
10
Implernentación
de
remoto
un shell
Corresponsales o entidades pares: Son entidades que soportan el protocolo de nivel
N.
Interface: Frontera vertical entredos
niveles adyacentes.Deberá ser pequeño y bien
definido.
Puntos de Acceso a Servicio (SAP):Medios a través de los cuales se comunican dos
capas adyacentes através de la interface.
Primitivas de Servicio:Información intercambiada pordos capas adyacentes.
capa N + l
................................................................
Protocolo
Interface
Entidades pares
capaN
................................................................
capa N -1
Primitivas
Servicios proporcionados
Figura 3. El concepto de capas enel modelo OSI.
Se dice que OS1 es un modelo para sistemas abiertos, pues pone especial atención en el
intercambio de información entre sistemas y no en el funcionamiento interno de cada sistema
en particular, buscándose con ello la comunicación entre equipos heterogéneos.
S
11
Capítulo I
LAS CAPAS DEL MODELO OS1
El modelo OS1 describe una arquitectura estratificada de red dividida en siete capas:
1.
2.
3.
4.
5.
6.
7.
La Capa Física.
La Capa de Enlace De Datos.
La Capa de Red.
La Capa de Transporte.
La Capa de Sesión.
La Capa de Presentación.
La Capa de Aplicación.
T
Las capas inferiores comprenden las funciones que aseguran la transferencia de operación
entre dosterminalesdentro
de la redde telecomunicaciones.La cuarta capa releva a las
sesiones de cualquier detalle referente a la forma en la cual se realiza la transferencia de
datos. Los niveles uno acuatro de OS1 conforman el subsisfema de fmnsporfe.
I
Los niveles de sesión, presentación y aplicación constituyen los niveles superiores de OSI.
Estas capas ofrecen una serie de servicios orientados al usuario: videotexto, teletexto, fax,
etc.
-
C
O
m
P
U
t
a
d
I
Aplicación
I
Aplicación
t
I Presentación I
1 Presentación 1
4
f
O
m
P
Transporte
t
a
d
t
I
Transporte
t
Red
Enlace
1
1
O
r
a
B
A
-
L
t
Enlace Flsico
Figura 4. Las capas del modelo OSI.
12
C
U
:
I
I
I
-
Sesión
O
r
a
I
I
Protocolos de comunicación. ConcePtos básicos
EL SUBSISTEMA DE TRANSPORTE DE OS1
1. La Capa Fisica. Proporciona las características mecánicas,.eléctricas, funcionales y de
conexiones
físicas para la transmisión
procedimiento
para
activar y mantener
transparentede bits entre entidadesde ,enlace de datos. En particular soporta la
transmisión y recepción de especificaciones de información, de bits de sincronización y
deseñalesdependientes del medio. Unejemplo de protocolo de la capa física es la
norma
RS-232C,
que
es
la
tercera versión de la norma RS-232 mencionada
anteriormente.
2. LaCapadeEnlace.
Proporciona los medios funcionales y deprocedimientopara
activar, mantener y desactivar una o más conexiones de enlace de datosentre capas de
red. En particular proporciona control de conexión, encapsulamiento, direccionamiento,
secuenciamiento, corrección y detección de errores, servicios de transmisión y control de
flujo. Comoejemplode protocolo delacapa
de enlace,se tiene el protocolo HDLC
(Control de Alto Nivel del Enlace de Datos),
que se analizará más adelante.
3. LaCapadeRed.
Proporciona los medios para establecer, mantener y finalizar
conexiones
de
red entre
sistemas
que
contienen
entidades
de
aplicación de
comunicación entre dos entidadesde transporte a través deconexionesde red. En
particular, esta capa proporciona, direccionamiento, control de reenvío y tiempo de vida
de mensajes, control de congestión y control de flujo. El Protocolo de Interconexión de
Redes (IP), de ARPANET, es un ejemplo de protocolo de la capa de red
(se revisará
más adelante). ARPANET (ReddelaAgencia
deProyectosdeInvestigación
Avanzada) es la creación de ARPA (ahora conocida como (DARPA), que es la Agencia
de
Proyectos
de
Investigación
Avanzada (de la
Defensa)
correspondiente
al
Departamento de Defensa de Estados Unidos.
4. La Capa de Transporte. Proporciona la transf rencia transparente de datos entre dos
capas de sesión. En particular proporciona mu1 iplexado, direccionamiento, control de
conexión, fragmentación de mensajes, secuenciación, control de error y control de flujo
de terminal a terminal, así como la paquetización demensajes Se identifican tres tipos de
servicios de transporte: tipo de conexión, tipo de transacción y tipo de difusión. Los
protocolos TCP (Protocolo de Control de Conexión) y UDP (Protocolo de Datagrama
de Usuario) de ARPANET, sonejemplos de protocolos delacapade
transporte; se
analizarán más adelante.
9
LAS CAPAS SUPERIORES DE OS1
l . La Capa de Sesión. Proporciona los medios necesarios para la cooperación de las
capas de presentación para organizar y sincronizar su diálogo y manejar su intercambio
de datos. En particular, ésta capa libera, sincroniza, multiplexa, y administra recursos,
exceptuando el reporte y servicios de comunicación. Se tiene el protocolo NFS (Sistema
de
Archivo
en
Red),
desarrollado por SUN Microsystems como un protocolo
correspondientea la capa de sesión. Este protocolo permite que un conjunto de
13
3.
computadorascomunicadas entre sí accedan los archivos de otras de ellas como si
fueran locales.
La Capa de Presentación. El propósito de ésta capa es representar información para
la comunicación de lascapas de aplicación de ,modoquese mantenga el significado
mientras se resuelven las diferencias de sintaxis. En particular esta capa proporciona los
siguientes servicios: transferencia de datos, protocolo de encriptamiento, selección de la
sintaxis de los datos del usuario, protocolo de conversión, y conversión del formato de
datos. Ejemplo: XDR (Representaciónde Datos Externos). Desarrolladopor SUN
Microsystems, permite la representación deestructuras de datos independientemente de
la máquina.
LaCapade
Aplicación. Los protocolos deestacapa
sirven directamentea la
comunicación del usuario final por medio del servicio de
información
distribuida
(intercambio del significado de la información) apropiado para una aplicación. Esta capa
proporciona la identificación de los usuarios que intentan comunicarse (por ejemplo, por
nombre o por dirección) e identificación de las tareas a ser comunicadas. Muchos tipos
de tareas son relevantes para el OSI: procesamiento de texto, transacciones bancarias,
reservacionesde aerolíneas, acuerdosde recursos, procesamientode transacción de
terminal a computadora, programas de control de proceso en tiempo real. Los servicios
decomunicación son: transferencia de archivos de la red, terminal virtual, terminal a
terminal y control de red. Ejemplo:el protocolo RCP (Llamada a Procedimientos
Remotos) ha sido definido por SUN Microsystems. Permite a un proceso, en el curso de
su ejecución, hacer una llamada a procedimiento o función con parámetros y valores de
vuelta en otra máquina.
lmplementación de unshell remoto
14
."
".
l
_
"
_
..-
.I
TIPOS DE PROTOCOLOS
El protocolo más simple se llama Stop 8, Wait (Paro y Espera), y trabaja como sigue: el
receptor indica su disponibilidad enviando una señal, entonces el transmisor envía sus datos y
espera a que el receptor le vuelva a indicar su disponibilidad, antes de volver a transmitir. Este
procedimiento funciona bien cuando los mensajes pueden ser enviados en un solo paquete,
pero muy frecuentemente un mensaje es dividido en varios paquetes. Si este es el caso, su
desempeño es inadecuado.
’
Se puede concluir que, en algunos casos, el sencillo procedimiento de reconocimientostop
2% wait proporciona un rendimiento adecuado. Para aquellos casos donde esto no ocurre, es
deseable un procedimiento más elaborado. Tal procedimiento, es conocido como pipelining
(entubamiento).
Supóngase la existencia de dos estaciones, A y B, conectadas mediante un enlace dúplex
(comunicación
en
dos sentidos simultáneamente). La estación B posee siete buffers
(dispositivos o lugares concapacidad dealmacenamiento) derecepciónen
lugar de uno.
Luego, B puede aceptar hasta siete paquetes y A,puede enviar hasta siete paquetes antes de
ser
esperarpor un reconocimiento. Para guardarle la pista a los paquetesquehande
reconocidos, cada uno de estos se etiqueta con un número en el rango de O a 7 (módulo 8 ) . B
acepta un paquete enviando un reconocimiento queincluye el número de secuencia del último
paquete correcto que recibió. Por tanto, si B devuelve el número de secuencia 6, significa que
aceptatodos los paquetes previos hasta e incluyendo el 6, y avisa queahoraespera
el
paquete 7. La estación A, por otro lado, mantiene una lista con los números de secuencia de
los paquetesquepuede
enviar, mientrasque B lleva una lista con los númerosde los
paquetes que puede recibir. Cada una de estas listas puede visualizarse como una “ventana”
de paquetes. Por esta razón al mecanismo de gestión de paquetes que se utiliza se le conoce
como sliding window (ventana deslizante).
Hasta el momento se ha discutido la transmisión en una sola dirección. Si dos estaciones
intercambian datos, cada una debe mantener dos ventanas: una para transmisión y otra para
recepción, en este caso, una técnica llamada piggybacking(acarreoacuestas)
es
comúnmenteusada.En ella una estación que tiene datos que transmitir, ademásde estar
obligada a reconocer los paquetes que se le han enviado, aprovecha el paquete de datos para
cargarle a cuestas el reconocimiento pendiente, con lo que se ahorran paquetes.
En un procedimiento normal, el transmisor envía un paquete de información etiquetada con
un número de serie. Cuando ésta llega al otro lado, el receptor verifica si hay o no errores en el
paquete recibido. Si no hayerrores, el receptordevolverá un acuse de recibo enviando un
paquete de reconocimiento(REC) que contendrá la etiqueta del paquete aceptado.
Debido a las limitaciones del canal físico, al receptor4 pueden llegar paquetes en apariencia
completos, pero con errores. Por esta razón, es necesario verificar la existencia de errores en
cada uno de ellos.
Encasode error, el receptor devolverá unpaquetededesconocimiento
(NREC) donde
informa al transmisor el número de seriedel paquete con problemas para que
éste pueda
reexpedirlo.
15
Capítulo 1
I
En el peor
de
los casos,puedepresentarse
la pérdida
de
la información o del
reconocimiento. Por tanto, cada vez que el transmisor envía un nuevo paquete, debe arrancar
un temporizador para contabilizar el plazo máximo que debe esperar antes de dar por hecho
su pérdida y retransmitirla o tomar alguna otra medida correctiva.
De manera genérica, a este conjunto de procedimientos seles
Automática de Repetición(ARQ).
conocecomo Solicitud
Se van arevisar tres modalidades de ARQ:
1. ARQ alto y espera.
2. ARQ con repetición no selectiva.
3. ARQ con repetición selectiva.
ARQ ALTO Y ESPERA
Esta versión de ARQ de uso popular usa el sencillo esquema de reconocimiento alto y
espera, descrito con anterioridad. La estación transmisoraenvía un paquete y espera su
reconocimiento.Ningún otro paquetepuede enviarse hastaque la estación conteste. Esta
puede
regresar
un reconocimiento positivo (REC)
si
el paquete es correcto, o un
reconocimiento negativo (NREC) en otro caso.
Este algoritmo, sin embargo, no contempla todas las contingencias. El paquete transmitido
puede ser descompuestopor el ruido del canal, a tal grado que, ni siquiera llegará asu
destino. En cuyocaso el receptor no respondería. Tomandoencuenta esta posibilidad, el
transmisor está equipado con un temporizador que se echa a andar en cuanto setransmite un
paquete. Si éste expira antes de que llegue una respuesta desde el otro lado del enlace, el
transmisor volverá a enviar la última tramaque
mandó.Obsérveseque
ésta modalidad
siempre requiere que el transmisormantengauna copia del paqueteque envía hasta que
reciba un reconocimiento positivo (REC) del mismo.
Se requiere un refinamiento adicional. Considerese la siguiente situación. La estación A
envía un paquete, que es recibido correctamente porB, quien a su vez responde con REC. Sin
embargo, el paquete REC en camino se daña y no puede ser reconocido por A, quien debe
retransmitir el mismo paquete, este paquete duplicadoes aceptado por B. Para evitar este
alternada con los números O y 1, de la
problema, los paquetessonetiquetadosenforma
misma forma los reconocimientos sonde la forma RECO y RECI.
La principal ventaja de este esquema essusimplicidad.
Sin embargo puede ser muy
ineficiente. La técnica de ventana deslizante presentada con anterioridad, puede adaptarse
para ofrecer un uso más eficiente de la línea. En este contexto se le conoce como ARQ
continuo.
I
16
Implementación deremoto
un shell
ARQ CON REPETICIóN NO SELECTIVA
Una variante del ARQ continuo se llama ARQ Go Back N (Devuelve N). En esta técnica
una estación puede enviar una seriede paquetes,hasta un máximodeterminadopor
el
número total de ventanas que puede tener abiertas. Si la estación receptora detecta un error
en un paquete, ésta envía unreconocimiento negativo NREC, paraesepaquete.También
descartará todos los paquetes posteriores al dañado sin siquiera analizarlos.
Entonces la estación transmisora, cuando recibe un NREC, retransmite el paquete que tuvo
error más los paquetes que le sucedían.
Si la ventana del emisor se llena, antes de que el temporizador venza, la línea se quedará
inactiva. Eventualmente al expirar el tiempo del emisor, éste comenzará aretransmitir en forma
ordenada todos los paquetes que no tengan reconocimiento, comenzando con el que está
dañado o perdido.
Con ARQ con repetición no selectiva, no es necesario que cada paquete sea reconocido.
Por ejemplo, la estación A envía los paquetes O, 1, 2, y 3. La estación B responde con RECO
después del paquete O, pero no responde a los paquetes 1, 2 y 3. Después de que el paquete
3 es recibido, envía el REC3, indicando que el paquete 3 y todos los paquetes anteriores son
aceptados.
Se pueden presentar otras contingencias, por ejemplo, supóngase un flujo de paquetes en
una línea dúplex. Mientras la estación transmisora A envíalas tramas 2, 3 y 4, la estación
(REC) del paquete I previamente recibido. Tiempo
receptora B mandaunreconocimiento
después, el paquete 2 es recibido con error: Los paquetes 3, 4 y 5 están en tránsito. B manda
un paquetededesconocimiento NREC2 aA el cual es recibido despuésdeque
ésta ha
mandado el paquete 5 pero, entes de mandar el 6. A debe entonces retransmitir los paquetes
2, 3, 4, y 5, aunque sólo el paquete 2 hayatenidoerror. Otra vez, la estación transmisora
debe tener una copia delos paquetes no reconocidos.
Nóteseque el número máximo de paquetes que pueden estar saliendo en cualquier
instante esdemaxseq,
y nodemaxseq
+ 1, aúncuandohayamaxseq
+ 1 númerosde
secuencia distintos: 0123...maxseq. Para entender la razón por la cual se necesita tener esta
restricción, considérese la siguiente situación con maxseq= 7:
1. El transmisor envía paquetes del O a la 7.
I
2. El reconocimiento superpuesto parael paquete 7 eventualmente regresaal emisor.
3. El emisor envía otras ocho paquetes, de nuevo con números de secuencia que vandel O
al 7.
4. Ahora llega otro reconocimiento superpuesto para el paquete 7.
La pregunta que se plantea es la siguiente: ¿“Los ocho paquetes pertenecientes al segundo
lote llegaron con éxito, o los ochopaquetes se perdieron” (cgntando las desechadas que
17
Catitulo 1
siguieron a un error como pérdida?. En ambos casos el receptor estaría enviando el paquete
7 como el reconocimiento. El emisor no tiene manera de decidir. Por esta razón, el ,número
máximo de paquetes enviados sin reconocimiento deberáser igual al valor maxseq.
ARQ CON REPETICIóN SELECTIVA
La técnica de Repetición Selectiva ofrece un enfoque mejorado. Los únicospaquetes
transmitidos son aquellos que se señalan en la respuesta NREC.
Por otro lado, el receptor debe de poseer la capacidad de almacenamiento necesaria para
guardar temporalmente los paquetes que arribaron después de el que fue desconocido, así
como la lógica para reordenarlos en la secuencia correcta, una vez que sea retransmitido el
paquete defectuoso. El transmisor también requerirá de una lógica de mayor complejidad para
retransmitir paquetes fuera de secuencia: por esta razón la técnica de repetición no selectiva
se usa más comúnmente.
El tamaño de la ventana es más restrictivo para la técnica de ARQ con repetición selectiva
que para la de ARQ con repetición no selectiva. Considérese el caso de un campo de tres bits
(el espacio de la secuencia es (8), y sea la siguiente situación:
1. La estación A envía los paquetes O a 6 a la estación B.
2. La estación B recibe y reconoce los paquetes.
3. Debido al ruido, el reconocimiento se pierde.
4. La estación A espera un momento y retransmite la secuencia.
5. La estación 8 ya ha avanzado su ventana para aceptar los paquetes 7, O, 1, 2, 3,4, 5.
Así, ésta se supone que es un nuevo lote y acepta a O, 1, 2, 3,4 y 5.
El problema con la situación anterior para ARQ con repetición selectiva,es que hay un
traslape entre las ventanas
de
transmisión con que
se
administran dos
secuencias
consecutivas. Para superar el problema, el tamaño máximo de la ventana no deberá ser mayor
que la mitad del rangode la secuencia de números.
E
18
I
Protocolos de comunicación. ConceDtos básicos
EL PROTOCOLO DE ALTO NIVEL DE CONTROL DEENLACE DE DATOS
(HDLC)
Algunos de los protocolos que han conseguido una amplia aceptación son:
Protocolo de Alto Nivelde Control de Enlace de
Datos. (HDLC).Desarrollado por ISO.
Procedimientos de Control de Comunicación de DatosAvanzados .(CCP).Desarrollado por
el ANSI.
Procedimiento Balanceado de Acceso de Enlace. (LAP-B).Adoptado por el
CCITT como
parte de su recomendaciónX 2 5 para redes de conmutación de paquetes.
Control de Enlace deDatos Sincrono. (SDLC).Usado por IBM.
No existen diferencias virtualmente, entre HDLC y CCP. LAP-B es un subconjuntode
HDLC. SDLC tambiénes
un subconjuntodeHDLC,
aunque incluye algunas diferencias
menores. A manera de ejemplo se revisará el prot,ocolo HDLC.
HDLC define tres tipos de estaciones, dosconfiguraciones de enlace y tres modosde
operación para transferencia de datos. Los tres tipos de estación son:
Estación primaria. Tiene la responsabilidad de controlar la operación del enlace. Las
tramas producidas por el primario se llaman comandos. (Como se trata de la capa de enlace
de datos, las unidades deinformación son las tramas).
Esfación secundaria. Opera bajo el ,control de la primaria. Las tramasproducidas por
una estación secundariasellaman
respuestas. El primario mantiene un enlace lógico
separado por cadaestación secundaria en línea.
Estación combinada. Reúne las características de las estaciones primaria y secundaria.
Una estación combinada puede producir comandos o respuestas. Las dos configuraciones de
enlace se muestran en la Figura 5.
Desbalanceada. Se usa en operaciones punto a punto y multipunto. Esa configuración
o
consiste enuno primario y uno o varios secundarios y soportatransmisionesdúplex
semidúplex (transmisión en los dos sentidos, pero no simultáneamente).
Balanceada. Se usa sólo en configuraciones punfo a punto. Esta configuración consiste
en dos estaciones combinadas y soporta transmisiones dúplex y semidúplex.
19
.
Capítulo 1
..
Los tres modos para transferencia de datos son:
,
Mododerespuestanormal(NRM).
Estaes una configuración desbalanceada. El
primario puede iniciar la transferencia de datos hacia un secundario, pero un secundario
solamente puede transmitir datos en respuesta a un comando proveniente del
primario.
Modo Asíncrono Balanceado (ABM).Esta es una configuración balanceada. Cualquier
estación combinada puede iniciar la transmisión sin recibir permiso alguno de laotra.
Modo de Respuesta Asíncrono (ARM).Esta es una configuración desbalanceada. En
este modo, un secundario puede iniciar latransmisión ,sin permiso explícito del primario. El
primario sigue teniendo la responsabilidad de la línea, incluyendo la recuperación de errores y
la desconexión lógica.
(a)
comandos
PRIMARIO
$espuestas
i
SECUNDARIO
SECUNDARIO
$omando,s
COMBINADO
COMBINADO
respuestas
Figura 5. Configuraciones de enlace HDCC. (a) desbalanceada, (b) balanceada.
HDLC usa transmisión síncrona. Todas las transmisiones son en tramas y un formato Único
es suficiente para todos los tipos de datos e intercambios de control.
La Figura 6 muestra la estructura de la trama HDLC. La trama tiene los siguientes campos
Bandera: 8 bits.
Dirección: uno o más octetos.
Control: 8 o 16 bits.
Datos: variable.
Secuencia de verificación de trama (SVT): 16 o 32 bits.
Bandera: 8 bits.
1
Los campos de bandera, dirección y control que preceden al campo de datos se conocen
20
Implementación
de
remoto
shell un
I
comoencabezado,mientras
terminación.
que la SVT, y la banderadespuésde
los datos, sellaman
Los campos de bandera delimitan los extremos de la trama con el patrón Único 01111 110.
Sin embargo,debidoaque
HDLCpermite la presenciadepatrones arbitrarios de bits, no
existe la seguridad de que el patrón O1 111110 no aparezca en algún lugar del interior de la
trama, destruyendo la sincronización a nivel de trama. Para evitar esta situación, se utiliza un
procedimiento conocidocomo rellenado de bits (bit stufing). En éste, el transmisor insertará un
bit O extra, cada vez que detecte la ocurrencia de un patrón de cinco 1’s consecutivos, dentro
de la trama (excepto cuandose trate realmente de una bandera).
Después de detectar la aparición de una bandera de inicio, el receptor monitorea el flujo de
bits. Cuando aparece un patrón de cinco l’s, se examina el sexto. Si éste es cero se borra.
BANDERA
a
I DIRECCIÓN I CONTROL I
octetos
8 0 16
DATOS
SVT
BANDERA
varigble
16 o 32
8
Figura 6. Estructura de una trama HDLC.
Si es I y el que sigue es cero, se trata de una bandera. Si el sexto y séptimo bits son l’s,la
estación transmisora está señalando .una condición de aborto.
Con el uso del rellenado de bits, pueden insertarse patrones arbitrarios en el campo de
datos de latrama. A esta propiedad se le conoce como transparencia de datos.
El campo de direcciones se usa para identificar a la estación secundaria que transmite o
recibe la trama. Este campo no es necesario para enlaces punto a punto, pero siemprese
incluye por uniformidad. Una dirección, normalmente es deocho bits, pero habiendo un
acuerdo previo, puedeusarseunformatoextendidoen
elque la longitud de la dirección
extendida es un múltiplo de siete bits. El octavo bit de cada octeto es 1 o O, dependiendo si
éste es o no el último octeto de la dirección. El octeto I1 1I1 111 se interpreta como una trama
para todas las direcciones, tanto en el formato básico, como en el extendido. Se utiliza para
permitirle al primario la difusión de una trama dirigida a todos los secundarios.
HDLC define tres tipos de tramas, cada uno con diferentes formatos de campo de control.
Las tramas de información (tramas I), acarrean los datos que son transmitidos por la estación,
conocidos como datos del usuario. Adicionalmente, alguna información de control de flujo o
error, usando el mecanismo ARQ, puedellevarse a cuestas (piggybacking), de la misma trama
I. Las tramas de supervisión (tramas S) proporcionan el mecanismo ARQ, cuando no se lleva a
cuestas la información para manejo de errores y control de flujo. Las tramas no numeradas
(tramas U) proveen las funciones suplementarias para el control del enlace.
El campo de datos se presenta solamente en las tramas I, así como en algunas tramas no
numeradas. Este campo puede contener cualquier secuencia de bits. Su longitud máxima está
21
Capítulo 1
normalmente acotada por laimplantación y debe ser un múltiplo de 8 bits.
La secuencia de verificación de trama se aplica a los bits restantes de la trama, excluyendo
a las banderas.
La operación de HDLC consiste en intercambios de tramas-I, tramas-S y tramas-U entre
unaestación primaria y una secundaria o entre dosestaciones primarias. Los diferentes
comandos y respuestas definidos para estos tipos de tramas se muestran en la Tabla 1. Para
describir la operación de HDLC, primero se discutirán estos tres tipos de tramas, y luego se
darán algunos ejemplos.
I
Nombre
Fun
DescriDción
lrlformación ( I )
Supervisión ( S )
No Listo para Recibir ( RNR )
Lislo para Recibir ( RR )
Rechazo ( REJ )
Rechazo Selectivo ( SREJ )
No Numerado ( U )
Establecimienlo de Modo NRM I NRM Extendido
CIR
CIR
C IR
CIR
CIR
CIR
lnlercambio de datos deusuario
Establecimiento de Modo ARMI ARM Extendido
C
Eslablecimienlo de Modo ABM I ABM Exleudido
C
Establecimiento de modo de lnicialización ( SIM )
C
Desconectado ( DISC )
Reconocimienlo no numerado ( VA)
C
R
Modo Desconectar ( DM )
Requerimiento de Desconexión ( RD )
Requerirnienlo de Modo de lnicialización ( RIM )
Información No Numerada ( VI )
Bit de Encuesta No Numerado ( UP )
Reset ( RSET)
htorcambio do Idorltilicnción ( XID )
Prucba ( TES7 )
Rechazo de Trama ( FRMR )
R
.
C
R
R
CIR
C
C
C/R
CIR
Reconocimiento positivo: No lisb para recibir
Reconocimiento positivo: Listo para recibir trama-I
Reconocimiento negativo: Repetición no Selectiva
Reconocimiento negativo: Repetir Selección
Estabiecimienlo de modo; Extendido = campo de control de dos
octetos
Establecimiento de modo; Extendido 5 campo de conlrol de dos
ocletos
Establecimiento de modo; Extendido = campo de control de dos
octetos
Inicializa funciones de control de enlace en la estación
direccionada
Termina conexión de enlace lógico.
Aceptación de reconocimientos de uno de los comandos de
selección de modo anteriores
El secundario está desconectado Iogicamente
Requerimiento del comando DISC
lnicialización necesaria; requerimiento del comando SIM
Usado para inlercambiar información de control
Usado para solicitar información de control
Usado para recuperación; Resets N ( A ) y N ( S )
Usado para idontidad de peliclones I reportos y estados
inlercambio de campos de Información idbntica para pruebas
Recepción de reportes de tramas inaceplables
Tabla 1. Comandos (C) y respuestas (R) HDLC. F = Función ( C 6 R).
Tramas de información. La operación básica HDLC involucra el intercambio de tramas
de información (trama-I) que contienen los datos del usuario. Cada trama-I contiene el número
de secuencia de la trama transmitida así como un reconocimiento positivo. El reconocimiento
es el número de secuencia de la próxima trama esperada. Un tamaño máximo de 7 o 127 es
permitido.
La trama-I también contiene un bit de P/F (EncuestalFinal). El bites de encuesta (poll) para
comandos (de la primaria) y es un bit final para respuestas. En el modo de respuesta normal
(NRM), la primaria utiliza la encuesta para dar permiso de
transmitir poniendo el bit a I y la
1
22
Implementación
de
un shell remoto
secundaria pone el bit final a 1 en la última trama-I de su respuesta. En el modo asíncrono de
respuesta (ARM), el bit P/F se utiliza algunas veces para coordinar el intercambio de tramas-U
y tramas-S.
Tramas de supervisión. La trama de supervisión (trama-S) es utilizada para control de
Selectivo. El primero se usa
flujo y errores. Se permiten tanto ARQ Selectivo como ARQ No
poco debido a los requerimientos de memoria. Una trama puede ser reconocida positivamente
con Listo para Recibir
(RR)
cuando no está disponible una trama-I para realizar un
Piggybacking. Además, un No Listo Para Recibir (RNR) se utiliza para aceptar una trama pero
pedir que no se envíen más tramas hasta que se utilice un RR subsecuente.
'
Un bit P/F en una trama supervisora se puede usar como sigue: la primaria puede prender
el bit P en una trama RR para explorar la secundaria. Esto se hace cuando la primaria no tiene
tramas-I para realizar el acarreo a cuestas de la exploración. La secundaria responde con una
trama-I si la tiene; de otra manera, envía un RR con el bit F prendido para indicar que no tiene
datos que enviar. La primaria (estación combinada) puede prender el bit P en el comando RNR
para solicitar el status de una estación secundariakombinada. La respuesta será un RR con el
bit F prendido si la estación puede recibir tramas-I, y un RR con el bit F prendido si la estación
está ocupada.
Tramas no numeradas. Lastramas no numeradas se utilizan para una variedad de
funciones de control. Como el nombre indica, estss tramas no llevan números de secuencia y
no alteran la secuencia o el flujo de las tramas-I numeradas.
Se pueden agrupar estas tramas en las siguientes categorías:
1. Comandos y respuestas de selección de modo.
2. Comandos y respuestas de transferencia de información.
3. Comandos y respuestas de recuperación.
4. Comandos y respuestas varios.
Estos comandos son transmitidos por la estación primariakombinada para inicializar o
cambiar el modo de una estación secundariakombinada. La estación secundariakombinada
reconoce y acepta respondiendo con una trama de recorlocimiento no numerada (UA); el UA
tiene puestoel bit F al mismovalor que el bit P recibido. Una vez establecido, el modo
permanece en la estación secundaria hasta que el próximo comando de selección de modo
sea aceptado y en la estación primaria hasta que el próximo comando de selección de modo
sea aceptado o transmitido y reconocido.
Comandos de selección y modo. Los comandos SNRM,SNRME, SARM, SARME Y
SABME se explican por sí mismos. Después de aceptar el comando, los números de
secuencia de las tramas-I en ambos sentidos se inicializan en cero. El comando SIM (de
Inicialización de Modo) se utiliza para que la estación secundariakombinada direccionada
inicie un procedimiento de estación específico para lnicializar sus funciones de control de
enlace de datos (esdecir,
aceptar un nuevo programa o actualizar los parámetros de
operación). Mientras que en el modo de inicialización la información se transmite utilizando
tramas de información no numerada (UI). El comando DISC (Desconectar) esutilizado para
Universidad Autónoma Metropolitana. Unidad dztapalapa
23
CaPítulo 1
informar a la estación direccior;ada quela
operación.
estación transmisora está suspendiendola
Además de UA, existen varias respuestas relacionadas con el establecimiento del modo. La
respuesta DM (Desconectar Mado) se envía en respuesta a cualquier comando para indicar
que la estación que responde está lógicamente desconectada. Cuandose envía en respuesta
a un comando de establecimiento e modo, DM se utiliza para rechazar modorequerido.
La respuesta RIM (Requerimiento deModo de Inicialización) se utiliza en respuesta a un
comando de establecimiento demodo cuando la estación no está lista y desea inicializarse. La
respuesta RD (Requerimiento de Desconexión) es utilizada para requerir desconexión de un
enlace lógico.
Comandos y respuestas de transferencia de información son utilizados para el intercambio
realiza
principalmente a través de los
de . información entre estaciones. Esto se.
comandoshespuestas no numeradas de información (UI). Ejemplos de tramas de información
UI son las interrupciones operacionales, status de alto nivel, la hora del día y parámetros de
iniciaiización de enlace. El comando UP (de Petición no Numerada) se utiliza para solicitar una
respuesta
no
numerada,
como
una
manera de establecer el estado de la estación
direccionada.
Comandos y respuestas de recuperación. Se utiliza cuando el mecanismo normal
ARQ nose aplica o no trabaja. La respuesta FRMR (Trama .Rechazada) es utilizada para
reportar un error en una trama recibida, tal como:
1. Campo de control válido.
2. Campo de datos demasiado largo.
3. Campo de datos nopermitido con el tipo de trama recibida.
4. Conteo recibido no válido (es decir, se reconoce una trama que no ha sido enviada).
El comando RSET es utilizado para limpiar la condición FRMR. RSET indica que la estación
transmisora reinicializa su número desecuencia de envío, y la estación direccionada debe
hacer lo propio con su número de secuencia de recepción.
Miscelheos. Finalmente, existen dos comandos/respuesta que no encajan en ninguna
categoría. El comandohespuesta XID(deIntercambio de Identificación) es utilizado por dos
estaciones para intercambiar identificación de estaciones, así como las características de
Un comando TEST debe ser enviado con una respuesta TEST a la mayor brevedad. Esto
es una forma de probar que el enlace y la estación direccionada aún están funcionando.
24
"
.
-.
.
.
. .-. ~)_.._
...~
l
_
l
"
"
.. ...
.
DESCRIPCIóN Y VALIDACIóN DE PROTOCOLOS
Cuando surgió la necesidad de conectar a las computadoras en red, los diferentes
fabricantes de equipos comenzaron proponiendoqsus propias arquitecturas, pero pronto se
comprendió el alcance limitado de estas soluciones, pues sólo garantizaban la interconexión
entre equipos de la misma marca.Latareadenormalizar
la comunicación incluye a los
protocolos y comprende una metodología de diseño, descripción y verificación. Claramente,
para diseñar y describir un protocolo se debe utilizar un lenguaje que permita expresar los
criterios de construcción y por otro lado, sirva para verificar la consistencia y validez del
modelo desarrollado. Igualmente es importante esta etapa de especificación porquepuede
facilitar la realización de los programas que ejecuten los protocolos.
Se pueden agrupar los métodos formales para la descripción de protocolos en tres
categorías que son las siguientes:
1. Modelos de transición. Tales como los modelos de las máquinas de estados finitos
(simple y extendida) y las Redes de Petri.
2. Lenguajes orientados al modelado. Incluyen lenguajes formales y lenguajes de
programación. En esta categoría se pueden incluir los modelos basados en expresiones
regulares, en lógica temporal, y las álgebras de procesos.
3. Modelos híbridos.Que son una combinación de los dos tipos anteriores.
A partir de la necesidad de definir un formato común para la especificación de protocolos en
los documentos de normalización, se han completado tres lenguajes o técnicas de descripción
formal (FDT: Técnicas
de
Descripción
Formal),
pue
se aceptan como referencias
universales:
1. SDL
2. LOTOS
3. ESTELLE
El Lenguaje de Especificación y Descripción (SDL) fue desarrollado por los grupos de
estudio SGX y SGXl del CCITT. Está pensado para la especificación y el diseño de sistemas
de telecomunicación, como los conmutadores telefónicos. El estudio se inició en 1968. La
primera versión se presentó como la recomendación Z101-Z104 de CCITT y las versiones
revisadas se publicaron en 1982 y 1985. La versión final se aprobó en 1987. En SDL una
especificación puede presentarse en dos formas equivalentes: de manera gráfica o en forma
de texto. Podemos decir que SDL es en realidad un modelo híbrido.
El Lenguaje para Especificaciones de Orden Temporal (LOTOS) es una contribución de
IS0 (TC97/SC2l/WGl). También se le llama un álgebra de procesos. Se basa en el Cálculo
de Sistemas Comunicantes desarrollado por Robin Milner en la Universidad de Edinburgh. El
objetivo de las álgebras de procesos es la especificación formal del comportamiento d6 los
procesos, en un nivel de abstracción muy alto. Las álgebras definen un conjunto de reglas de
transformación y relaciones de equivalencia que ofrecen un criterio formal deanálisis de
25
.
Capitulo 1
comportamiento entre procesos. La primera versión de LOTOS, lS8807, se dio a conocer en
febrero de 1989.
ESTELLE (Lenguaje de Máquina Finita Extendido) es una técnica de descripción formal
propuesta por el mismosubgrupode IS0 (TC97/SCZl/WGl). Un total de 3 subgrupos del
WGI han estado activos desde 1981 estudiando el tema. El lenguaje ESTELLE se basa en el
concepto de máquina de estados finitos extendidos. Su primera versión, IS9074 se presentó
en julio de 1989.
Tanto LOTOS como ESTELLE pertenecenal segundo tipo de modelos, definen un lenguaje
formal pero, al mismo tiempo, disponen de compiladores para generar el código ejecutable de
los protocolos que describen.
El compilador de ESTELLE puedegenerar una representaciónintermedia como máquina de
estados finitos extendidos o como red dePetri.
LOTOS es la única técnica de descripción formal de las tres quetambiénaborda
-el
problema de diseño, al menos en forma parcial. El problema de la verificación completa de los
protocolos a nivel de diseño ha ocupado a
los científicos de la computación en los últimos
años y representa una frontera del conocimiento. En su estado actual ninguna FDT puede
garantizar la verificabilidad de un protocolo.Tanto LOTOS como SDL, por ejemplo, pueden
especificar sistemas infinitos que pueden conducir a problemas formalmente
indecibles.
PROTOCOLOS DE INTERNET
En 1968 la Agencia de Proyectos de Investigación Avanzada del Departamento de Defensa
de los Estados Unidos (ARPA), contrató a la empresa de consultoría Bolt Bernak & Newman
paraque desarrollara unaredde
computadoras (ARPANET), que uniera a los centros de
investigación donde tenía proyectos financieros. En un principio se instalaron nodos enla
UCLA,laUniversidad
de California enSan Bernardino, el Instituto de Investigaciones de
Stanford y la Universidad de Utah. Para 1971 la agencia asumió la drrección del proyecto. De
los primeros trabajos que se completaron se instaló un protocolo, el programa de control de
redque evolucionaría hasta convertirse, dosaños más tarde en el Protocolo de Control de
Transmisión y el Protocolo Internet (TCP/IP). Por estas fechas se empezaron a implantar en
En 1983 se estableció como
lascomputadoras de la red los protocolos delaserieTCP/IP.
requisito de conexión en ARPANET eluso de esta familia de protocolos.
Quizá unade las medidas más importantes en torno a TCP/IP fue la decisión de
implantarlos basados en el sistemaoperativoUNIX.De
igual importancia fue la decisión de
liberar el código y designar a la Universidad de California en Berkeley como su distribuidor.
Debido a que los protocolos de la serie TCP/IP tienen un carácter público, estos se
extendieronrápidamente
entre las universidades, centros de investigación y empresas
entre
privadas hasta llegar a convertirse en el estándarparacomunicacióndedatos
26
Implementación
de
un shell remoto
computadoras
operando
bajo UNIX. En la actualidad las operaciones
de
la
red
son
coordinadaspor
la organización Internet que gestiona millones denodosdeacceso
y
comercializa sus servicios en todo el mundo.
Junto al modelo OS1 que se espera conduzca en el futuro, los desarrollos internacionales en
materia de protocolos, encontramos al modelo TCPIIP probado en la práctica y que ha sido el
modelo de facto de las comunicaciones. Ambos persiguen objetivos semejantes y se basan
en el concepto del protocolo. No obstante, existen diferencias fisiológicas y prácticas
importantes entre ellos.
El Departamento de la Defensa de los Estados Unidos (DOD) normalizó un conjunto de
protocolos de comunicación y optó por desarrollar sus propios protocolos y arquitectura en
lugar de adoptar los estándares internacionales por tres razones:
1. Los protocolos del modelo TCP/IP se especificaron y tuvieron una difusión anterior a la
normalización de OSI: Debido a las necesidades inmediatasdel proyecto ARPANET, era
inútil esperar la aparición de normas reconocidasinternacionalmente.
2. Losrequerimientos específicos decomunicacionesen
el modeloTCPIIP, tienen un
mayor impacto en el diseño de protocolos y en la arquitectura. Esta característica ofrece
facilidades para la implantación que no se encuentra en otros modelos.
3. Existen diferencias filosóficas con respecto ala naturaleza apropiada de una arquitectura
de comunicación ysus protocolos.
DIFERENCIAS ENTRE EL MODELO OS1 Y TCP/IP
Hay 4 diferencias fundamentales:
1. El concepto de jerarquía contra el de nivel.
2. La importancia que cada modelo concede ala interconexión de redes.
3. La utilidad de servicios no orientados a conexión.
4. El enfoque para funciones de administración.
El modelo TCP/IP reconoce que el trabajo de la comunicación es muy complejo y diverso
paraque se realice poruna sola unidad. Enconsecuencia éste se divide enmódulos o
entidades cooperantes que soportan en conjunto un servicio distribuido. Una buena práctica
de diseño de sistemas dicta que esas entidades serqn arregladas jerárquicamente (es decir,
ninguna entidad usasus propios servicios directamente).
El modelo OS1 reconoce además,que
los protocolos dela
misma jerarquía tienen
características en común que se pueden agrupar en un solo nivel o capa.
La objeción algunas veces incrementada por los diseñadores del modelo TCP/IP es que el
modelo OS1 es prescriptible más que descriptivo. Esto es dicta que los protocolos dentro de un
nivel dado ejecuten ciertas funciones, lo cual no es siempre deseable. Es posible definir más
27
Capítulo 1
de un protocolo de la misma jerarquía y la funcionalidad de ellos puede no ser igual o siquiera
semejante. Algo que es común acerca de un grupo de protocolos es que pueden compartir el
mismo conjunto de protocolos de jerarquía inferior.
En lo queconciernea
mencionarse que:
las relaciones entre niveles,quese
presentanen
OSI, pueden
1. La entidad de nivel (N) puede intercambiar datos usando los servicios de la entidad del
nivel (N-I). Otraformade
decir estoesque
la entidad del nivel (N-I), debeestar
implicada en cada transferencia de datos deentidad de nivel (N).
2. La entidad del nivel (N-I) da servicio intercambiando datos que, contienen información
de control y de datos de entidad (N). Por su lado en el modelo TCPAP se permiten las
siguientes operaciones:
los servicios de otra jerárquicamente más baja,
aún sin ser adyacentes.
2. Puede utilizarse caracteres de escape para colocar caracteres de control dentro de una
cadenade datos. Esta situación no sedescribe completamente en OS1 dentro del
concepto de unidad de datos deprotocolo.
3. Pueden separase las trayectorias de control y de datos. Con estos se ofrecen diferentes
servicios para cada tipo de conexión.
4. Jerarquías superiores. Por ejemplo el cierre de una conexión en una entidad baja puede
implicar la clausura de una conexión isomorfa en una jerarquía superior sin requerir que
está ultima pase la información de control.
5. Se permite la cooperación de múltiples de entidades de la misma jerarquía. Por ejemplo,
un protocolo de aplicación puede emplear los servicios de otra entidad en el inicio de una
secuencia
de
transferencia de datos, pero no requerirla después
de
iniciar
la
transferencia y por otro lado, hacer uso de otra nueva.
1. Una entidad puede usar directamente
Una diferencia histórica entre el modelo TCP/IP y el OS1 es la importancia que el primero
concede a la interconexión. La interconexión ocurre cuando dos sistemas de comunicación no
están unidos a la misma red. Así los datos transferidos deben atravesar al menos dos redes
que, además pueden ser distintas.
Los requisitos de interconexión entre redes se manejan por un protocolo. Los documentos
actuales de OS1 hacen una breve referencia a la posibilidad de redes de tándem y consideran
un protocolo entre redes como un subnivel de la red. Esta no es una solución clara, pero es la
única posible dentro de la arquitectura de los 7 niveles.
Un servicio sin conexión como sunombre lo indica, es aquelen el que los datos se
transfieren deuna entidad a otrasin
quele procedael
establecimiento de un camino
dedicado.En el modeloTCP/IP tienen igual importancia losservicios sin conexión y los
servicios orientados a conexión, mientras 'que el modelo OS1 esta expresando solamente en
términos deestos últimos. Eluso principal del serviciosin conexiónen TCP/IPes en la
interconexión entre redes, ya que no es seguro suponer que todas las redes intermedias son
confiables, como para construir una ruta dedicadacomo pordondepueda transferirse una
secuencia ds datos.
Una diferencia final entre el modelo TCP!IP y OS1 es la forma en la cual son tratadas las
28
Implementación
un
de
shell remoto
funciones de administración. Ejemplo de tales funciones son la designaciones, el control de
acceso y la contabilidad de los recursos de la red. En el modelo OS1 estas se clasifican por
nivel y se localizan como tareas de administración en cada uno. El modelo TCP/IP no excluye
este enfoque,pero va más lejos. Desde el puntode vista de TCP/IP, muchasdeestas
funciones pueden ofrecerse a través de un protocolo de tipo "sesión". Este enfoque refleja el
hecho de que esos protocolos usan servicios de transporte.
ORGANIZACIóN DE TCPllP
,
El modelo TCP/IP puede describirse por la interacción de 3 agentes: procesos, anfitriones
y redes. Los procesos son las entidades fundamentales de la comunicación y se ejecutan en
los anfitriones (estaciones) que pueden soportar varios procesos simultáneos. La
comunicación entre procesos se lleva a través de redes a las que se conectan los anfitriones.
Los tres conceptos constituyen un principio fundamental del modelo:la transferencia de
información a un proceso se realiza primero, llevándola al anfitrión donde reside el proceso
fuente, el anfitrión leentregaa la red que la hace llegar hasta al anfitrión final donde es
ofrecida al proceso de destino. La red se ocupará del direccionar de datos entre los anfitriones,
mientras estos acuerdencomo dirigir los datos a sus procesos.
El modelo organiza a sus protocolos en 4 niveles. Aquí se enfatiza que el hecho importante
es el ordenamiento jerárquico de los protocolos, la designaciónde niveles solo sirve para
este contexto no tiene
conducir la exposición y poder establecer comparaciones. Fuera de
sentido hablar de niveles en TCPAP, no por lo menos como se entienden el OSI. Así pues los
4 niveles del modelo son:
1.
2.
3.
4.
Nivel acceso a red.
Nivel Internet.
Nivel anfitrión-anfitrión.
Nivel proceso/aplicación.
Nivel acceso a red. Este nivel comprende aquellos protocolos que gestionan el uso de
los servicios en red y residen en un anfitrión o su equivalente lógico. Una función de todos
estos protocolos es el de direccionar los datos entre IT anfitriones que pertenecen a la misma
red.
Otros servicios que ofrecen son el de control de flujo y errores entre anfitriones, así como
varías características de calidad de servicio como prioridad y seguridad. Una entidad a nivel
red se invoca regularmente por una entidad de nivel Internet o de nivel anfitrión-anfitrión, pero
también puede invocarse desde unaentidad a nivel proceso /aplicación.
Nivel lnfernef. El nivel Internet soporta los procedimientosquepermiten el tránsito de
datos a través de múltiples redes. Así, este debe proporcionar una función de direccionar. Los
protocolos se implantan entre los anfitriones y los puentes.
Un puente es un procesador que conecta a dos redes y garantiza el flujo de datos entre
estos.
Universidad AutónomaMetropolitana. Unidad lztapalapa
29
Capítulo 1
Nivel anfifrión-anfitrión. Este nivel contiene los protocolos con capacidad para enviar
datos entre dos procesos en diferentes anfitriones. Pueden ofrecer una conexión lógica entre
entidades de alto nivel. Otros posibles servicios incluyen control de errores, flujo y la capacidad
de manejar señales decontrol no asociadas conuna conexión lógica de datos. Son necesarios
4 tipos de protocolos generales en este nivel, cada uno tiene diferentes requerimientos de
servicio:
Un protocolo de datos. Orientadoaconexión
caracterizado por la necesidaddeuna
entrega confiable de datos. Muchasaplicaciones de procesamiento de datos puedenusar este
servicio.
Unprotocolo para datagramas. Son protocolos de mínima funcionalidad que puede ser
apropiados, para algúntráfico, particularmente aplicaciones que no se orientan a conexión.
Un protocolo de lenguaje. Se caracteriza por la necesidad de manejar un flujo constante
de datos con unavariación mínima de retardo.
Un protocolo de datos en tiempo real. Tiene las características del protocolo orientado a
datos y del protocolo de lenguaje.
Nivel
proceso/ap/icación. Comprende protocolos - para compartir recursos(i.e.
computadora a computadora)y garantizar acceso remoto (¡.e terminal a computadora).
-
~
La Figura 9 representa el modelo de la arquitectura TCPAP y varios de sus protocolos más
importantes. La manera en que se apilan las capas del modelo puede variar dependiendo de
las necesidades de los usuariosde la red y de las decisioneshechaspor los diseñadores.
Nótese que están normas encajan en los 3 niveles superiores a la arquitectura. Los protocolos
que descansansobreTCP (y UDP) sonejemplosde
nivel de aplicación. Por su parte los
protocolos de los 2 niveles inferiores garantizan el acceso a los medios físicospara
la
transmisión de la información y pueden implantarse con una amplia selección de normas y
protocolos. Los sistemas pueden tener interface con una gran variedad de redes. De un modo
general TCP/IP confiará en los estándares nacionales e internacionales a este nivel, tal como
X.25 para paquetes conmutados en redes de gran cobertura geográfica, así como IEEE 802
para redes locales.
Son muchos los que piensan que la serie TCPAP es un enfoque más viable por un cierto
número de razones. Primero por que ha demostrado que funciona, segundo porque hay un
gran númerodeproductosenelmercadobasadosen
TCPAP, tercero porque es fácil el
acceso a su documentación y finalmente porque está asociado con UNIX.
Frente a los partidarios de TCPAP se encuentran los convencidos de OSI, que insisten en
sus bondades. En todo caso no se discute la operatividad de este, por lo menos en los niveles
inferiores, donde la misma serie TCP/IP puede confiar el acceso a red, en protocolos como X.
25 (redes publicas deconmutación
de paquetes) o Q.931 (Red Digital de Servicios
Integrados (RDSI)) estructurados con el enfoque de OSI. También es cierto que el modelo de
7 capas vino a marcar una direcci6n en la comprensijn del problema de las arquitecturas de
30
Implementación
de shell un
remoto
red. Remarcamos que en OS1 no se describen como deben hacerse las cosas en cada nivel, si
noquecosasdebenhacerse.
Esdecir, clasifica las tareas del sistema. OS1 no es una
implantación, debeentenderse como un "lenguaje informal" de descripción deredes de
telecomunicaciones. Hablamos de un lenguaje porque el modelo designa la terminología con
que se aborda el diseño. Decimosquees
informal para diferenciarlos de las técnicas de
descripción formal como ESTELLE, LOTOS ó SDL. En contraste TCPAP es una implantación.
PRESENTACIóN GENERAL
Como su nombre lo indica, el concepto Internet, busca el interconectar redeshaciendo
posible, a priori, la comunicación entre dos máquinas cualesquiera. Esto supone la existencia
de máquinas bisagra, llamadas pasarelas (gateway), que aseguran,el enlace entre redes. Ver
Figura 7.
Pasarela I
Pasarela 2
Figura 7. Concepto Internet de interconexión de redes.
N direccionarniento. Las redes interconectadas no tienen ninguna razón para disponer
del mismo mecanismo de direccionamiento de los diferentes nodos. Por tanto, es necesario
dar una dirección lógica acada máquina huésped (cualquier computadora que se conecta a
una red. Puede ser desdeuna micro hastaunasupercomputadora).
Constituida poruna
dirección de una red y por una dirección de una máquina en la
red, se forma la dirección
Internet (Internet esla colección deredes ypasarelasque utilizan la serie de protocolos
TCP/IP y funcionan como una red virtual simple y cooperativa). La dirección Internet completa
de una máquina ocupa 32 bits, la de red 8, 16 ó 24 bits sobre estos 32, según la importancia
dedicha red (entérminos del número de máquinas que la componen). En general, las
direcciones se dan bajo la forma nl,n2.n3.n4 (cada ni es el valor de un octeto).
Aunqueen
el cuadrode
utilización de protocolos Internet yde
su mecanismode
direccionamiento en una red local no abierta al exterior (es decir, sin pasarela a otra red) es
posible elegir una dirección cualquiera, no ocurre así si existe una pasarela. Entonces hay que
dirigirse a un organismo central para que ébte suministre una dirección a una red (NIC: Cenfro
de Control de información de Red).
Dos identificaciones de la máquina tienen una interpretación particular, cualquiera que sea
la importancia de la red:
1. La dirección nula permite hacer referencia a la red o a la máquina actual.
2. La dirección donde todos los bits son iguales a 1 permitedesignar elconjuntode
máquinas.
ÉSta última se utiliza para direccionar un mensaje a todasias máquinas de la red. (Difusión
o broadcast).
1
31
Las redes pueden ser de las clases A, B o C. Las redes de clase A son las de tamaño
grande; el primer octeto tiene asignada la dirección de la red y las máquinas son identificadas
con los siguientes tres octetos. La red ARPANET de dirección 10.0.0.0 es una red particular de
tipo A. En las redes de clase 6, los dos primeros octetos de la dirección se ocupan designar la
dirección de la red, mientrasque los dosúltimos contienenla dirección de la máquina.
Finalmente las redes de clase C designan la dirección de la red con los tres primeros octetos, y
la de la máquina con el último octeto. Ver Figura 8.
c
Las direcciones Internet aparecen como números enteros (largos en el sentido del lenguaje
C). Donde la representación de estas cantidades es variable de una máquina a otra en lo que
concierne al orden de escritura de los bits. Para simplificar, podemos imaginar que se escriben
imaginar
de izquierda aderecha b0bl...b31 (notación Liffle Endian). Igualmentesepueden
variaciones en lo que concierne al orden delos octetos.
La notación elegida a nivel de los protocolos Internet es la Big Endian (b31b l...bO). Por tanto,
es particularmente importante
en
los intercambios el efectuar la conversión
de
la
representación local a la de red antesdehacer
elenvío, y laconversión inversa tras la
recepción.
-
-
(a) Clase A.
O
I
I
7 8
31
_ .
Dirección de la red I
Identificación de la máquina
(b) Clase B.
O
1
15 16
31
I
I
Identificación de la máquina
Dirección
red la de
tc) Clase C.
o
23 24
31
1 2
I
I
I
I
Dirección de la red
Identificación
máquina
la de
1
Figura 8. Las diferentes clases de redes (direcciones).
Arquifecfura. En la Figura 9 siguiente se representa la arquitectura en niveles Internet y la
relación que se puede establecer entre ella y los diferentes niveles del modelo OSI.
-
=n los párrafos siguientes se estudiaran en detalle estos diferentes niveles. En lo referente
32
Implementación
un
de
shell remoto
al nivel base, hablando con propiedad, no forma parte de los protocolos de la familia Internet.
Aquí, se encuentran los protocolos relativos a los nivelks físicos.
I
I
Internet
Niveles
Aplicación
Presehtación
I
Aplicaciones
~
I
TCP
I
I
UDP
I
I
Niveles OS1
5
Sesión
Transporte
I
Figura 9. Arquitectura Internet comparada con el modelo OSI.
LOS INTER.FACES IP
Aquí se asegura la gestión de los protocolos específicos a cada tipo de red física. Uno de
los papeles que les incumbe es la fragmentación de los mensajes que se van a emitir. Se trata
de dividir los mensajes para enviarlos mediante unatrama física (ver el inicio de este capítulo).
A continuación se trazan los rasgos generales de los tres interfaces principales.
N inferfacelP/Efhefnet. Se tienen queañadirdos
protocolos específicos afinde
encontrar la dirección física Ethernet (se analiza posteriormente) correspondienteauna
dirección Internet o a la operación inversa. Evidentemente esta dirección física es necesaria
para realizar las comunicaciones. El protocolo ARP (Protocolo de Resolución de Dirección)
Y , cuya
funciona bajo una idea simple:si una máquina X quiere comunicarseconuna
realmentecon ella, se ha
dirección física, o bien ya conoce (comoyasehacomunicado
encontrado en la segunda situación, ha obtenido su dirección física y la conservado en una
tabla), o bien sólo conoce su dirección Internet I,. Entonces el interface envía a la red una
trama Ethernet de difusión (dirección del destinatario constituida de 48 bits iguales a 1) de un
tipo convenido, que contiene la dirección Internet de la máquina Y y las direcciones Internet y
Ethernet de la X. Y reconocerá su dirección Internet y enviará a X un mensaje de respuesta
que contiene su dirección Ethernet (este mensaje también tiene un tipo específico). Por otra
parte, el protocolo RARP (ARP en Reversa) permiteque una estación sin disco queno
reconoce su propia dirección Internet, la pida mediante la difusión de un mensaje Ethernet de
un tipo especificado. Sólo una máquina (servidor RARP) está autorizada para responder a un
mensaje de este tipo.
El interface lPM.25. Esta interface divide los paquetes de 576 octetos enviados por el
protocolo IP en paquetes de 128 octetos que es el tamaño máximo de paquete enX.25.
El interface SLlP (Protocolo Internet Local Rápido). Permite utilizar los protocolos
de la familia Internet en líneas asíncronas dirigidas por el protocolo RS-232N.24.
33
Capítulo 1
EL PROTOCOLO IP
Se trata de un protocolo del nivel de la red para intercambio de datagramas en modo no
conectado:
por
tanto, no garantiza la llegada a
buen
puerto de los mensajes. Esta
funcionalidad se introducirá en el nivel superior cop el protocolo TCP.
A continuación se dan las principales funciones y características.
Los datagramas /P. Undatagrama IP es launidadde transferencia a este nivel. El
protocolo especifica el formato de un objeto de este tipo, constituido esencialmente, por un
encabezamiento que permitesu identificación y por los propios datos.
Estedatagrama, al bajar a los niveles inferiores, será encapsulado en unatrama física
(eventualmente el módulo del interface tiene que dividir el datagrama): el datagrama completo
constituirá la parte dada de una trama (el resto está constituido por diversas informaciones
específicas sobre el protocolo físico utilizado).
Entre las informaciones que se encuentran en elencabebamiento figuran las necesarias
para el control de la fragmentación: en efecto, un mensaje que proviene del nivel superior al IP
tiene que ser dividido en varios datagramas. Por tanto, el encabezamiento tiene que contener
las informaciones que permiten la reconstrucción de un mensaje apartir de los fragmentos que
lo constituyen.
Además, los datagramas que "navegan" por la red contienen un campo destinado a evitar
que lo hagan indefinidamente.
1
A fin de poder multiplexar los mensajes IP entre diferentes protocolos del nivel superior, a
los datagramas correspondientes se les da un tipo de la misma manera que el tipo de una
trama Ethernetpermiteencaminar,
informaciones que contiene.
hacia el módulo correspondiente (IP-ARP-RARP), las
E/ direccionamiento de /os datagramas. En el momento que una máquina tiene que
comunicarse con otra que no pertenece a la misma red (y, por tanto, inaccesible directamente
mediante una trama que encapsula la trama IP), es necesario hacer transitar los mensajes por
una o varias pasarelas. Toda máquina puede saber si la máquina destinataria pertenece a la
mismaredcomparando
la dirección Internet de la red de dicha máquinacon la suya. El
algoritmo de direccionamiento de Internet se basa en las tablas de direccionamiento que se
gestionandinámicamenteencada
máquina pormediacióndemensajes
difundidos por las
pasarelas.
34
lmplementación
de
un shell remoto
LOS PROTOCOLOS DEL NIVEL DE TRANSPORTE
Los dos protocolos (protocolo UDP y protocolo TCP) del nivel que se va a presentar tienden
a permitir la comunicación entre actividades (procesos)sobre
máquinas distantes. Una
actividad tal constituye un punto de entrada en el sistema.
Para saber dialogar con ella, es
necesario poder designarla. En el concepto Internet, evidentemente es necesario permitir el
diálogo entre actividades en sistemas diferentes. Comola designacióndeprocesosdeun
sistemaa
otro es diferente se hace indispensable definir un métodode
identificación
independiente de los sistemas. El principio consiste en separar la identidad del proceso que
realiza una función de la propia función; la noción ‘de servicio es privilegiada con respecto a la
de proceso. Una última ventaja consiste en permitir reiniciar un proceso servidor cuando el
servidor iniciado previamente ha terminado accidentalmente.
El concepto Internet correspondiente es el de puerto. Para cada uno de los dos protocolos
de transporte existe un conjunto de puertos identificados mediante un número entero. A cada
aplicación Internet estándar le correspondeun número de puerto específico. Por tanto, los
módulos TCP y UDP realizarán el multiplexado por mediación de los números de los puertos.
El protocolo UDP (Protocolode Datagrama de Usuario)
Caracferísticas generales. Permite que una aplicación envíe mensajes a otra en modo
datagramanoconectado.Proporciona
el mismotipodeservicioque
el protocolo IP y, por
su destino. En
tanto, no garantiza de manera alguna, la llegada del mensajeenviadoa
particular, no
hay
algún
mecanismo de
entrega
ni de control de flujo en
caso
de
“embotellamiento”
de
la máquina receptora, integrado en el protocolo. Por tanto, los
datagramas corren el riesgo de perderse o de llegar en un orden arbitrario.
Un datagrama UDP, que será encapsulado en uno I r , en particular contendrá los números
del puerto fuente y del de destino.
Los puerfos
reservados.
Un cierto número de
puertos
están
reservados
para
aplicaciones estándares Internet o para aplicaciones ulteriores. En principio están reservados
los números inferiores a 256 (en UNlX son los números inferiores a 1024). El resto de los
puertos utilizados para las diferentes aplicaciones serán reservados dinámicamente.
El protocolo TCP (Protocolode Control de Transporte)
Introducción. Se trata de un protocolo del nivel de transporte orientado a conexión, que
ofrece un servicio seguro de transporte de grupos de octetos; los octetos que se emiten desde
un lado de la conexión se liberan en el mismo orden del otro lado de ésta. Además, este grupo
de octetos no tiene estructura alguna. La conexión se realiza en modo dúplex; por tanto,
soporta una comunicación simultánea en los dos sentidos. El protocolo utiliza, como UDP, el
mecanismo de puerto.
35
Caracferísficas generales del protocolo. El problema principal que tiene que resolver
es el asegurar una transferencia fiable de información apoyándose en mecanismos que no lo
son. Los diferentes mecanismossubyacentes son:
1
1. Reconocimiento (acuse de recibo). Esta técnica de base consiste en esperar, antes de
emitir un nuevo paquete, la llegada de un acuse de recibo por parte del destinatario del
anterior. Si éste no llega en un lapso de tiempo dado (principio de temporización o
timeout), se retransmite el paquete. Se le otorga un número de orden a cada uno con el
fin de detectar duplicaciones de paquetes o de entregas.
2. Las ventanas deslizantes. Esta técnica es utilizada por el protocolo TCP.
Los servicios que se proporcionan. Corresponden a los diferentes valores posibles de
un'campo particular de un segmento TCP (unidad de transferencia a nivel TCP):
I
Módulo UDP
Mddulo TCP
Selección del módulo por el tipo de datagrama IP
I
I
Datagrama IP
I
Módulo
IP
Módulo RARP
Módulo ARP
Selección del módulo porel tipo de la trama
A
Trama física
Figura I O . Esquema general de funcionamiento de UDP y TCP
1. Petición de apertura de la conexión que tiene forma activa (del lado del que inicia la
conexión) y forma pasiva (dellado que es llamado).
2. La expedición con posibilidad de enviar mensajes urgentes y de forzar el envío de un
mensaje (para que se emita sin que el módulo TCP lo reagrupe con otro).
3. La recepción conla posibilidad de acceder directamente a un mensajeurgente.
4. El cierre de la conexión.
36
f.os puertos reservados. Como en el caso del protocolo UDP, se reservan un número
de puertos TCP para servicios estándares (por ejemplo ECHO {puerto 7}, FTP {puerto 2}, o
TELNET {puerto 23)).
ESQUEMA GENERAL DE FUNCIONAMIENTO
La Figura 10 siguiente recopila los mecanismos de multiplexado y selección que intervienen
entre los diferentes niveles de protocolos de Internet.
EL MODELO CLIENTE-SERVIDOR
Es el modelo de interacción más corriente entre aplicaciones en una red. Aunque, hablando
con propiedad, no forma parte de los conceptos Internet como lo forman los protocolos IP,
TCP o UDP, no porello no le corresponde un lugar aquí: todos los servicios estándares de alto
nivel propuestos en Internet funcionan según este modelo.
Un servidor es un programa que ofrece un servicio en la red, es decir, que realiza una
función específica. En ciertas circunstancias, este término designará a una máquina. Esteserá
el caso si dichamáquina está dedicadaaun servicio particular (por ejemplo, se hablade
servidor de archivos).
Un cliente es un programa que dirige a ut1 servidor una petición específica que corresponde
a una demanda de servicio.
De este modo, en el caso de aplicaciones que se comunican utilizando protocolos Internet,
se enviará una petición de un cliente a un servidor por mediación de un paquete que contiene,
en particular, un número de puerto que corresponde al servicio y el número del puerto donde
espera la respuesta. Se dedicará más adelante, un capítulo entero al modelo cliente-servidor.
LAS APLICACIONES
Está disponible un cierto número de aplicaciones que se apoyan bien en el protocolo UDP,
bien en el TCP. Se les puede dividir en tres categorías:
1. Servicios estándares disponibles en toda implantación de Internet.
2. Servicios generales disponibles, potencialmente, en toda implantación.
3. Servicios específicos de UNIX.
1
37
I
Los servicios estándares
Transferenciadearchivos.
El protocolo FTP (Protocolo qle Transferencia
de
Archivos) es el protocolo de transferencia interna de Internet. Permite establecer una sesión
de transferencia de archivos entre dos máquinas bajo sistemas diferentes. La seguridad está
asegurada por mediación de identificaciones y palabras de paso en los dos sistemas. Permite
ejecutar diferentes órdenes en cada uno de los sistemas (contenidos de directorios, copias de
archivos en los dos sentidos con conversiones eventuales). Este servicio se apoya en el
protocolo TCP.
También está disponible un protocolo simplificado adaptado a la transferencia de pequeños
archivos apoyándose en el protocolo UDP.Se trata de TFTP (Protocolo de Transferencia de
Archivos Simple).
Correo electrónico. El protocolo SMTP (Protocolo de Transferencia de Correo Simple)
permite el intercambio de correo entre máquinas distantes. Este protocolo está constituido
sobre el protocolo TCP para establecer un enlace entre los procesos de las dos máquinas
entre las que se tiene que intercambiar el correo. Especifica el formato de los mensajes
intercambiados.
Terminal virtual. La función “terminal virtual” se reqliza a través del protocolo TELNET
(Protocolo de Terminalde Red) que permite hacer de un terminal físicamente conectado a un
sistema dado, un terminal “lógico” de otro y de esta manera trabajar de forma remota en otro
sistema. La implantación de este protocolo sobre un sistema supone que dispone del concepto
de pseudoterminal (punto de entrada en un sistema simulando un terminal).
Los servicios generales
I
Los protocolos XDR/RPC/NFS. Estos tres protocolos, corresponden a los niveles de
aplicación, presentación y sesión respectivamente. El objetivo del protocolo NFS (Sistema de
Archivos en Red) consiste en permitir la repartición de archivos en la red independientemente
de los sistemas de gestión de archivos. Este protocolo se basa en una representación
y un mecanismo
estándar de los objetos (protocolo XDR {Representación de Datos Externa})
de llamada a procedimientos remotos (protocolo RPC {Llamada Procedimientos
a
Remotos}).
38
....lll__
_.””””
-
~ . ...~...
Los sisfemas mulfivenfana. Los protocolos X-Window de MIT y News de Sun se basan
en protocolos Internet y permiten la gestión de ventanas en pantallas bitmap en una red.
Otros servicios. Servicios tales como t a l l . : o
finger
permiten el diálogo entre usuarios
o la obtención de informaciones sobre un usuario dado de una máquina huésped.
Los servicios UNlX
Junto a estasdoscategorías
de servicios, que son accesiblessobre todo sistema que
soporte los protocolos Internet, se han desarrollado otro cierto número para el entorno UNIX.
. Estos servicios, se presentan a los usuarios bajo la forma de órdenes remotas como r l o g i r l
(permite hacer una conexión a distancia sobre una máquina dada), rsh (permite la ejecución
de unaorden
shell en la máquina designada), rwho (permitever
la lista de usuarios
conectados a la(s) máquina(s) de la red), etc.
' REDES DE ORDENADORES
Prentice Hall I-lispanoamericana S.A. [ I 9911
Andrew S.Tanenbaum
Págs. 2, 5, 11-12, 31-34.
COMUNICACIONES EN UNlX
McGraw-Hill [1992]
Jean-Marie Rifflet
Págs. 192-201.
LAS REDES DE COMPUTADORAS
Monografía [I9941
Ricardo Marcelín Jiménez
Orestes Téllez Analco
Rubén Vázquez Medina
Págs. 20-25, 28-32.
CONTROL DE ENLACE DE DATOS
Mollografía [I 994]
Ricardo Ma1cclíl1 Jirr16ncz
Págs. 7, 9-17 , 19-20, 25-33.
DISTRIEUTED OPERATING SYSTEMS
THE LOGICAL DESIGN
Addison-Wesley Publishing Company [I 9911
Andrej Goscinski
Prigs. 5-6, 44-46.
DESIGN AND VALIDATION
O í COMPUTER PROTOCOL
Prentice Hall [ I 9911
Gerard J. Holzrnann
P3gs. 32-32.
39
CAPÍTULO 2
FUNDAMENTOS DE
REDES
DE COMPUTADORAS
I
FUNDAMENTOS
COMPUTADORAS
DE
REDES
DE
[TOMADO DE Tanenbaum,Marcelín, Peterson y Coulouris]*
I
Una red de computadoras es una colección interconectada de computadoras autónomas.
Enun
principio las redesdecomputadoras
surgieron comosolucionesanecesidades
. estratégicas del conjunto limitado de organizacionesque poseían varias computadoras que
debían interconectarse, con el objetivo fundamental de compartir recursos, es decir, permitir al
usuario de cualquier terminal dentrode
la organización, acceder y utilizar todas las
posibilidades del conjunto de aparatosque constituyeran la red.
Como primera alternativa se utilizaron los medios de comunicación queya existían. En 1956
tuvieron lugar los primerosexperimentoscontransmisionesde
larga distancia para datos,
los medios
mediante líneas telefónicas. Sin embargo, pronto sevioque
estosnoeran
indicados para cursar el tipo de tráfico generado (datos, en este caso) y que presentaban
diferentes problemasde control. Seis añosmástardese
realizó la primera transmisión de
datos vía satélite (Telstat). Un satélite de comunicaciones es una estación de conmutación
de radio en órbita a 35 900 km. sobre la línea ecuatorial; viaja a la misma velocidad de rotación
de la Tierra (se dice que es geosincrónico). Por otro lado, un conmutador es un dispositivo o
estado de programa mecánicoo electrónico que puede estar en uno de dosposibles estados
Los primeros
procedimientos
de
comunicación
eran
soluciones
del
problema
de
coordinación "maestro-esclavo" entre un equipo queera
responsablede las tareas de
transferencia, recuperación, sincronización y control dela
conexión y varias terminales
pasivas. En1960,con
la conexión directa entre computadorasaparecen las redes de
computadoras propiamente dichas, con velocidades detransmisión superiores, mayor tráfico y
donde no era operante el procedimiento de coordinación usado hasta entonces.
Las primeras redes de computadoras de gran escala fueronlos sistemas de reservación de
las aerolíneas, a principios de los años 60. El sistemaSABRE deAmerican Airlines, por
ejemplo, fue construido en1961.Posteriormente
surgieron proyectoscomo ARPANET y
TYMNET a finales de la década de los 60's y CICLADES a principios de los 70's que indican
el gran interés de la comunidad de las telecomunicaciones (comunicación de información que
incluye datos, voz y video), por encontrar soluciones que permitieran interconectar máquinas
situadas a distancia, en condiciones técnica y económicamente favorables. Baste un ejemplo
como prueba de la penetración de las redes de computadoras. Desde sus inicios en 1969,
hasta1985, el proyecto ARPANET, financiado por el Departamentode la Defensade los
Estados Unidos había conectadocasi 1200 pomputadoras, su sucesor Internet, crecería de 25
O00 computadoras en 1987 aun estimado de250 O00 a fines de 1989.
La experiencia alcanzada en el campo de la Teleinformática, durante sus primeros años,
Capítulo 2
tuvo influencia importante sobre un tipo particular de redes de computadoras conocidas como
Redes de Área Local (LAN). E n éstas, se trató de optimar las ventajas que representa tener
una distancia rolativarrlonto poquciía critro equipos do córnputo. Entre los trabajos piorlcros ct1
ésta área se encuentra el proyecto ALOHA de la Universidad de Hawai que se llevó a cabo a
principios de la década de los 70's.
El auge actual delasredesde
computadoras es unaconsecuenciade
la cantidad de
pequeñasorganizaciones
que,a finales de la décadapasada, disponían deimportantes
inventarios de microcomputadoras y que representaban un mercado de grandes potenciales
comunicaciones
entre
para
poner
su
a
alcance todos los desarrollos en mbteria de
computadoras, fruto de los años anteriores.
La aplicación de la tecnologia digital para el manejo de señales analógicas, como la voz y
el video, marco un hito en las telecomunicaciones y definió la tendencia de fines de siglo en la
materia. Con la disponibilidad de nuevos métodos y el crecimiento de los volúmenes de
información que se almacenan y transmiten, surge la conveniencia de crear redes flexibles, de
gran capacidadde
transporte, que evolucionen a partir de la ihfraestructura existente,
aprovechando la capacidad instalada y de que puedan adaptarse dinámicamente incorporando
servicios básicos y de valor agregadopara la transmisión de información bajo un formato Único
independiente de la fuente. Los servicios de valor agregado son aquellos que proporcionan
servicios más allá de latransmisión normal, como la detección y corrección automáticade
errores, y el almacenamiento y despacho de mensajes.
Una razón que ha favorecido el desarrollo de las redes digitales es que la tecnología de
base ha demostradouna disminución de costos considerable en los últimos años. Además
existe un uso creciente de las computadoras y los servicios de tipo digital. S e han estudiado
diversas opciones de integración, introduciendo voz en las redes de
datos y viceversa pero,
debido a los propósitos distintos conque se creó cada tipo, se piensaen la necesidad de
aprovechar al máximo sus posibilidades actuales y emigrar gradualmente hacia nuevas redes.
Ya en 1980 varioscomités nacionales de telecomunicaciones propusieron unconjunto de
normas para el desarrollo de un nuevo tipo de infraestructura, que se espera sea la columna
vertebral delastelecomunicaciones
del futuro. No consiste en una aplicación tecnológica
particular, se trata másbien, deun accesoa los serviciosdigitales decomunicación, con
independenciadelasredes
a las que se suscriban. E s decir, garantiza una compatibilidad
internacional a niveldel interfaz deconexión.En
suprimera etapa, la RDI (Red Digital
Integrada) ofrecerá servicios de transporte de información de origen analógico o digital (voz y
datos sobretodo);en
su segundaetapa, la RDSI(Red Digital deServicios Integrados)
ofrecerá además, servicios de valor agregado relacionados con el contenido de la información
transportada y su aplicación (correoelectrónico [transmisión de memorandos y mensajes
mediante una red] y conferencia múltiple, por ejemplo), para finalmente ofrecer en su última
etapa la RDSI-BA (RDSI de Banda Ancha) servicios devalor agregado con requerimientos
técnicos superiores (videoconferencia).
Cuando un bien deconsumohacesu
aparición, pasa algún tiempo antes de quese
demuestre su utilidad y por tanto, tenga éxito. Si lo logra, su precio se determinará mediante la
oferta y la demanda; salvo algunas fluctuaciones, éste llegará a una situación estable.Sin
embargo, la aparición deunanueva
tecnologia queabarate
su costo de producción y/o
44
remoto
shell
un
Implementación
de
Fundamentos de redes de computadoras
operación producirá undescensoensu
precio y portanto será asequible paraun mayor
número de compradores, pudiéndose convertir incluso, en un bien de consumo masivo. Estas
observaciones pueden aplicarse muy bien, tanto a las computadoras, como a los equipos de
telecomunicaciones.
Si no se considera a las modernas supercomputadoras (la computadoras más veloces
disponibles) poseídas por algunos grupos de investigación
repartidos
en los países
industrializados y se piensamás
bien en las computadoras personalesque
tienen una
utilización masiva, se encontrará que, desde su aparición, el precio de éstas se redujo en tres
órdenesde magnitud, de $ I O 6 a $ I O 3 (dólares), gracias a los constantes desarrollos en la
tecnología del estado sólido y aquí se halla la causadesu
amplia difusión. Consu
abaratamiento se multiplicóelnúmero
de usuarios que tuvieron a su disposición nuevas
capacidades para manejo de la información. Todavía en los 70’s parecía cuento de ciencia
ficción la idea de tener una computadora en casa.
Aunque los precios de los equipos de telecomunichciones han descendido también, por
razonessemejantes, los cambios nohan sido tan pronunciados comoen el caso de las
computadoras, por tratarse de un mercado más maduro y en donde tradicionalmente se hacen
compras esperando que la inversión se amortice en plazos más largos. Hasta hace poco, el
costo de las redes estaba dominado por la etapa de transmisión, pero con el desarrollo gradual
de la fibra óptica (filamento de vidrio muy delgado, diseñado para la transmisión de luz, capaz
de transmitir miles de millones de bits por segundo), los costos de transmisión han descendido
y se esperaque la tendencia sigaen los próximos añoshasta llegar a ser el medio de
transmisión más utilizado y que la transmisión no represente el porcentaje más importante del
precio de la comunicación. Esto no significa que los otros medios de transmisión, como el
más
bien
en
una
satélite y las microondas, vayan a caer en desuso. S e piensa
complementación de las capacidades que cada uno ofrece.
S e concluye por tanto, que las redes de computadoras actuales crecieron hasta convertirse
en un mercado que se desarrolló con el uso de las microcornputadoras y de una tecnología de
comunicaciones que aprovechó la experiencia delas
investigaciones precursoras. E n su
primera etapa comercial se pudieron conectar los equipos pertenecientes a una misma
organización, con la instalación de redes locales, y posteriormente, se utilizó la infraestructura
de cobertura internacional para ofrecer conexión mundial.
E n el camino recorrido puede observarse un inicio más bien caótico, en el que no existían
normasde
compatibilidad; hasta llegar a una convergencia entre la computación y las
comunicaciones en donde se propone un sólo tipo de redes de computadoras y donde existe
un consensoen el uso de normas que garanticen la independencia entreel usuario y el
prestador de servicios.
45
CaDítulo 2
OBJETIVOS DE LAS REDES
Compartir recursos. Son muchas las organizaciones que ya cuentan con un número
considerable de computadoras en operación y con frecuencia alejadas unasde otras. Por
ejemplo una compañía con varias fábricas puede tener una computadora en cada una de ellas
para mantener un seguimiento de inventarios, observar la productividad y llevarla nómina
local. Inicialmente cada una de éstas computadoras puede haber estado trabajando en forma
aislada de las demás pero, en algún momento, la administración puede decidir interconectarlas
para tener así la capacidadde
extraer y correlacionarinformaciónreferente
a toda la
compañía.
I
Puesto en unaforma más general, el tema aquí consiste en compartir recursos, y el objetivo
es hacer que todos los programas, datos y equipo estén disponibles para cualquier usuario de
la red que as¡ lo solicite, sin importar la localización física del recurso y del usuario. E n otras
palabras, el hecho de que el usuario se encuentre a 1000 km. de distancia de los datos, no
debe evitar que éste los pueda utilizar como si fueran originados localmente. Otro aspecto de
compartir recursos es el relacionado con el compartimiento de la carga.‘Este objetivo se puede
resumir diciendo que es un intento para terminar con la “tiranía de la geografía”.
Fiabilidad. Un segundo objetivo consiste en proporcionar una alta fiabilidad, al contar con
fuentes alternativas de suministro. Por ejemplo, todos los archivos podrían duplicarse en dos o
tres máquinas,de
tal maneraque
si una de ellas no se encuentra disponible (como
consecuencia de un fallo de hardware), podría utilizarse alguna de las otras copias. Además la
presencia de múltiples C P U significa que si una de ellas deja de funcionar, las otras pueden
ser capaces de encargarse de su trabajo, aunque se tenga un rendimiento global menor. Para
aplicaciones militares, bancarias, de control de tráfico aéreo y muchas más, es muy importante
la capacidadde los sistemas para continuarfuncionando a pesarde existir problemas de
hardware.
Ahorro económico. Otroobjetivo es el ahorro económico. Las computadoras pequeñas
tienen una mejor relación costohendimiento, comparadacon la ofrecida porlasmáquinas
grandes.Estasson,
a grandes rasgos, diezvecesmás
rápidas que el más rápido de los
microprocesadores, pero su costo es miles de veces mayor. Este desequilibrio ha ocasionado
quemuchosdiseñadores
construyan sistemas constituidospor
poderosas computadoras
personales, una por usuario, con los datos guardados et3 una o más máquinas que funcionan
como servidor de archivo compartido.
Un puntomuy relacionado es la capacidadpara aumentarelrendimiento
del sistema en
forma gradual a medida que crece la carga, simplemente añadiendo más procesadores. Con
máquinas grandes, cuando el sistema está lleno, deberá reemplazarse con uno más grande,
operaciónque por lo normal genera ungrangasto
y una perturbacióninclusive mayor al
trabajo de los usuarios.
Medio de comunicación. Otro objetivo del establecimiento de una red de computadoras
no tiene que ver con la tecnología. Una red de computadoras puede proporcionar un poderoso
medio decomunicación entre personas que se encuentranmuy alejadas entre sí. Con el
46
Implementación
remoto
shell
de un
empleo de una red es relativamentefácil para dos o máspersonas,que
viven en lugares
separados, escribir un informe juntos. Cuando un autor hace un cambio en un documento que
se mantiene en línea, los otros pueden ver el cambio de inmediato, en lugar de esperar varios
días para recibirlo por carta. Esta rapidez hace que la cooperación entre grupos de individuos
que se encuentran alejados, y que anteriormente había sido imposible de establecer, pueda
realizarse ahora. A la larga el usode
las redes, comoun
medio para enriquecer la
comunicación entre sereshumanos,puede
ser más importante que los mismos objetivos
técnicos, como por ejemplo la mejora de la fiabilidad.
Finalmente, a la conexión de dos o más redes se le denomina interconexión de redes.
APLICACIONES DE LAS REDES
El reemplazo de una máquina grande por estaciones de trabajo sobre una red de área local
no ofrece la posibilidad de introducir muchas aplicaciones nuevas, aunque podrían mejorarse
la fiabilidad y el rendimiento. Sin embargo, la disponibilidad de una red de gran cobertura sí
genera nuevas aplicaciones viables, y algunas de ellas pueden ocasionar importantes efectos
en la totalidad de la sociedad. Para dar una idea sobre algunos de los usos importantes de
redes de computadoras, se verán ahora tres ejemplos:el acceso a programas remotos, el
acceso a bases de datos remotasy facilidades de comunicación.
Acceso a programas remotos. Una compañía que ha producido un modelo que simula
la economía mundial puede permitir que sus clientes se conecten usando la red y corranel
programa para ver cómopueden
afectar a susnegocioslas
diferentes proyecciones de
inflación, de tasas de interés y de fluctuaciones de tipos de cambio. Con frecuencia se prefiere
este planteamiento que vender los derechos del programa, en especial si el modelo se está
ajustando constantemente o necesita de una máquina muy grande para correrlo.
Utilización de bases de datos remotas.Otra área principal para la utilización de redes
es el acceso a bases de datos remotas. E n el futuro próximo no será difícil ver, por ejemplo, a
cualquier personahacerdesde
su casa reservas de
avión,
autobús,
barco
y hoteles,
restaurantes, teatros, etc., para cualquierParte del mundo y obtener confirmación de forma
instantánea. E s esta categoría caen las operaciones bancarias que se llevan acabo desde el
domicilioparticular, así como las noticiasdelperiódicorecibidas
de formaautomática. Los
periódicos en la actualidad ofrecen un poco de todo, pero con los de tipo electrónico se puede
fácilmente adaptar el contenido de acuerdo con el gusto particular de cada lector. Por ejemplo,
que elcontenidoincluyatoda
la informaciónreferente a las computadoras, a los principales
temas sobre política y epidemias, pero que excluya los temas relacionados con el fútbol.
El paso posterior a la automatización de periódicos (además de las revistas de divulgación y
científicas) es la automatización de las bibliotecas. Dependiendo del costo, tamaño y peso de
la terminal, la palabra impresa puede llegar a ser obsoleta. Los escépticos deberían tomar nota
I
47
del efecto que la letra impresa tuvo sobre el manuscritoImedieval.
Todasestas aplicaciones operansobreredesporrazones
económicas: el llamar auna
computadora remota mediante una red resulta más económico que hacerlo directamente. La
posibilidad de tener un precio más bajo se debe a que el enlace de una llamada telefónica
normal utiliza un circuito caro y en exclusiva durante todo el tiempo que dura la llamada, en
tanto que elaccesoa través deuna red, haceque sólo se ocupen los enlacesde larga
distancia cuando se están transmitiendo los datos.
Utilización de las redes de computadoras como medio de comunicacidn. Una
tercera forma que muestra el amplio potencial del, uso de redes, es su empleo como medio de
comunicación. Los científicos informáticos yatoman como hechogarantizadopoder enviar
correo electrónico, desde sus terminales, a sus colegas situados en cualquier parte del mundo.
En el futuro, será posible para todos enviar y recibir correo electrónico, y no sólo para aquellas
personas que se encuentran en el mundo de las computadoras. Además, este tipo de correo
también será capaz de transmitir voz digitalizada, así como fotografías e imágenes móviles de
televisión y video. Uno puede imaginarse muy fácilmente a los niños de diferentes países,
tratando de aprender el lenguaje de los otros, dibujando la imagen de un niño en una pantalla
compadida y poniéndole una etiqueta en otro idioma.
En la actualidad ya existen tablones de anuncios electrónicos, pero éstos tienen cierta
tendencia a ser utilizados por expertos en computadoras,ser orientados hacia temas técnicos
y con frecuencia están limitados desde el punto de vista gedgráfico. En el futuro los sistemas
serán tanto nacionalescomo
internacionales y millones depersonas
los utilizarán sin
necesidad de tener un conocimiento técnico, cubriendo además una gama de temas mucho
más amplia. El uso de un tablón de anuncios será entonces tan común como leer una revista.
Algunasvecesse dice que seestá llevando acabouna carrera entre el desarrollo del
transporte y el de la comunicación,y que el gane de los dos hará al otro innecesario. El uso de
las redes de computadoras como un sistema de comunicación sofisficado puede reducir la
cantidadde viajes realizados, ahorrandode esta manera energía. Las oficinas y escuelas
comoson ahora, pueden llegar adesaparecer.Lasórdenesmediantecatálogopor
correo
electrónico pueden llegar a reemplazarlas tiendas comunes y corrientes. Las ciudades podrían
dispersarse con relativa facilidad, dado que la alta calidad de los recursos de comunicación
tenderán a reducir la necesidad de una proximidad
física.
ESTRUCTURA GENERAL DE UNA RED
Desde el punto de vista del usuario y de una forma muy general, una red de computadoras '
está constituida por un conjunto de elementos, capaces de realizar la tarea de comunicación
entre dos entidades que así lo requieran. Dichos elementos serán programas o equipos entre
los que
pueden
establecerse
relaciones específicas. Por ejemplo, comunicación entre
48
.
Implementación
de
"_._.-.-
un shell remoto
programas con objeto de intercambiarinformación para cooperaren la resolución de una
función; comunicaciones entre programas y equipos, con el objeto de que los primeros hagan
uso de los servicios de los segundos.
E n la Figura 1 se puede ver un sencillo sistema de comunicación de datos. El “Proceso de
Aplicación”(PA)que maneja el usuario final, suele tratarse de un programa de computadora o
a veces de una terminal de usuario, con un programa de contabilidad, de nómina, un sistema
de reservaciones para avión, etc.
I
’
La aplicación reside en el Equipo Terminal de Datos o ETD. Estas siglas suelen emplearse
de manera genérica para aludir a la máquina que emplea el usuario final. Un E T D puede ser
una gran computadora, del tipo IBM, o una máquina máspequeña, como una terminal o
computadora personal. La misiónde
las redes’ detransmisiónde
datos es interconectar
distintos ETD. Así mismo, se ve en la figura un Equipo de Terminación del Circuito de Datos
o ETCD. Su misión es conectar los ETD a la línea o canal de comunicaciones. El canal de
comunicaciones llamado circuito o línea, es una vía sobre la cual se transfieren datos entre
dispositivos remotos.
Los E T C D , en un principio, eran dispositivos exclusivamente decomunicaciones,
sin
embargo,en losúltimos añoshan ido incorporando más funcimes deusuario; hoy en día
algunos E T C D contienen parte de los procesos de aplicación. De cualquier modo, la principal
misión de un E T C D es servir de interface entre el ETD y la red de comunicaciones.
,............................................................................................
Archivo
datos
de
-
PAA2
6.O
Bases
Conexione
II
I
I
I
Red de
1 .............................................................................................
cornunicacione I
Archivo
S
:
S
Conexiones lógicas
físicas
Conexiones
Figura 1 . Sistema de comunicaciones.
S e hace hincapié en que el ETD es el equipo de usuario donde se desarrolla la aplicación
que originala necesidad de comunicación. El ETCD es el equipo medianteel cual el ETD
ingresa a la red que transporta la información.
Una red de computadoras, como cualquier red de telecomunicaciones, puede cumplir sus
49
Capítulo 2
objetivos mediante una combinación muy rica de soluciones materiales (canales, equipo, etc.)
y lógicas (arquitectura, organización, etc.). La arquitecturadeunared,
es un diseñode
sistema de comunicaciones, que incluye el hardware, el software, los métodos de acceso y los
protocolos empleados.También define el métodode control: si las computadoraspueden
actuar en forma independiente o si son controlados por otras computadoras que monitorean
(un monitor essoftware
que proporciona utilidades y funcionesde
control comoel
establecimiento de parámetros de comunicaciones)la red. La arquitectura de red determina la
futura flexibilidad y conexión a redesextranjeras.
Finalmente el ETD puede tener comosinónimos terminal, computadora, estación, sistema
final, anfitrión o huésped (estos dos últimos provienen de la terminología ARPANET); y el
de
ETCD puede
llamarse
nodo,
lnterfaz
de
Hardware
(de
la
Red) o Procesador
Intercambio de Mensajes(IMP) -&te último también de la terminología ARPANET-.
CLASIFICACIONES DEREDES
En su forma más simple, las comunicaciones toman lugpr entre dos dispositivos que se
conectanenalgunamodalidaddeenlace
punto a punto.En este casocada línea de
comunicaciónde la redconectaados
ETCD. Si dos ETCD deseancomunicarse y no
comparten una línea de comunicación común, deberán hacerlo a través de otros ETCD; sin
embargo, si se trata deungruponumerosode
aparatos, enelqueno
todossevan
a
comunicar simultáneamente, no resulta práctico pensar en una configuración punto a punto
que una a cada equipo con resto
el
del conjunto.
La solución del problema consiste en conectar los dispositivos a una red de comunicación
( llamada también subred de comunicaciones o simplemente subred). Se tiene un grupo de
pueden
ser
aparatos
deseando
comunicarse
entre sí (estaciones). Las estaciones
computadoras, terminales, teléfonos o cualquier otro aparato de comunicación. Cada estación
se conecta a un nodo de la red.
La red de comunicación no tiene que ver con el contenido de la información que por ella
circula, su propósito es transportar información entre origen y destino. Con la redse comparten
las instalaciones de transmisión entre 'estaciones con lo que se reducen los costosde
funcionamiento.
Las redes de comunicaciones puedenclasificarse empleando diferentes criterios tales como
su topología, cobertura, el método de envío de información, velocidad o bien por su tipo de
tráfico cursado.
50
Implementación
de
un shell remoto
L.
Fundamentos de redes de cornputadoras
TOPOLOGiA
Por topología debe entenderse la forma en la cual habrán de interconectarse físicamente
los diferentes componentes que constituyen una
red
de
'comunicaciones.
Existen
fundamentalmente cinco topologías, que son (ver Figura 2):
a)
b)
c)
d)
e)
Anillo
Árbol
Bus
Estrella
Malla
@
Fig. l. Conexión total
(Malla)
Fig, 2. Conexión Parcial
.x-Q
Enlaces
Dobles
Fig. 4. Estrella
Fig. 3. Jerarquía [Arbol]
I
PPPP
Canal
lineal
Enlace
I
Sencillo
Fig. 6. Canal multiacceso
Fig. 5. Anillo
Figura 2. Topologías deredes.
Topología en anillo. La estructura en anillo es una configuración bastante extendida.
Como se ve en la Figura 2, la topología en anillo toma su nombre del aspecto circular del flujo
de datos. En la mayoría de los casos, los datos fluyen en una sola dirección, y cada estación
recibe la seña1.y la retransmite a la siguiente estación d I anillo.
7
Laorganizaciónen
anillo resulta atractiva porquecon
ella sonbastantes
I
raras las
51
Capítulo 2
situaciones decongestión o bloqueo, tan frecuentesen las topologías de estrella y árbol.
Además, la lógica necesariaparaponerenmarchauna
red de este tipo es relativamente
simple. Cada nodo sólo ha de llevar a cabo una serie de tareas muy .sencillas: aceptar los
datos y retransmitirlos al próximo componente delmismo.
Sin embargo,comotodas
las topologías, la red en anillo tiene algunos defectos. El
problema más importantees que todos los componentes del anillo están unidos por un mismo
canal. Si falla el canal entre dos nodos,toda la red deja de funcionar. Por esoalgunos
fabricantes han ideado diseños especiales queincluyen canales de seguridad, de modo que si
se produce la pérdida de algún canal, existen otros de respaldo. Otros fabricantes construyen
conmutadores que redirigen los datos automáticamente, saltándose el nodo averiado, hasta el
siguiente nodo del anillo, con el fin deevitar que el fallolafecte a toda la red.
Topología en árbol. La estructura árbol es una de las más extendidas en la actualidad.
La ‘infraestructura que controla la red es relativamente simple y la topología proporciona un
punto de concentración de las tareas de control y de resolución de errores. En la mayoría de
los casos, el nodo situado en el nivel más elevado de la jerarquía es el que controla la red. En
la Figura 2, el flujo de tráfico entre los distintos nodos arranca del que está arriba.
Muchos fabricantes incorporan a esta topología un cierto carácter distribuido, dotando a los
nodos subordinados deun control directo sobre los nodos situados en niveles inferiores dentro
del árbol (control distribuido), lo cual reduce la carga de trabajo del nodo central de arriba.
Aunque la topología en árbol resulta interesante por ser fácil de controlar, puede presentar
ciertos problemas en cuantoala
posibilidad de cuellos de botella. En determinadas
situaciones, elnododemayor
jerarquía hade controlar todo el tráfico entre los demás
(enfoque centralizado). Estehechono sólo puede crear saturacionesde datos, sino que
además plantea serios problemas de fiabilidad. Si el nodo principal falla, toda la red deja de
funcionar.
Pesea todo, las topologías de árbol se hanvenidousadoampliamentedesdehace
bastantes años, y seguirán empleándose durante muchotiempo, ya que permiten la evolución
gradual hacia una red más compleja, puesto que la adición de nuevos nodos subordinados es
relativamente sencilla.
I
Topología en bus. En la Figura 2 se muestran topologías tipo bus. Esta estructura es
frecuente en las redes de área local. Es relativamente fácil controlar el flujo de tráfico entre las
distintas estaciones, ya que el bus permite que todas reciban cualquier transmisión, es decir,
una estación puede difundir la información a todaslas demás.
La principal limitación de esta topología eselhechode
que suele existir un sólo canal
principal. Otro inconveniente deesta configuración estriba en la dificultad de aislar las fallas de
los componentes individuales conectados al bus, la falta de puntos de concentración complica
la resolución de este tipo de problemas.
Topología en estrella.
La topología en estrella es unade las más empleadas en los
sistemas de comunicación dedatos, principalmente por razoneshistóricas.
52
Implementación
de
un shell remoto
Fundamentos deredes de computadoras
I
La topología en estrella se utilizó a lo largo de los años sesenta y principios de los setenta,
porque se consideraba fácil de controlar, debido a que su programación para funcionamientoy
mantenimiento no es complicada y su flujo de tráfico es sencillo.
Todo el tráfico atraviesa el núcleo de la estrella, que en la Figura 2 es el nodo central. El
nodo central, por lo general una computadora, poseeel control total de los ETD conectados a
él. Dicho nodo es responsable de enrutar el tráfico hacia el reSto de los componentes; se
encarga además, de localizar las averías. Esta tarea es relativamente sencilla en el caso de
una topología estrella, ya que es posible aislarlaslíneas
para identificar el problema. Sin
embargo, una red enestrella puede sufrir saturaciones y problemas en caso de unaavería del
nodo central.
Algunas redes en estrella construidas en los años setenta experimentaron serios problemas
de fiabilidad, debido a su carácter centralizado. En otros sistemas se estableció redundancia
en el nodo central, como medida
de
seguridad, con lo cual la fiabilidad aumentó
considerablemente.
Topología en malla. La topología en malla se ha venido empleando en los últimos años;
la Figura 2 representa casos particulares de este tipo de redes.
Enuna topología en mallacada estación puede estar conectadacontodas las demás
estaciones (red completa o red total) o con sólo algunas (red incompleta o red parcial)
formando una estructura que puede ser regular (simétrica) o irregular.
Cuando se desea implantar una red con topología en malla, el diseñador ha de plantearse
tres objetivos fundamentales:
1. Proporcionar la máxima fiabilidad posible para garantizar la recepción correcta de la
información quese transmite; uso de vías alternativas.
2. Encaminar el tráfico entre el equipo terminal de datos que transmite y el que se recibe a
través del camino más económico dentro de la red.
3. Proporcionar al usuario final un tiempo de respuesta y una capacidad de transmisión
óptimos.
Lo que hace atractiva a este tipo de topología es su relativa inmunidad a los problemas de
congestión y fallas. Gracias a la multiplicidad de caminos que ofrece, en esta topología es
posible orientar al tráfico por trayectorias alternad en caso de que algún nodo esté fuera de
operación. A pesar de que la realización de este método es compleja y cara, muchos usuarios
prefieren la fiabilidad de una red en malla a otras alternativas.
53
_"
-
-
--
'
... -..
"
"
Capitulo 2
COBERTURA
Existen redes de comunicación que ofrecensu servicio a una amplia zona territorial junto a
redes cuya coberturase limita a uno o a varios edificios.
I
A partir de su extensión territorial se identifican dos clases de redes:
1. Las de gran coberturageográfica, denominadas WAN (Redes de Área Ancha).
2. Las redes de árealocal, denominadas LAN (Redes de ÁreaLocal).
Estos tipos de redes se estudiarán más detalladamente en una secciónposterior
REDES CONMUTADAS Y REDES DE DIFUSIóN
El método con que se realiza el enrutamiento de la información, desde su origen hasta su
destino, ofrece otro criterio para clasificar a las redes, separándolas en dos grandes grupos, a
saber:
A) Redes conmutadas.
1. Conmutación de circuitos.
2. Conmutación de paquetes.
3. Conmutación de mensajes.
I
B) Redes de difusión.
1. Radio paquetes
2. De satélite.
3. Locales.
I
Se entiende por red conmutada a aquella colección de nodos en la cual la información se
transmiten de la fuente al destino enrutándose através de varios nodos de la red.
Losnodosque
constituyen lared se conectandeacuerdoa
los requerimientosde
comunicación entre ellos, debido a esto, la interconexión no necesariamente es entre todos.
Por eso se dice que en este tipo de redes la topología puede ser de conexión completa o
parcial. Dentro de las redes conmutadas se da una clasificación en términos de la forma en la
cual los nodosconmutan los datosde un enlace a otro, de ahíque existan las redes de
conmutación de circuitos, de mensajesy de paquetes. Estos tipos de redes se analizarán
brevemente en la sección de comunicación.
El número de estaciones(ETD) conectadas a un nodo, dependerá desu tipo. Si se trata de
unpuntodeacceso
a red (ETCD), podrá tener varias estaciones abonadas (es decir,
Implementación
de
54
*
"
un shell remoto
Fundamentos de redes de comwtadoras
conectadas a éI). Por otro lado, si se trata simplemente de un elemento de conmutación
interno de la red,no tendrá unasola estación abonada. Los enlacesesfaci6n-nodo son
enlaces punto a punto dedicados, en cambio, los ?#/aces nodo-nodo son comúnmente
enlaces de mayor capacidad y de uso compartido.
E n las redes de difusión, no existen elementos de conmutación. Es éstas, cada estación se
conecta a un transmisor-receptor y se comunica sobre un medio común a otras estaciones.
E n estas redes, en principio, cada estación tiene la capacidad de recibir la información que
todas las demás envían, pero sólo la aprovecha si le corresponde.,Las redes de sat6lites y las
redesderadiopaquetes
emplean el espacio aéreo como medio comúnde transmisión.
(cablede
alta
Existen también lasredes
que emplean medios como el cablecoaxial
capacidad utilizado en comunicaciones y video, generalmente llamado co-ax), la fibra óptica o
el par de cables trenzados(alambres aislados del grosor de un diámetro [de medida entre 22
y 261, utilizado comúnmente en alambrados telefónicos). Loscasos característicos son las
redes de anillo y de bus vistas anteriormente.
VELOCIDAD
Las redes de comunicación se pueden clasificar también por su velocidad en:
1. Redes de baja velocidad (LSLN: Red Local de Baja Velocidad).
2. Redes de alta velocidad (HLSN: Red Local deAlta Velocidad).
Las redes de baja velocidad emplean como medio de transmisiónel cable coaxial y en
menormedida la fibraóptica. S u velocidad de transmisión puede ser de hasta
10 Mbps., y
pueden soportar hasta 1000 estaciones. E n este tipo de redes pueden considerarse las redes
un sistema de
locales y a los PBX(Intercambio Privado deRamificación). Una PBX es
conmutación telefónica
interna
que interconecta en forma
electrónica
las extensiones
telefónicas entre sí, así como a la red telefónicaexterna. Puede incluir funciones como ruta
menos
costosa
para
llamadas externas, redireccionamiento de' llamadas, llamadas de
conferencia y contabilidad dellamadas.
LasPBX modernas utilizan métodos totalmente
digitales de conmutación, y a menudo pueden operar terminales y teléfonos digitales, así como
teléfonos analógicos.
I
Las redes de alta velocidad emplean como medio de transmisión el cable coaxial y la fibra
óptica, y actualmente el par trenzado de nivel 5. S u velocidad de transmisión es entre los 10 y
1000 Mbps., y puede soportar hasta 1000 estaciones. E n este tipo de redespueden
considerarse las redes locales FDDl (Interface de Datos Distribuidos por Fibra Óptica), las
cuales son un caso particular de las redes locales de anillo.
55
- .. . . . . .. . -.
.
TIPO DE INFORMACIóN QUE CURSAN
i
Por cuestiones de exposición, se considera también como criterio de clasificación el tipo de
información que pueden cursar las redes. Aún cuando se ha visto, de acuerdo a su evolución,
quo no os ut1 pardtnolro soparado, puos de rnariera natural la loridencia es llacia la intoyraciitl
y con ello, la información que se transmite no es de un sólo tipo.
Hecha la advertencia, se pueden dividir las redes entres categorías:
1. De voz.
2. De datos
3. De imágenes.
El diseñador de una red de comunicaciones debe considerar
cuatro aspectos básicos:
1. Estrategias de enrutamiento. ¿Cómo se enviarán los mensajes porla red?
2. Estrategias de conexión. ¿Cómo envían dos procesos unaserie de mensajes?
3. Conflictos. Puestoque la red es un recurso compartido, ¿Cómo solucionamos las
demandas de usoconflictivas?
4. Estrategias de diseño. ¿Cuál es el diseño global para
la
comunicación
entre
de
redes, vistas
aplicaciones? Aquí entran las arquitecturas y normalización
anteriormente.
ESTRATEGIAS DE ENRUTAMIENTO
1
Cada instalación tiene una tabladeencaminamiento
(o enrutamiento)que indica las
alternativas de rutas que pueden emplearse paraenviar un mensaje aotras instalaciones. Ésta
tabla puede incluir información acerca de la velocidad y costode las diversas rutas de
comunicación y puede actualizarse manualmente o por medio de programas.
Los tres esquemas de encaminamientomás comunes son los descritos a continuación:
Encaminamienfo fíjo. Se especifica por adelantado una ruta de A a B y no cambia a
menos que una falla en el hardware invalide esa ruta. Generalmente se escoge la ruta más
corta por economía. Éste esquemaes poco flexible, sin embargo asegura que los mensajes de
A a B sean entregados en el orden en
el que fueron enviados.
Implementación
de
56
~ . - ,I.
._
un shell remoto
I
Circuito virfual. S e fija una ruta de A a B durante una sesión. Sesiones distintas donde
aparecen mensajes de A a B pueden tener rutas diferentes. Éste esquema es más flexible que
el de encaminamiento fijo, y también asegura que los mensajes de A a B se reciban en el
orden de envío.
Encaminamiento dinámico. La ruta para enviarun mensaje dela instalación A ala
instalación B se escoge en el momentodeenviar el mensaje. Éste esquema es totalmente
flexible, pudiéndose enviar un mensaje de una instalación a otra, usando el enlacemenos
utilizado en ese momento. La desventaja es quelos mensajespueden llegar en cualquier
orden;sepuede
anexar unnúmerode
secuenciaa
cada mensaje para solucionar éste
problema. Los paquetes que
circulan
en este tipo de encaminamiento se denominan
datagramas.
ESTRATEGIAS DE CONEXIóN
I
Hay varias maneras de conectar pares de procesos que desean comunicarse por la red; los
esquemas más comunes son los que se describen a continuación:
Conmutación de circuitos. Si dos procesos quieren comunicarse entre ellos,se
establece un enlace físico permanente. Éste enlace se asigna par todo el tiempo que dura la
comunicación y ningún otro proceso puede utilizarlo durante ese período. Éste esquema es
semejante al quese utiliza en el sistema telefónico. La conmutación de circuitos requiere
tiempo de preparación, pero provoca menos tiempo de procesamiento adicional para enviar
cada mensaje y puede desperdiciar parte del ancho de banda de la red.
La conmutación de
circuitos utiliza el encaminamiento fijo.
Conmutación de mensajes. Si dos procesos quieren comunicarse, se establece un
enlace temporal durante el tiempo que dura la transferencia de un mensaje. Cada mensaje es
un bloque de datos, junto con ciertainformación (comola fuente, el destino y códigos de
corrección de errores). Es posible enviar muchos mensajes(de varios usuarios) por el mismo
enlace.
Éste
esquema
requiere menos tiempo
de
preparación y mayor tiempo
de
procesamiento adicional por cada mensaje. El sistema de conmutación de mensajes es similar
al usado por la oficina de correos.
Conmutación de paquetes. Los mensajes generalmentetienenlongitud
variable. La
conmutación de paquetes es similar a la de mensajes, pero en aquella los mensajes se dividen
en mensajes de longitud fija llamados paquetes. Es posible que un mensaje lógico tenga que
dividirse en varios paquetes, cada unode los cuales se envía por separado a su destino y
pueden seguir rutasdiferentes por la red. Para formar el mensaje hay que reensamblar los
paquetes conforme llegan. AI igual que en la conmutación de mensajes se requiere un menor
procesamiento. Esta estrategia de conexión
tiempo depreparación y untiempomayorde
utiliza los circuitos virtuales y el encaminamiento dinámico (datagramas).
57
CONFLICTOS
Ya que un enlacepuedeconectar
varias instalaciones, es posible queéstasquieran
transmitir simultáneamente información por un enlace. Si no se toman medidas especiales,
ésta situación se puede repetir, dando como resultado una degradación del rendimiento. Las
principales técnicas para evitar colisiones repetidas son las que se citan en seguida.
CSMNCD(CSMA = Detección de PortadoraconAccesoMúltiple)
'(CD =
Detección de Colisión).Antes de transmitir un mensaje porun enlace, una instalación debe
escuchar para determinarsi en ese momentose está transmitiendo otro mensaje por el mismo
enlace, a ésta técnica se le llama CSMA. Si el enlace está libre, la instalación puede comenzar
a transmitir; de lo contrario debe esperar (y seguir escuchando) hasta que el enlace quede
libre.
Si dos o más instalaciones comienzana transmitir en el mismo instante (cadauna
pensandoqueninguna
otra utiliza el enlace), entonces registrarán una CD y dejaránde
transmitir. Cada instalación intentará hacerlo de nuevo, después de cierto período aleatorio de
tiempo.
El problema principal con ésta estrategia es que, cuando el sistema está muy ocupado,
pueden ocurrir muchas colisiones con mensajes de otras instalaciones y degradarse el
rendimiento. No obstante, CSMAICD se ha utilizado con éxito enEthernet (ver Tecnología
Ethernet másadelante).
Paso de testigo (ficha). Un tipo de mensaje Único, conocido como testigo o ficha, circula
continuamente por el sistema (casi siempre una estructura anular). Una instalación que desee
transmitir información debe esperar a que llegue el testigo; luego quita el testigo del anillo y
comienzaa transmitir sus mensajes.Cuando la instalación terminade transmitir, vuelvea
transmitir el testigo, lo que permite que otra instalación reciba y quite el testigo para repetir el
proceso. Si se pierde el testigo, el sistema debe detectar ésta situación y generar uno nuevo.
En los sistemas IBM y Apollo se ha adoptado un esquema de paso detestigo.
Ranuras de mensajes. Por el sistema (casi siempre una estructura anular) circulan
constantemente varias ranuras de mensaje de longitud fija. Cada ranura puede contener un
mensaje de longitud fija e información decontrol (como cuáles son la fuente y el destino y si la
ranura está vacía o llena). Una instalación que esté lista para transmitir debe esperar a que
llegue una ranura vacía, en la cual insertará su rpensaje, ajustando la información de control
adecuado. La ranura consu mensaje prosigue entonces porla red y al llegar a una instalación,
esta examina la informaciónde control para determinarsi le correspondeo no el mensaje en la
ranura. Si no es para esa instalación, la ranura con el mensajevuelvea
circular; de lo
contrario, la instalación toma el mensaje, restablece la información de control para indicar que
la ranura está vacía, y luego puede enviar un mensaje propio o liberar la ranura. Éste esquema
se ha adoptado experimentalmente enel Anillo de ComunicaciónDigital de Cambridge.
Implementación
de
58
" -
Y_"".-.*
un shell remoto
"
TECNOLOGíAS DE REDES
Redes de área ancha. Las primeras redes de computadora, fueron redes de área ancha
(WAN). Estándiseñadasparaproporcionarcomunicación
entre computadorasqueestán
separadas por grandesdistancias y usualmente localizadas en organizacionesseparadas.
Una red de área ancha consta de una colección de canales de comunicación enlazados a
computadorasde
propósito especial,
conocido6
individualmente como Conmutadorde
Paquete o lntercambiador de Conmutación de Paquete (PSE), introducidos primero en la
red ARPA conelnombredeProcesadordeInterfacedeMensaje
(IMP). Un PSE está
tarea de
localizado encadanododela
red (Figura 3). Los PSEs estándedicadosala
comunicación de datos. Ellos envían y reciben paquetes de datos através de la red en nombre
de otras computadoras.
Los PSEs operan la red por la reexpedición de paquetes desde un PSE a otro a lo largo de
una ruta desde el emisor a el receptor. Ellos son responsables de definir la ruta tomada por
cada
paquete.
Este
modo
de
operación
de red es aludido como comunicación
de
almacenamiento y reenvio, porque cada paquete de datos
es almacenado temporalmente
por cada PSE durantesu ruta antes de que sea reexpedido aotro PSE.
Los sistemas de red de almacenamiento y reenvío pueden ser usados para comunicación
de computadora a computadora sobre cualquier distancia donde existan circuitos que lleven
los paquetes.
e la red 1____3
Anfitri6n 4
Figura 3. Una red deárea ancha.
Las computadoras que usan una red paraenviar y recibir datos se denominarán anfitriones
59
Capítuio 2
(como se vio antes, el nombre proviene de la terminología ARPANET). Los anfitriones están
normalmente localizadoscerca deun PSE y conectados directamente a él. Ellos pasan los
paquetes de datos a los PSEs para que éstos los transmitan a travbs de la red a otros
anfitriones y reciben paquetes desde los PSEs que son direccionados a ellos.
1
e" Anfitriones
"+
Topología de bus simple.
Topología de bus ramificada.
Figura.4. Topologías de bus.
y la mayoría de las actuales operan a velocidades de
Las primeras redes de área ancha
transmisión en el rango de 20-500 Kbps., obteniéndose tiempos de transmisión mínimos para
un mensaje de 1000 bytes a través de un circuito simple entre 16 y 400 ms. Pero el método de
conmutación de paquetes involucra
retardos
adicionales de
el
orden de
unos
pocos
milisegundos en cada PSE en la ruta detransmisión.
En consecuencia, los tiemposde
transmisión de mensajesson relativamente largos y puedendepender incluso de la ruta
tomada por cada mensaje. Los mensajes cortos son transmitidos en 100-200 ms. en redes de
60
remoto
shell
un
Implementación
de
área ancha típicas. Los satélites de transmisión necesariamente involucran una latencia (es el
tiempo entre la iniciación de una solicitud de datos y el comienzo de la transferencia efectiva
de datos) adicional porque el tiempo de vuelo de una sefial electrónica a un satélite síncrono
en órbita y de regreso a la tierra es del orden de 200 ms. Si son usados los canales del satélite
o la ruta es compleja, se involucran muchos PSEs, y el tiempo de transmisión para un mensaje
puede ser hasta de 500 ms. Se espera que las redes de área ancha basadas en ATM ofrezcan
velocidades de transferencia en la región de 150 Mbps. con latencia abajo de I ms. para la
transmisión de paquetes una vezque una conexión ha sido establecida.
I
Redes de área local. Las redes de área local fueron desarrolladas en respuesta a las
'
mismas necesidades que permitieron el desarrollo de sistemas distribuidos (los cuales fueron
diseñados para habilitar a los usuarios a trabajar en computadoras personales dedicadasy
en estacionesdetrabajo
paracompartir
recursos). Las estaciones de trabajo y las
computadoras dedicadas son aquellas micro o minicomputadoras para un sólo usuario, de alto
rendimiento, que han sido especializadas para gráficas, diseño o aplicaciones científicas.
Estación monitor
Figura 5. Topología en anillo.
Las redes locales están estructuradas ya sea como buses o anillos (Figura 4 y Figura 5) con
circuitos de comunicacióndedicados,normalmente
enun lugar sencillo y extendiéndose
alrededor de unos pocos kilómetros. Los mensajes son transmitidos directamente desde una
computadora fuente a una computadora destino sin almacenamientointermedio
y sin
Universidad
Autónoma
Metropolitana. Unidad
lztapalapa
61
Capítulo 2
procesamiento. No hay PSEs enlas%redeslocales;
en vezdeello,
los anfitriones son
responsables colectivamente del control de tráfico o de la red usando interfaces de hardware
de propósito especial para transmitir y recibir los datos en los circuitos de la red. El modo de
operación
está
basado
en
comunicación de difusión más
que
en el modo de
almacenamiento y reenvíousado
en redesdeáreaancha.
Estoes,cada
paquete es
transmitido a cada una de las computadoras de la red y cada computadora es responsable de
la identificación y recepción de paquetes que son direccionados a ella.
La comunicación en redes
locales
es efectuada sin la necesidad
de
computadoras
especializadasdedicadasalas
tareas de comunicación. Los anfitriones sonconectados
directamente a un canal de comunicación por una interface de hardware relativamente simple.
La interface de hardware y elsoftware que maneja la red en cada anfitrión puede enviar y
recibir datos a altas velocidades con tasas de
errores bajas y sin retardos de conmutación,
implementando la capa física, la capa de enlace de datos y la capa de red con un protocolo
simple.
E s posible proporcionar softwarerelativamentesimple
a cada computadora que pueda
llevar a cabo la tarea completa de la transmisión o recepción de mensajes. Estas importantes
características de
las
redes
locales
dan
ventajas considerables encosto,
velocidad e
integridad en comparación con las redes de área ancha.
Los circuitos usados en redes locales pueden ser par trenzado, cable coaxial o fibra óptica,
capaces de transmitir datos a velocidades en un rango desde 0.2 a 100 Mbps. Ya que todas
las redes locales están diseñadas para proporcionar comunicación directa entre dos anfitriones
cualesquiera, la topología usada (anillo, bus o bus ramificado)tienerelativamente
poca
influencia en el comportamiento visto por el usuario.
Redes de &ea metropolitana (MANS). Esta clasederedes está basada en la fibra
óptica conectandopueblos y ciudadespara la transmisiónde video,voz y otros datos en
distancias de hasta 50 km. Las facilidades de transmisión de datos de dichas redes pueden
ser explotadas para proporcionar tasas de transferencias de datos que son comparables a las
requeridas por los sistemas distribuidos. Sus tasas de transferencias de datos son similares a
las de las redes RDSI-BA y usan las técnicas de conmutación ATM (se verá posteriormente).
El enrutamiento de mensajes y otros retardos son mucho más cortos que los de redes de área
ancha, produciendo latencias típicas de menos de un milisegundo. Las’redes MAN encuentran
necesidades similares a aquellas que encontraron las actuales redeslocales mientras se
expandían grandes distancias.
El enfoque se hará en las redes de área local porque han proporcionado la infraestructura
decomunicacionesnecesariapara
los sistemas distribuidos. .Las ventajas de la tecnología
RDSI-BA y delastécnicas
de conmutación ATM, ofrecen mecanismosdecomunicación
compatibles con las necesidades de los sistemas distribuidos que son independientes de la
distancia geográfica.
62
”
remoto
shell
un
Implementación
de
“.““”l(”l
-.
TECNOLOGIAS E-I’HERNE-I’,TOKEN RING Y ATM
S e describen aquí los principiosde operación de dos tecnologías importantes de redde
área local y de la surgiente tecnología ATM pararedes ISDN debanda ancha. Primero se
discutirán los principios generales de operación de redeslocales basadas en topologías de
bus y anillo.
*
E n redes con topología de bus simple o bus ramificado, hay un circuito compuesto de un
cable sencillo o de un conjunto de cables conectadQs pasando cerca de todos los ETDs en la
red. Cuando se usamás
deun
cable las conexiones puedenhacerse
por repetidores
(unidades simples de amplificación y conexión que no causan efectos en la sincronización o
comportamiento lógico de la red). El cable es pasivo, y cada ETD tieneun cabledecaída
conectado al cable principal por medio de una conexión T o llave. Los datos son transmitidos
por una señal de difusión sobre el cable como una secuencia simple de pulsos. Esta forma de
señalización es análoga de alguna manera a los sistemas de bus (genéricamente un bus es
un canal o ruta común entredispositivosdehardware)
de datos que fueron desarrollados
originalmente paraconectar las partes del sistema de una computadora convencional. La
diferencia principalentre las redes de bus y los sistemas debuses usados dentrode los
sistemas de computadoras es que éstos QltiTos
son
buses
paralelos permitiendo la
16 ó 32 bits simultáneamente y la transmisiónde datos sobre ellos está
transmisiónde
sincronizada por una unidad de arbitraje central, mientras que en las redes locales de bus no
haycomponentes centralizados y el uso del cable se sincroniza porunmétodo
de control
distribuido que involucrar cooperación entre todas las computadoras conectadas a la red. Esto
ha conducido a la descripción detales redes como buses de contencich, porque todas las
computadoras de la red necesitan enviar un mensaje en cualquier momento contenido para el
uso del cable.
E n redes
con
topología de anillo el cable está compuesto de
enlaces
conectando
estaciones adyacentes. Los datos son transmitidos en una dirección alrededor del anillopor
señalización en las estaciones. Cada nodo envía la señal que recibe a la siguiente sección del
los remueve de el
cable.Los datos circulan alrededor del anillo hastaqueunaestación
circuito; la estación receptora hace esto en algunos sistemas del anillo, pero en otros los datos
pueden completar elciclo y ser removidos por la estación emisora. E n la mayoría de los
sistemas de anillo una estación monitor es incluida para asegurarse que los datos no circulen
indefinidamente (por ejemplo, en caso de que la estación receptora o la emisora fallen) y
permitir otras funciones “domésticas”.
Las redes locales han sido objeto de mucho trabajo de desarrollo, ya que cerca de los años
70’s un número de tecnologías de red han surgido con un desempeño adecuado para soportar
sistemas distribuidos.
I
La Ethernet, originalmente desarrollada en Xerox P A R C , principios de los ~ O ’ S , ha sido
adoptada como la Norma IEEE 802.3 y es la tecnología de red local más ampliamente usada
para sistemas distribuidos. Está basada en la difusión sobre un circuito pasivo simple, con un
cablede alta velocidadconectando todas las computadoras delared. La Cambridge Ring
desarrolla en la Universidad de Cambridge a mediados de los 70’s ejemplifica otra clase de red
63
Capítulo 2
local,conocida como anillo deapertura, puede transmitir paquetesgrandes y de tamaño
variable, y ha sido adoptada como la Norma IEEE 802.5, por IBM y algunos otros fabricantes
.
para el enlace de computadoras personales y estaciones detrabajo.
Las redeslocales
actuales son capaces de transmitir datos avelocidades
de 0.2-10
megabits por segundo (Mbps.),y algunas redes recientes que lo hacen a velocidades mayores
velocidades detransmisión
no ocasionan conflictos
de
tráfico
de
de 200 Mbps.Estas
comunicación o con los protocolos o en el costo del software, pero indicanel potencial de
rendimiento de las redes de área local, ofreciendo velocidades básicas de transmisión para un
mensaje de 1000 bytes en una rango que vade 4 milisegundos (ms.) a 40 microsegundos
( p . ) en las redes más rápidas.
E n las topologias usadas en redes de área local nohayretardos
conmutación.
por almacenamiento o
Las redes locales con velocidades
detransmisiónantes mencionadas de alrededor de 1
Mbps. deberían ofrecer un desempeño aceptable para su uso en sistemas distribuidos
ligeramente cargados (carga es una medida del rendimiento, del uso normalde un sistema
como un porcentaje de la capacidad total), ya que 10 Mbps. ofrece una capacidad razonable
para soportar sistemas que generan tráficosustancia4. Los experimentos con redes de área
local en sistemas distribuidos soportan esta conjetura.
TECNOLOGjA ETHERNET
Ethernet fue desarrollada en Xerox en 1973 como parte del programa intensivode
investigación llevado a cabo en estaciones detrabajo personales y sistemas distribuidos. El
piloto Ethernet fue la primer red de área local de alta velocidad, demostrando que es factible el
uso de redes
locales
de
alta velocidad enlazando computadoras en un sitio simple,
permitiéndoles comunicarse a altas velocidades de transmisión con bajas tasas de error y sin
retardos por conmutación.
S e describirá Ethernet como se
especifica
en
la Norma IEEE/ISO
802.3.
Opera a
velocidades de 10 Mbps. usando cable coaxial de baja pérdida, dispositivos de alta velocidad
en las computadoras conectadas a éI; el prototipo original Ethernet corrió a 3 Mbps. y muchas
redes posteriores han sido implementadas usando elmismométodo
básicoparauna
gran
variedad de aplicaciones. E n el nivel más bajo de costo son usados los mismos principios de
operación para conectar computadoras de bajo costo con velocidades de transmisión de 100200 kilobits por segundo (Kbps.).
I
Ethernet es una redde bus simple o ramificado y usa un circuito que consta de varios
segmentos continuos de cable coaxial de baja pérdida conectados por repetidores. Es un bus
laclase de redes descritas por la frase 'Detecciónde
de contención y es unmiembrode
Colisión/ Detecciónde Portadora con Acceso Múltiple" (CSMACD).
remoto
shell Implementación
un
de
64
"..-
Fundamentos de redes decomputadoras
Difusión de paquetes. El método básico de comunicación enredes CSMAlCD es por
difusión de paquetes de datos en un cable que es accesible a todas las estaciones de la red.
Todas las estaciones están continuamente ‘C;scuchando”elcable para detectar paquetes que
sean dirigidos a ellas. Cualquier estación que desee transmitir un mensaje difunde uno o mas
paquetes (llamados tramas en la Especificación Ethernet) en el cable. Cada paquete contiene
la dirección de la estación destino, la dirección de la estación emisora y una secuencia de bits
de longitudvariable representando el mensaje a ser transmitido. La transmisióndedatos
produce IO millones de bits por segundo y los paquetes varían en longitud entre 64 y 151 8
bytes, así que el tiempo para trasmitir un paquete en Ethernet tiene un rango de 50-1200 ps
dependiendo de su longitud.
La dirección de la estación destino normalmente se refiere a una interface de red simple.
Cada estación recibe una copia de cada paquete, pero ignora los paquetespara
otras
computadoras y pasan hasta su estación correspondiente solamente aquéllos paquetes que le
son direccionados. La dirección de la estación destino también podría especificar direcciones
de difusión o difusión restringida. Normalmente las direcciones se distinguen de las
direccionesde difusión y difusiónrestringidaporelvalor
desus bits demáspeso
(O y 1
respectivamente). Una dirección consta totalmente de 1’s si está reservada para usarse como
una dirección dedifusión y esusada cuando un mensaje va aser recibido por todas las
estaciones de la red. Cualquier estación que recibe un paquete con una dirección de difusión
la pasará a la siguiente. Una dirección de difusión restringida especifica una forma limitada de
difusión la cual es recibida por ungrupode
estacionescuyas interfaces de red han sido
No todas las
configuradas para recibir paquetes con direcciones dedifusiónrestringida.
implementaciones de interfaces deredEthernet
puedenreconocer direcciones de difusión
restringida.
El protocolo de red Ethernet (proporcionado para la transmisión de paquetes Ethernet entre
pares de estaciones) es implementado en lainterfacedehardware
Ethernet,así que el
software del protocolo es requerido para la capa de transporte y capas superiores a ésta.
EstructuradeunpaqueteEthernet.
Los paquetes (o tramas)
transmitidos
estaciones en Ethernet tienen la estructura de la Figura 6.
[
6 bytes
Dirección destino
I
6 bytes
Dirección fuente
I
246bytes
Tipo
-1518bytes
Datos
por
4 bytes
Secuencia de vcnlicaci6n de Innu
Figura 6. Estructura de un paquete Ethernet.
contiene un
Aparte delas direcciones destino y fuente yamehcionadas,lospaquetes
campo de tipo, campo de datos y una secuencia de verificación de trama. Note que la longitud
de los paquetes no es transmitida. Es vez de ello, la estación receptora detecta elfinde
transmisión (hay un intervalo obligatorio de 9.6 ps entre paquetes y se asume que los últimos 4
bytes recibidos constituyen la secuencia de verificación de trama. (En la Norma IEEE/802.3la
65
Capítulo 2
longitud del campo de datos es transmitido en lugar de el campo de tipo, pero la información
de tipo es importante en interedes [conjunto de redes conectadasentre sí] ya que permite que
protocolos de transmisión múltiple sean transmitidos sin interferencia y dicho campo ha sido
conservado en la mayoría de las implementaciones Ethernet).
El campo de tipo es usado por las capas superiores de protocolos para distinguir paquetes
devarios tipos. La especificación no permite más de 1024 estaciones en una red Ethernet
simple, pero las direcciones ocupan 6 bytes, y cada interface de hardware Ethernet es dada
como una dirección única por el fabricante, con el fin de permitir que todas las estaciones en
un conjunto de redes Ethernet interconectadas tengan
direcciones únicas. El IEEE actúa como
una autoridad de distribución de direcciones Ethernet, asignando direcciones enrangos
separados de48 bits para los fabricantes de interfaces de hardwareEthernet.
El campo de datos contiene o todo parte (si la longitud del mensaje exceda de 1518 bytes)
de el mensaje que está empezando a transmitirse. Es el Único campo cuya longitud puede
variar entre límites definidos. El límite inferior de 46 bytes enla longitud del paquete es
necesaria para asegurarse que las colisiones puedan ser detectadas por todas las estaciones'
de la red.
La secuencia de verificación de la trama es un verificador general, insertado por el emisory
usadoporel
receptor para validar paquetes. Los 'paquetes de validación incorrecta son
simplemente ignorados porla capa de enlace de datos en
la estación receptora.
Este es un ejemplo de el potencial de falta de integridad de los protocolos de datagramas
simples usados en redes locales; para garantizar la transmisión de un mensaje, la capa de
aplicación debe usar un protocolo que reconozca la recepción de cada paquete y retransmitir
cualquier paquete no reconocido. La incidencia de corrupción de datos en redeslocales es tan
pequeñaque el usode este métododerecuperacióncuando
la entregagarantizada es
requerida es perfectamenteaceptable.
Colisiones de paquefes. Aúnenel
tiempo relativamente corto quetoma transmitir
paqueteshayuna
probabilidad finita dequedosestacionesde
la red intenten transmitir
mensajes simultáneamente. Si una estación intenta transmitir un paquete sin verificar si el
cable es usado porotras estaciones, puede ocurrir una colisión.
Ethernet tiene tres mecanismospara tratar ésta posibilidad. La primeraesllamada
detección de portadora; el hardware de interface en cada estación escucha para detectar la
presencia de una señal (conocida como portadora por analogía con
la radiodifusión) en el
cable. Cuando una estación desea transmitir un paquete espera hasta que ninguna señalesté
presente en el cable y entonces empieza a transmitir.
las colisiones. La
Desafortunadamente, la deteccióndeportadoranoorevienetodas
ser
posibilidad de colisión se mantiene durante el tiempo finito z que le toma a una señal
insertada en el cable (viajando a velocidad electrónica: aproximadamente 2x108 metros por
segundo) para alcanzar todoslos otros puntos. Considérense dos estacionesA y B que están
ya listas para transmitir paquetes casi al mismo tiempo. Si A empieza a transmitir primero, B
puede verificar y no encontrar señal en elcable en el tiempo t<r después de que A empezó a
66
Implementación
de
un shell remoto
Fundamentos de redes de comwtadoras
I
transmitir. B entonces empieza a transmitir, interfiriendo con la transmisión de A. Tanto los
paquetes deA como los de B serán dañados porla interferencia.
La técnica usada para recuperarse da tal interferencia es llamada detección de colision.
Cada vez que una estación está transmitiendo un paquete a través de su puerto de salida de
hardware, también escucha ensu puerto de entraday las dos señales son comparadas.Si son
diferentes, entonces ha ocurrido una colisión. Cuando esto sucede la estación detienela
las
transmisión y produce una señal de obstrucciónen el cable para asegurarse de que todas
estacionesreconozcan la colisión. Como se hadetectado ya, esnecesario un paquetede
longitud mínima,
para
asegurarse
que las colisiones siempre son
detectadas.
Si dos
estaciones transmiten casi simultáneamente desdeextremos opuestos de la red, no llegarán a
enterarse
de
la
colisión por 2.s segundos (porque el primer
emisor
debe
estar aún
transmitiendo cuando recibe la segunda señal). Si el paquete que las estaciones transmitan
tomamenosde T para ser difundido, la colisión no será notificada, ya quecada estación
emisora no podrá ver el otro paquetehasta después dequehaya
finalizado su propia
transmisión, mientrasque
las estacionesenpuntos
intermedios podrían recibir ambos
paquetes simultáneamente,resultando una corrupción de datos.
Despuésde la señal de obstrucción, todas las transmisiones y estacionesde escucha
cancelan el paquete actual. Entonces las estaciones transmisorastienen que intentar transmitir
sus paquetes otra vez. Surge ahora una dificultad posterior. Si las estaciones involucradas en
la colisión intentan retransmitir sus paquetesinmediatamentedespuésdela
serial de
obstrucción probablemente ocurra otra colisión. Para evitar esto,es
usadauna técnica
conocida como cerrar a la inversa. Cada una de ¡as estaciones involucradas en una colisión
elige esperar un tiempo n.r antes de retransmitir. El valor de n es un entero aleatorio escogido
separadamente en cada estación y limitado por una constante L definida en el software de la
red. Si ocurre una colisión posterior, el valor de L es duplicado‘ y el proceso es repetido si es
necesario hasta 10 intentos.
Finalmente, la interface dehardwareenla
estación receptora computa la secuenciade
verificación y la compara con lasumatransmitida en el paquete. Si la comparación falla el
paqueteesrechazado
(esto es, no es transmitido). Usandotodasestas
técnicas, las
estaciones conectadas a Ethernet son capaces de manejar el uso del cable sin algún control
centralizado o de sincronización.
I
Eficiencia Ethernet. La eficiencia deuna red Etherneteslarazónde
el númerode
paquetes transmitidos correctamente con respecto al número teórico máximo que podría ser
transmitido sin colisiones. La eficiencia es afectada por el valor de T, ya que el intervalo de 2r
segundos después de la transmisión de un paquete inicia la Ventana de oportunidad”para las
colisiones (una colisión no puede ocurrir después de 2r segundos después de queun paquete
empieza a ser transmitido). También es afectada por el número de estacionesen la red por su
nivel de actividad.
Para un cable de 1 km. el valor de T es ’menor que 5 ps. y la probabilidad de colisiones es
enormemente pequeria para asegurar una gran eficiencia. Ethernet puede lograr la utilización
de un canal entre un 80% y 95%, aunque los retardos debidos a la contención llegan a ser
perceptibles cuando es excedido el 50% dela utilización. Como la carga es variable, es
67
Caritulo 2
imposible garantizar la entrega de un mensaje dado dentrode un tiempofijo, ya que la red
podría estar completamente cargada cuando el mensaje ya está listo para la transmisión. Pero
la probabilidad de transferir el mensaje con un retardo dado es tan buena, o mayor que otras
tecnologías de redes.
Las mediciones empíricas de eficiencia de una red Ethernet en Xerox PARC y reportada por
Shoch y Hupp confirman este análisis. E n la práctica, las redes Ethernet usadas en sistemas
distribuidos están relativamente cargadas. La mayoría de las veces no operan con estaciones
esperando transmitir y cerrar el canal de utilización.
Ethernets inferconecfadas. Ya que las direcciones permitidas para todas las interfaces
Ethernet sonúnicas,puedenser
interconectadas dos o más Ethernets, permitiendo alas
computadoras de las redes interconectadas comunicarse sin temor de que existan direcciones
duplicadas. Hay dos tipos de conexión en este nivel: repetidores y puentes (dispositivos que
conectan redes de igual tipo). Mientras que un repetidor es un dispositivo electrónico analógico
que simplemente reemite lasseñales eléctricas que ;ecibe, un puente es una computadora
que pasa paquetes entre lasredes que están interconectadas. Los puentes tienen muchas
o distorsión
ventajas: como operan digitalmente en elnivelde
paquete norepitenelruido
eliminando el problema de retardo de extremo a extremo: cualquier número de redes Ethernet
de cualquier longitud pueden ser interconectadas usando puentes.
La mayoría de los puentes pueden hacer algo mejor que sólo tomartodos los paquetes
recibidos en la interface de una red Ethernet y retransmitirlos en la interface a otra Ethernet.
Pueden por ejemplo guardar una lista de las direcciones de cada red Ethernet y retransmitir
solamente aquellos paquetes que estén destinados a una Ethernet diferente. Un puente puede
también ser programado para filtrar mensajes de 'salida a destinos particulares.
TOKEN RING
Las Token Rings fueron exploradas a principios de la época del desarrollo de redes locales,
pero su explotación ha sido más lenta que la deotras tecnologías de redde árealocal.
Empero, han sido usadas en varios productos comerciales e IBM ha adoptado un token ring
que conforma
la
Norma IEEEllSO 802.5 como una bafe para productos de sistemas
distribuidos. Pueden ser transmitidos mensajes de casi cualquier longitud como paquetes
sencillos. Esto se ha logrado con la ayuda de una ficha circulando permanentemente que tiene
un formato distribuido.
Puede ser útil una analogía con eltransportede carga por tren en la comprensión de la
operación de token rings. La analogía tomael paquete ficha como una locomotora que está
circulando eternamente alrededor de una pista cerrada (circular) y a los paquetes dedatos
como vagones de carga. La locomotora está marcada como 'ocupada'lo 'libre'. Cuando no hay
vagones pegados a la locomotora, está libre, en otro caso está ocupada. Los vagones
contienen datos que pueden ser unidos a la locomotora cada vez que pasa una estación y no
está ocupada.Cuando los vagonesson unidos la locomotora semarca como llena y la
68
remoto
shell
un
Implementación
de
dirección de destino de los vagones semarca en la locomotora. La estación destino debe
separar los vagones cuando pasany marcar la locbmotora comolibre.
Una ficha simple es usada en la mayoría de los token rings. Circula continuamente y hay
una estación monitor que introduce una ficha libre si ésta es omitida (para inicializar la red y
para prevenir la pérdida del token cuando una estación falla). En el Token Ring IEEE la ficha
ocupa tres bytes y es usado un bit sencillo en el token para indicar si está ocupada o libre.
Cuando el token está libre, no circulan otros datos en el anillo. Cuando está ocupado, el token
es seguido de una secuencia de campos de bytes de direcciones y datos. El formato de los
paquetes y fichas se muestra en la Figura 7
3 bytes
6 bytes
6 bytes
Token
Dirección
Dirección
fuente
destino
S
4 bytes
5000 bytes
Datos para
1 byte
Delimitador
verificaci6n transmisi6n
final
Secuencia de
1 bvte
Estado de la
trama
de trama
Figura 7. Formato de un paquete o ficha en una red TokenRing.
Un token tiene el siguiente formato:
I
1 byte
I
1 byte
Delimitador inicial
Control acceso
de
1 byte
I
Control trama
de
1
Figura 8. Formato de Token.
El byte delimitador inicial tiene un patrón fijo de bits que habilita a las estaciones para
reconocer el inicio de la trama y sincronizar la velocidad de transmisión para datos. Los ocho
bits del campo de confrol de acceso son usados para distinguir entre fichas ocupadas y libres,
para identificar la prioridad de la trama que está siendo transmitida (3 bits) y para reservar la
siguiente trama libre con una prioridad dada (3 bits). La estación monitor usa el octavo bit para
ayudar a verificar que el anillo esté funcionando correctamente.
La operación del token ring sigue el patrón en la analogía del ‘tren de carga:’ Una estación
que desea enviar un mensaje verifica el campo de control de acceso y coloca el bit a ocupado
si dicho bit está libre. Los campos de dirección destino y fuente son insertados por la estación
emisora, y los datos del mensajesonagregadosa
ellos, seguidospor la secuencia de
verificación de trama y el delimitador final. La estación destino coloca el campo de control de
acceso a libre y quita los campos arrastrados de el token.
No se detallará el uso de la prioridad y reservación de bits en el campode control de
acceso; su propósito es habilitar una variedad de regimientos para compartir la capacidad del
69
CaDítulo 2
canal entre las estaciones de la red. Una consecuencia importante es que pueden ser usados
para asegurar una distribución correcta de la capacidad del canal entre estaciones esperando
o dos
transmitir mensajes',previniendo la apropiación total del anchodehandaporuna
estaciones.
El tokenring no sufre de las desventajas de paquetes pequeños o de tamaño fijo (los
paquetes pueden en principio ser de casi cualquier longitud1 la limitación a 5000 bytes es un
valor de defecto, para un parámetro que puede ser configurado en una preinstalación básica).
El requerimiento para una estación monitor es la más fuerte desventaja que queda.
MODELO DE TRANSFERENCIA ASíNCRONO (ATM)
ATM ha sido diseñada para llevar una grancantidad
de datos, incluyendodatos
de
multimedia tales como voz y video. Es una red deconmutación de paquetes rápida basada en
el método de enrutamientoconocidocomo celda de relevo que puede operar muchomás
rápido que la conmutacióndepaquetes convencional.Lograéstasvelocidadesevitando
la
verificación de control de flujo y de errores en los nodos intermedios en una transmisión. La
transmisión los enlaza y así los nodos deben tener una baja probabilidad de corrupción de
datos. Otro factor que afecta el desempeño es la pequeña longitud fija de unidades de datos
transmitidas, lo cual reduce el tamaño del buffer, la complejidad, y los retardos de la cola en
nodos intermedios.
A I M opera en modo conectado, pero solamente una conexión puede ser establecida si los
recursos suficientes están disponibles. Una vez que una conexión es establecida, su calidad
(esto es, sus características de latencia y ancho de banda) pueden ser garantizadas.
Está hecha para ser estratificada sobre, RDSI-BA,conforme la NormaCCITT 1.150, pero
puede ser implementada como una red de conmutaciónATM pura (llamada también modo
nativo). En ambos casos, el medio de transmisiónpara el quese ha diseñadoes la fibra
óptica, permitiendo anchos de banda de varios gigabits por segundo con latecnología de fibra
actual. RDSI-BA ha sido diseñada para soportar un amplio rango de servicios con varias
velocidades.Estos incluyenvoz (32 Kbps.), fax, servicios de sistemas distribuidos, video,
televisión de alta definición (100-150 Mbps.). Para la implementación de ATM sobre RDSI-BA,
la norma ha seleccionado velocidades de transferencia de datos de 155 Mbps., pero también
es recomendada una velocidad futura de622 Mbps..
El servicio ATM puede ser visualizado en tres capas como se muestra en la Figura 9. La
capa de adaptación ATM está ideada paraproporcionar interacción con protocolos de alto
nivel tales como TCPAP y X.25 sobre la capa ATM. La capa debería ser capaz de proporcionar
varias funcionesdeadaptación
diferentes para una seriede requerimientos de diferentes
organizaciones. Incluirá algunas funciones comunes tales como ensamblado y desensamblado
de paquetes para usaren laconstrucción específica de protocolos de capas superiores.
70
MENSAJES
CAPAS
Aplicación
Protocolos de capas superiores
I
Capa de adaptación ATM
I
CapaATM
I
les ATM
Figura 9. Capas del protocolo ATM.
La capa ATM proporciona unservicioorientado
a conexión que transmite paquetes de
longitud fija llamados celdas. Una conexión consta de unasecuenciade canales virtuales
(VC)dentrode caminos virtuales (VP). Uncanal virtual es una asociación unidireccional lógica
entre dos puntos extremos de un enlace en la ruta física desde el fuente hasta el destino. Un
camino virtual es una Bnvoltura”de canales virtualesque estánasociadoscon
un camino
I
físico entre dos nodos de conmutación. Los caminos virtuales están hechos para soportar
conexiones semipermanentes entre pares depunto
extremos. Los canales virtuales son
colocados dinámicamente cuando se establecen las conexiones.
Los nodos en una red ATM pueden jugar tres roles distintos:
1 . Anfitriones que envían y reciben mensajes.
2. Conmutadores VP que mantienentablasquemuestran
caminos virtuales entrantes y salientes.
3. Conmutadores V P N C quemanejantablassimilares
canales virtuales.
la correspondencia entre
tanto para caminos como para
En ATM una celda tiene una cabecera de 5 bytes y un campo de datos de 48 bytes (Figura
I O ) . El campo dedatos siempre es enviado completoaún cuando sólo esté lleno con datos
parcialmente. L a cabecera contiene unidentificador parauncanal virtual y unidentificador
para un camino virtual; los cuales juntos proporcionan la información requerida para enrutar las
virtual
celdasa través de la red. El identificador de camino virtual se refiere auncanal
especifico dentro del camino virtual. Otros campos de la cabecera son usados para indicar el
tipo de celda, si se pierde la celda, prioridad y la frontera de la celda.
71
Capítulo 2
<
ldentificador del
camino virtual
Cabecera: 5 bytes _______j
ldentificador del canal Banderas
virtual
53 bytes
.
Datos
>
Figura I O . Estructura de una celda ATM.
Cuandounacelda
llega a un conmutador VP, el identificador delcamino virtual en la
cabecera es buscado en su tabla de enrutamiento para preparar el identificador del camino
virtual correspondiente para el camino físico de salida (ver Figura 11). El conmutador VP pone
el nuevo identificador de camino virtual en la cabecera y entonces transmite la celda en el
camino físico de salida. Unconmutador VPNC puede ejecutar un enrutamiento similar en
ambos, el identificador de caminovirtual y en el identificador del canal virtual.
Note que los identificadores de camino virtual y de canal virtual son definidos localmente.
Este esquema tiene la ventaja de que no son necesarios identificadores de red área ancha
Un esquemade
locales, en cuyocaso
sería necesariousarnúmeros
muy
grandes.
direccionamiento global podría introducir gastos administrativos y requeriría cabecerasde
celdas y las tablas en los conmutadores mantendríanmás información.
VPI = ldentificador del camino
VPI = 2
VPI = 5 Entrada
Salid
"
"
"
"
"
"
"
Camino virtual1
"
"
"
"
"
"
"
"
"
"
"
"
"
"
E C a n a l e s virtuales
Figura 1l . Conmutación decaminos virtuales en una red ATM.
ATM proporciona un servicio con baja latencia (el retardo de conmutación sería alrededor
de 25ps por conmutador, dando por ejemplo unalatencia de 250 ps cuando un mensaje pasa
a través de 10 conmutadores).Comparar esto con los requerimientosderendimiento
estimados para un sistema distribuido
72
"
Implementación
de
un shell remoto
REDES DE ORDENADORES
Prentice Hall HispanoamericanaS.A. [1991]
Andrew S . Tanenbaum
Págs. 3-6.
Monografía [I9941
Ricardo Marcelin Jiménez
Orestes Téllez Analco
Rubén Vázquez Medina
Págs. 2-4, 7-17.
SISTEMAS OPERATIVOS. CONCEPTOS FUNDAMENTALES
Addison-Wesley Iberoamericana [I9941
Abraham Silberschatz
James L. Peterson
Peter B. Galvin
Págs. 452-456.
DISTRIBUTED SYSTEMS. CONCEPTSAND DESIGN
Addison-Wesley Publishing Company [1994]
George Coulouris
Jean Dollimore
Tim Kindberg
Págs. 66-69, 75-84.
I
I
73
CAPÍTULO 3
EL
SISTEMA
OPERATIVO
UNIX
1
I
EL SISTEMA OPERATIVO WNlX
[TOMADO Y ADAPTADO DE Coffin, Peterson y RiffletI3
Características del sistema UNIX:
Herramientasdesoftware.
Los problemas pueden ser resueltos y las aplicaciones
creadas mediante la interconexión de unas cuántas piezas simples, las cuales realizan bien y
completamenteuna tarea. Enel dominio de desarrollo, las subrutinasempaquetadasse
combinanpara formar nuevos programas ejecutables (este conceptobásicosedenomina
reutilización de software).
Porfabilidad. El sistema UNlX ha sido trasvasadoa casi cualquier computadora de
tamaño moderado o grande. El aumento en el potencial de proceso en las microcomputadoras,
hace natural la aplicación del sistema UNlX a dichas máquinas. Generalmente
se reconoce
queel sistema UNlX proporciona el entornoadecuado para permitir el fácil traslado de
aplicaciones desde micro hasta maxicomputadoras, independientemente del tipo y antigüedad
entre las arquitecturas de las máquinas y las diferentes versiones del sistema UNIX.
Flexibilidad. UNlXes muy flexible para los creadores de hardware y software: se ha
adaptado a aplicaciones tan diversas como
automatización
de fábricas, sistemas de
conmutación telefónica y los juegos personales. Se extiende fácilmente añadiendo funciones y
órdenes a paso rápido, y se le considera un banco de trabajo” paralas aplicaciones en
general.
Potencia. Tiene una sintaxis de órdenes clara y concisa, lo cual permite realizar muchas
cosas rápida y sencillamente. Es extremadamente potente (posiblemente el sistema operativo
más potente).
Mulfiusuario y multifarea. UNlX es un entorno multitarea de tiempo compartido, por lo
cuál se puede hacer más de una cosa a la vez. También es un entorno multiusuario que
soporta las actividades de más de una persona a l a vez (cientos de usuarios).
Elegancia. Una vez que los usuariosentiendenalgunos
de los conceptosbásicos
sistema UNIX, pueden realizar muchas y grandes tareas de un modo sencillo y elegante.
del
Orientación a red. Las versiones modernas de UNlX están organizadas para un uso de
red fácil y funcional. El sistema UNIX proporciona herramientas internas de comunicación, fácil
aceptación de rutinas de dispositivos de bajo nively organización flexible de ficheros.
Capítulo 3
EL SABER Y LA CONTROVERSIA QUE RODEAN AL SISTEMA UNlX
Los “entusiastas” de UNlX alaban su elegancia, potencia y flexibilidad, y son comúnmente
expertosencomputadoras.Los
principiantes deUNlXsongeneralmente
sus “enemigos” y
critican su sintaxis mínima, los extraños nombres de sus órdenes, su documentación escasa y
la complejidad desu administración.
El sistema UNlX está orientado en principio a usuarios expertos, sin embargo en las últimas
versiones de UNlX se ha manifestado la preocupación por los usuarios novatos, incorporando
mejoras en las siguientes áreas principalmente:
Robustez. El sistemaUNlXha
sido endurecidodemodoque
se requiere muy poco
mantenimiento de software para mantener el sistema ajustado y operando al máximo. Se han
automatizado muchastareas.
Consistencia. Las órdenes han evolucionado para adodtar una
sintaxis más consistente.
Agentesdeusuario.
Seproporcionangeneralmenteherramientas
ayudar a laconfiguración y administración del sistema UNIX.
simplificadas para
Nuevas características.Muchas capacidades y órdenes nuevas se han introducido en el
sistema UNlX en las últimas versiones: nuevas características y una, nueva organización del
sistema para soportar conexiónen red;. el entornode desarrollo ha sido mejorado y está
creciendo el soporte para procesamientocompartido en múltiples máquinas.
lnteroperabilidad. Las interfaces binarias de aplicaciones (AB0 y la interfaz de
sistema evolucionarásegún
vías
programación de aplicaciones (AM) aseguranqueel
predecibles. Por lo tanto, los programadorespueden confiar enque sus inversiones en
productos de software mantendrán su valor. El sistema UNlX se está desplazando hacia un
mayorcompromisoconelestándar
internacional POSlX desistemas operativos, el cual
proporciona un conjunto mínimo de funciones.
Cornparfición del sistema operativo. La compartición de sistemas operativos significa
que las capacidades multitarea del sistema UNlX pueden ser utilizadas para ejecutar MS-DOS
entero (o el FINDER de Macintosh) como un proceso bajo el sistema UNIX, permitiendo así
quetodas
las funciones“subordinadas”del
sistema UNlX se ejecutenmientrasestén
ejecutándose programas enel otro sistema operativo.
LA FILOSOFíA TRAS EL SISTEMA UNlX
El principio fundamental de UNIX, fue diseñar órdenes que sólo hicieran una cosa, pero que
la hicieran deforma simple, silenciosa y bien. Porejemplo, unaordenparaconcatenar
y
visualizar ficheros, no debería tratar de paginar la salida o de imprimir los ficheros sobre una
impresora.
78
Implementación
de
un shell remoto
El sistema operativo UNlX
I
Como consecuencia de implantar esta filosofía se tienen los siguientes efectos importantes:
1. La salida dealgunadelasherramientas
(órdenes de propósito simple) debe ser
canalizada a la entrada de otras herramientas. De esto surge el concepto de cauce de
órdenes.
2. El desarrollo de nuevas órdenes y otras aplicaciones fue mucho más fácil que en otros
sistemas operativos, de modoqueUNlXhaexperimeqtadoavances
y crecimiento
substanciales, facilitando el desarrollo y mantenimiento de software.
3. El sistema UNlXcontiene un grannúmero de órdenes de propósito sencillo. Las
dificultades asociadas a la existencia de muchas órdenes están más que
equilibradas
con la flexibilidad y potencia que el planteamiento de las herramientas proporciona.
EL SISTEMA UNlX MODERNO
El sistema UNlX esmásgrande
y complejo que MS-DOS u OS12,sin embargoofrece
muchas características que dichos sistemas operativos no ofrecen.
La filosofía de “hacer una cosa bien” en el sistema UNlX primitivo se ha perdido hasta cierto
punto en las versionesmodernas, y las órdenesactuales contienen un grannúmerode
opciones y controles; por tanto, aunque. las órdenes pueden ahora ser más difíciles de utilizar,
también pueden ser adaptadas a nuevas situaciones sin cortosiones o ineficiencias.
El sistema UNlXestá orientadoprincipalmentea
terminales basadas en cardcfer. Se
requiere un software especial denominado sistema de ventanas X para hacer que el sistema
UNlX funcione con pantallas gráficas de cada mapa de bits. En consecuencia la mayoría de
herramientas y procedimientos son orientados a líneas de órdenes y las herramientas de ratón
y menús que utiliza la pantalla gráfica están apenas apareciendo masivamente.
Por otra parte, elsistema UNlX permite a un usuario invocar una máquina remota desde un
terminal barato, sobre líneas telefónicas baratas.
El sistema UNlX va contra la tendencia actuallde hacer los sistemas operativos “invisibles”
al usuario. La interfaz deusuario orientada a la ventana y menús ayuda a ocultar las órdenes,
los sistemas de ficheros y las herramientas administrativas del usuario. Ahora, aunque el en
sistema UNlX se han preparado herramientas tales como los agentes del usuario para aislar a
este de muchas complejidades del sistema operativo, se piensa que mientras más consciente
se es de las funciones internas del sistema, mejor se pueden controlar en beneficio propio y
para mejorar suproductividad.
79
Capitulo 3
HISTORIA DEL SISTEMA UNlX
*
Los avances importantes en el sistema UNlX no han venido principalmente de discusiones
burocráticas, sino más bien de lasnecesidades y la creatividadde los usuarios.
El sistema UNlX fue diseñado por un grupo de personas que eran representantes de AT 8,
T. Ken Thompson y Dennis Ritchie construyeron el
sistema basado en un diseño que ellos
mismos elaboraron junto con Rudd Canaday. Como muchos de los mejores proyectos, este
comenzó con la creaciónde un juego. El nombre UNlX fue pronto aplicadoa los resultados, ya
que su trabajo era una simplificación delsistema MULTICS.
La implementaciónoriginalfuecodificada
en lenguaje ensamblador, peropronto
se
desarrollóel lenguaje de programaci6n C dentro delgrypo, comenzando en 1971. Casi
inmediatamente, el lenguaje C fue utilizado en la continuación
del desarrollo del sistema UNIX,
y en 1973 se recodificó el núcleo en C. Este fue el primer intento de codificar un sistema
operativo completo en un lenguajede alto nivel, aumentando su portabilidad.
,
En estos mismos años se introdujeron las herramientas de procesamiento de texto que
posteriormente dieron lugar a troff. El primer cliente de UNlX fue la oficina de abogados de
patentes de los laboratoriosBELL, y AT & T comenzó a soportar el proyecto interno dentrode
los laboratorios BELL, en la familia de máquinas PDP.
Simultáneamente,AT
& Tremitió
numerosas copias del sistema UNlXatodaslas
universidades del mundo y una generación completa de informáticos aprendió su profesión, a
finales de los setenta, con el sistema UNIX.
Aparecieron innovaciones eimplementaciones como la BSD (Software DistribuidoBerkeley)
en la Universidad de California en Berkeley.
A finales de los setenta, AT & T introdujo un nuevo esquema de denominación para su
versión en UNIX. Las versiones más recientes se denominan sistema V revisión 3 y sistema V
revisión 4 que se abrevian como SVR3 y SVR4, respectivamente.
A finales de los setenta y comienzo de los ochenta, una o ambas versiones BSD y AT & T
fueron portadas a casi todas las computadoras con potencia para soportarlas. Hoy en día se
puedenadquirir versiones de UNlXparalas
mayores supercomputadoras, lasmáquinas
centrales más ampliamente utilizadasy casi todas las minicomputadoras.
Las versiones BSD fueron plataforma dominante para experimentación en conceptos de
red, por lo que algunas de las mejores redes de área local están disponibles para el sistema
redes de área extensa, el ARPANET, fue
UNIX. El primerexperimentoimportanteen
principalmente orientada hacia el sistema UNIX. El NFS (Sistema de Ficheros de Red) creado
por Sun Microsystems, y el RFS (Compartición Remotg de Ficheros), creado por AT & TI son
los productos finalesde esta evolución.
AI incrementarse en velocidad y potencialas microcomputadoras y disminuir su costo, estas
máquinas se han desplazado al rango del sistema UNIX.
80
I
Cuando los sistemas SVR3 y SVR4 estuvieron disponibles en máquinas dearquitectura PCAT a finales de los ochenta, la popularidaddel sistema UNlX dio un gran paso hacia adelante.
Lasmáquinas 80386 de tipo AT proporcionabanciertamente un entornoasequiblepara el
sistema UNIX, y más de la mitad de los sistemas UNlX que corren hoy en día utilizan esta
popular computadora.
Otro paso importante ha sido la aparición del sistema de ventanas X como pieza de amplia
aceptación del sistema UNIX. Otros sistemas de ventanas orientadas a ratón fueron creadas
Apollo, perocomoestándarde
la industria no
en el entorno del sistema UNlXporSuny
propietaria, X ha dominado.
Recientemente, los laboratorios BELL AT & T han desarrollado una nueva versión genérica
denominada Edición Décima, o sistemaUNlX de investigación. Esta versión no se vende
comercialmente, perose ha distribuido a universidades.
En las últimas revisiones de SVR3 se inició una mezcla de las tres variantes principales del
sistema UNIX, y esta convergencia está casi a punto de terminar en SVR4. Hoy día, como
resultados de los acuerdos entre AT & TI Sun Microsystems y Microsoft, los sistemas BSD y
XENIX estánfundidosdentro
del sistemaV. Esteproducto tombinado” también permite
compatibilidad de código objeto entre variantes producidas parael mismo tipo de máquina.
A la vez que se producía la fusión de BSD y el sistema VI otros vendedores de UNlX se
preocupabandehacer
otro tanto en elmercadodeAT
& T y SunMicrosystems.Estos
vendedores (principalmente IBM, Hewlett-Packard y DEC) fundaron un consorcio llamado la
Fundación de Software Abierto (OSF). En respuesta AT & T y su grupo han formado UNlX
International, para normalizar y dar a la publicidad revisiones del sistema V en la década de
los noventa. Algunas compañíasparticipan en varios grupos.
Apple Computer ha adaptado SVR4 para su familia de computadoras Macintosh, de modo
similar a como MS-DOS hasido incorporado enlos productos Merge y Simultask.
I
La potencia del sistema UNlX para acomodarse a diferencias en hardware se ilustra bien
con la aparición de las Computadoras De Repertorio de Instrucciones Reducido (RISC) a
máquinas RISC hanadoptadoel sistema
principios de los noventa. Virtualmentetodaslas
UNIX. Como resultado, lasmicrocornputadorasmás rápidas y mejores disponibles hoy, son
máquinas RISC.
Con el avancede la décadade los noventa, el desarrollo más significativo serán las
características de multiproceso que permiten a las máquinas contener más de un chip de
CPU central (sistemas distribuidos). Lossistemas multiproceso seránciertamente un factor
importante en la vida de SVR4.
Lasideas
y herramientasde
éxitoquese
originen enunode
los sistemasserán
eventualmente adoptados por el otro, pero probablemente no de inmediato. Esto mismo es
cierto para otros sistemas operativos. Las innovaciones en MS-DOS, OS/2, NeXT, el entorno
de Macintosh y las versiones IBM16000 del sistema UNlX están con frecuencia disponibles
Universidad
Autónoma
Metropolitana. Unidad lztapalapa
81
Y
Capítulo 3
comopaquetesañadidospara
SVR4.
.
LA VERSION SVR4
La versión SVR4 es la versión más actualizada del sistema UNlX de A T & T. Muchas de las
características novedosas son principalmente
de
interés
para
creadores
de
software y
administradores del sistema, pero la mayoría,sona
nivelde usuario enaplicaciones más
fáciles,másrápidas,mejores,
o menoscaras.Algunasdelasmás
importantes sonlas
siguientes.
Soponte de conexión en
red. La mejora más importante de SVR4 es la adición de
soporte completo para redes de área local. Tanto el sistema RFS de A T & T como el sistema
NFS estándar en la industria para redes, soporta SVR4. La administración remota es posible
ahora a través de la red. Las herramientas de multiproceso (que se añadirán posteriormente)
pronto permitirán que las máquinas conectadas en red compartan sus cargas de trabajo.
Unificación. SVR4 hadadopasos
importantes hacia la unificación de las diferentes
versiones del sistema UNIX (especialmente BSD y XENIX). Esto permite a los programadores
y
crear aplicacionesparauna
versión del sistema envezdemuchasversionesseparadas
diferentes.
1
El entorno de desarrollo en lenguaje C ha sido
ampliamente mejorado en SVR4. Existe un nuevo compilador C que cumple la norma ANSI y
que funciona significativamente mejor que las versiones más antiguas.
Nuevoentornodedesarrollo.
/nternaciona/izacic)n.El lenguaje de los mensajes del sistema, los convenios de fecha y
moneda, y otras variantes locales están incluidas por el sistema por primera vez. El sistema se
acerca globalmente al cumplimiento de los estándares internacionales para sistemas
operativos.
Sistema de ventanas X. SVR4 incluye la interfaz gráfica X.
Órdenes o Comandos. S e han añadidomuchasórdenesnuevas
“tradicionales”del sistema UNIX.
y características
Sisfema de ficheros virtual. El esquema VFS (Sistema de Archivos Virtual) permite
que numerosos tipos de sistemas de ficheros diferentes sean utilizados simultáneamente, y se
han incluido mejoras, incluyendo la eliminación del antiguolimite de catorce caracteres para
los nombres de ficheros.
Procesos en tiempo real.E n SVR4, un nuevo sistema de planificación permite procesos
aplicaciones desde
en tiempo real y rnicrofemporizadores, ampliando el rangocompletode
sistemas de tiempo compartido multiusuario hasta controladores dedicados al alto rendimiento.
82
lmplementación de un shell remoto
El sisterrla operativo UNlX
Configuración e instalación mejoradas. En el futuro, debería ser más fácil instalar un
nuevo sistema y añadir nuevohardware y paquetes de software a un sistema existente.
Seguridadmejorada. Laseguridad
sistema UNlX satisface ahoramuchasde
Estados Unidos.
del sistemaha sido extensamente mejorada y el
las exigencias de seguridad delgobiernode los
1
TEMAS AVANZADOS
’
Un sistema SVR4 requiere significativamente másmemoria real y discos rigidos mucho
mayoresqueSVR3u
otras versiones. En contrapartida, SVR4 entrega un sistema actual,
nuevas características de red y mejor soporte de herramientas de administración y desarrollo.
Requerimientos para microcomputadoras
Generalmente, una máquina SVR4requiere al menos 4 MB de memoria real (RAM) y 80 MB
de espacio en disco rígido rápido. El almacenamientotemporal de disco duro, seefectúa
generalmente por paginación. Un sistema UNlX totalmente configurado puede contener más
de40 MB de programasalmacenados y datosasociados. Existen más de 2000 órdenes
distintas, y alrededor de 6000 ficheros directorios en SVR4; el software añadido tal como el
entorno de desarrollo C estándar y los diferentes paquetes de red consumen casi un cuarto del
espacio de disco total. Sin embargo, es aconsejable disponer de al menos 80 MB de espacio
de disco rígido antes de cargar un sistema SVR4. Se requiere una memoria real grande, ya
que el nljcleo del sistema UNIX que reside en memoria y media en todas las conexiones entre
los programas del usuario y el hardware de la máquina, consume más de 1 MB por sí mismo.
La arquitectura incluye muchos buffers. Algunossistemas UNlX grandes configurados para
altas prestaciones conmuchos usuarios simultáneos tienen más de 40 MB de memoria real.
Ensamblaje de un sistema unix
Generalmente, un sistema operativo se elige sobre la base de las aplicaciones que están
disponiblespara prestaciones con muchosusuariossimultáneos
tienen más de40 MB de
memoria real; sin embargo, el entorno del sistema UNlX anima a la realización de
modificacionesy mejorassobre parte del software del sistema básico, y hay disponibles
muchos paquetes software que sustituyen a subsistemas importantes.
83
Capítulo 3
Los vendedores individuales con frecuencia han añadido o modificado el sistema bien para
personalizar el producto, o simplementeporquealgunaorden
o subsistemapodía
ser
mejorado. Esto ocurre confrecuencia en tres áreas:
1. Los programadores individuales o usuarios tienden a 'tecolectat'versiones de órdenes
que prefieren a las órdenes estándar. Estosprogramasamedidaaparecencon
frecuencia en las revisiones que se pueden adquirir.
2. El sistema de ficheros se reorganiza frecuentemente, dándose varios cambios, como en
los nombres de ficheros de dispositivos.
3. Los
vendedores
de
UNlX suelenproporciondrherramientaspersonalizadaspara
administrar el sistema. Con esto se gestiona más fácilmente la máquina, pero parte de la
flexibilidad y potencia incorporadas en las herramientas originales manuales se pierde.
Estos agentes de usuario suelen diferir notablemente unos deotros.
En general todos los aspectos de UNlX cambian con eltiempo.
Lasórdenes y herramientasestándarque
se aparecen aquí son los estándaresque
aparecen en la base de transporte del sistema V Versión 4, tal como lo entrega AT 8, T para
máquinas PC-AT 80386 y 80486.
Nota sobre compatibilidad BSD y XENIX
Históricamente las versiones BSD han sido significativamente diferentes de las versiones
delsistema
VI sin embargo SVR4 está efectuando un serio intento de incorporar las
características de éstas dosversiones.
Las herramientas BSD y XENIX disponen de paquetes de compatibilidad especiales que
permiten a los administradores del sistema permanecer en el sistema V o añadir los paquetes
de compatibilidad.
La compatibilidad de XENIX ha sido más fácil de lograr que la compatibilidad de BSD.
,
TUTORIAL
1. AI final de este
capítulo, se debería ser capaz de entrar y salir al sistema UNlX sin
dificultad.
2. Los tipos de terminales para los cuales se proponela sesión de éste capítulo pueden ser
de varios tipos: una consola del sistema, un terminal orientado a carhter conectado
directamentea un puerto RS-232 en la máquina, un terminalremoto conectado vía
84
-_I.
Implementación
de
un shell remoto
_~
.
-..
"
-.
- ."
.
.-.
"
telefónica y módem, o un terminal conectado a través de una red de área local(LAN).
Debido a que el sistema UNlX fue desarrollado originalmente para terminales de impresión
'tontos'; gran parte del sistema sigue suponiendo terminales orientadas a carácter y las etapas
iniciales del acceso al sistema requieren de tal terminal.
La versión del sistema UNlX disponible en países de habla inglesa utilizaelconjuntode
caracteres ASCII. Para usar el sistema de ventanas X, la interfaz usual orientada a ventanas,
es preciso estar en la consola del sistema o en un terminal inteligente orientado a red.
En primerlugar puede ser necesario presionar la tecla RETURN o ENTER para despertar al
sistema. AI hacerlo se verá el inductor de presentación, que es como éste:
Welcome to the AT&T 386
System name: mi-sis
UNIX
System
login:
Si no aparece el inductor login,algo va mal.
Un id de presentación Único identifica a cada usuario que puede conectarse al sistema. Por
medio de dicho id de presentación se tiene acceso a ficheros propios y se establece la sesión
deacuerdoconlas
preferencias que el irsuario haya seleccionado. El administradordel
sistema controla las presentaciones permitidas en cada máquina. Las exigencias de unid de
presentación es que tenga menos de ocho caracteres y esté formado sólo por letras y
números. E n este esquema, los caracteres mayúsculas y minúsculas se distinguen de modo
que el id de presentación LUIS no es igual que el id luis. Todos los idsde presentación
deberíancomenzarcon
un carácter minúscula; sielidde
presentación comienza con un
carácter mayúscula, el sistema UNlX pensará que se le está llamando desde un terminal que
sólo soporta mayúsculas, y funcionará de acuerdo con
ésta
suposición.
Cada id
de
presentación debe ser Único. El id de presentación es generalmente información pública.
Cuando se termine de introducir el id de presentación, presiónese RETURN. Generalmente no
se pueden corregir errores de mecanografía en este pupto, ya que el sistema aún no ha hecho
la identificación. El sistema UNlX tratael uso de la tecla BACKSPACE, por ejemplo, como una
preferencia del usuario. Si se comente u error en la introducción del id de presentación o en la
contraseña, se debe completar el proceso; el sistema proporciona otra oportunidad.
Después de haber introducido elid de presentación, el sistema UNlX responde solicitando
una contraseña individual, como se muestra aquí:
a5
I
Capítulo 3
login: luis
Password:
Se introduce la contraseña y se presiona RETURN. A diferencia del id de presentación, el
sistema no hará eco(no visualiza los caracteres de la contraseña mientrasse tecleen).
Si se teclea incorrectamente el id de presentación o la contraseña, (puede ser también un
introducido
usuario no autorizado), el sistema noinforma si el id depresentaciónfue
era la contraseña,perodaunasegunda
incorrectamente o si loqueestabaequivocado
oportunidad. Se introduce de nuevo elid de presentacióny luego la contraseña.
I
Cuandoelpar
iddepresentación y contraseñaha sido aceptado,apareceránalgunos
rótulos y mensajes iniciales. Los mensajes diferirán en cada sistema, pero pueden ser como
los siguientes:
t
UNIX
System V/386 Release 4 . 0
M i-si
identificaci6n de la mdquina
}
}
}
(única para cada sistema).
Derechos de copia para el software instalado en una mbquina.
Listado del
espacio y uso del disco.
Mensaje del dfa. Preparado por el administrador del sistema. Puede estar o no
presente. Se visualiza cada vez que serealiza una
presentaci6n hasta que el mensaje sea modificado o
suprimido por el administrador del sistema.
news: nuevo-Usuario }
YOU
Idenlificaci6n del sistema en uso.
have mail }
t
Noticias. Manejadas por el administrador.
I
Correo electrdnico. Hay un mensaje al menos, procedente de
otro usuario en el buzbn. Se verl este mensaje cada vez que
se haga una presentaci6n hasta que se suprima el correo.
A diferencia de la lectura de noticias, la lectura de correo
no suprime necesariamente el mensaje "You have mail" de la
pantalla de presentaci6n.
$ }
Finalmente cuando el proceso de presentaci6n se completa, el sistema
devuelve el control imprimiendo el inductor $ . Cada vez que se
visualice el $, el sistema estar5 esperando 6rdenes, las cuales serdn
enviadas al procesador de 6rdenes, el s h e l l .
LA PANTALLA DEL SISTEMA DE VENTANAS X
El sistema de ventanas X para el sistema UNIX, funciona en una terminal o computadora
suficientemente inteligente. Aparecerá un sistema deventanasen
lugar del inductor $.
Generalmente habrá:
Un menúWorkspace,que controla la sesióny define las preferencias.
Una ventana File Manager (Gestor de Ficheros).
Una o masventanas xterm, cadaunaconteniendo el inductor de shell $. Sellaman
UNIX.
emulador delterminal y permiten usarla linea de órdenes normal del sistema
Una ventana Mailbox (Buzón) (xbiff), que muestra que haycorreo a la espera mediante
86
.-
"
Implementación
de
un shell remoto
-.-
,
"
una bandera elevada enel icono del buzón.
Una ventana dela hora actual.
El sistema de ventanas Xestá controlado porratón y teclado.
LECTURA DE NOTICIAS
Loprimeroque se puedehacer es leer las noticias, ya que ello puede afectar eluso
posterior del sistema. Las noticias se leen escribiendo
$ news
y presionando luego RETURN.
Hay que recordar que los caracteres mayúsculas y minúsculas son diferentes en el sistema
UNIX.
Cuando se hayan leído todas las noticias, el programa news finaliza y devuelve el control al
shell; otro inductor $ recuerda queel shell está listo para obedecer nuevas órdenes.
LISTADO DE FICHEROS
Tras la presentación, el usuario se encontrará en un lugar específico dentro del sistema de
ficheros UNIX, llamado directon'o PROPlO [HOME]. Este es generalmente el lugar donde se
mantendrán los ficheros y datos privados. Cada usuario tiene un directorio propio personal.
Esto permite que diferentes usuarios puedan tener ficheros con los mismos nombres sin que
ello sea causa de problemas.
Se pueden listar los nombres de ficheros privados con la orden Is (por listar). No hay límite
con respecto al número deficheros permitidos dentro de un directorio.
En el sistema UNlX si no hay algo que decir, generalmente el sistema no dice algo. (Por
ejemplo: si no
hay
archivos,
se
lista nada).
1
La orden IS,como la mayoría de las órdenes de UNIX, tiene varias opciones y posibilidades.
Por ejemplo:
$ I s -1
total 2
-rw-rw-rw-rw-rw-rw-
1
1
luis
luis
o t h 1e r3A8p r
o t h e r 227
5 1 9 : 3 4 LEEME
Apr 5 1 9 : 3 3 nota
87
Capítulo 3
La adición de -I (menos ele) dice a la orden Is que genere unlistadolargo
(conmás
información que Is a secas). -I se llama argumento. A los argumentos que les precede el signo
(menos) se les denomina opción. Hay que dejar un espacio tras el nombre de la orden, pero
ningún espacio entre el signo y la letra del argumento.
-
-
E n el último listado (Is -I) el primer campo a la izquierda, -rw-rw-rw revela los permisos del
fichero; h i s es el propietario del fichero, que pertenece al grupo other. El tamaño del fichero en
bytes viene a continuación, seguido de una esfampacibn de tiempo para el fichero, y el último
campo de la línea es el nombre del fichero.
E n UNlX se utiliza
el sistema UNIX.
- en lugar de / que se utiliza en MS-DOS; el carácter / tiene otro uso en
S e puede consultar el Manual delusuario de UNlX, la principal referencia del sistema UNIX,
para conocer la sintaxis exacta de todos los argumentos de todas las órdenes.
VlSUALlZAClbN DE UN FICHERO
S e utiliza laorden
siguiente:
cat (por concatenar ficheros) para yisualizar los ficheros del modo
$ cat n o t a
(Nota es el nombre del fichero a visualizar). Los nombres de los ficheros son generalmente
argumentos sin o algún otro marcador de argumentos.
-
SUPRESIóN DE UN FICHERO
Para suprimir un fichero se utiliza la orden rm (por remover), como en el siguiente ejemplo:
$
$.
rm n o t a
S e ha suprimido el fichero nota. E n el sistema UNlX no hay modo de recuperar un fichero
una vezqueha
sido suprimido con rm. Puede utilizarse la orden rm -i nota (la -i es por
interactivo) para recibir una confirmación antes de suprimir el fichero:
$ rm -i n o t a
rm: remove n o t a(:y / n ) ?
88
Implementación
un
deremoto
shell
Se introduce y si se desea suprimir el fichero y cualquier otra cosa si no se desea suprimir
Sepuede interrumpir la ejecución de la ordenmientras ésta esperasurespuesta sise
desea regresar al shell directamente; para haceresto se presiona la tecla DEL o B A C K S P A C E en
el teclado. Esta acción de ruptura puede ser aplicada a casi cualquier orden UNlX que este
esperando entrada. También puede utilizarse ésta técnica para detener órdenes que están
generando demasiadasalida o que parezcanestar “colgadas”.
LECTURA DE CORREO
x
El correo electrónico es similar enfuncionamiento al correo que se recibe de la oficina
postal: permitecomunicación entre usuarios, cadapersona tiene una dirección de correo
única, y cada mensaje tiene un sobre y un contenido. Se puede leer la orden de correo con la
orden mail.
Esto instruye al shell para que ejecute la orden mail, la cual busca en el buzón del usuan’o y
muestra cada mensaje porturno en el terminal, como en éste ejemplo:
$ mail
From jim Fri Apr
Bienvenido luis
6
18:24
MST 1990
?
La primera línea de este recado por correo se conoce como timbre. Informa que el mensaje
proviene de jimy que fue enviado un viernes 6 de abril, a las 18:24 MST 1990.
El inductor ? le hace saber que el sistema UNlX está esperando una elección acerca del
mensaje de correo. Se puede suprimir el mensaje (pulsandod), pasar al siguiente mensaje (si
lo hay), salvar el mensaje enun fichero, o tomar una deotras acciones.
I
En el sistema de ventanas X, la bandera baja después de suprimir el mensaje de correo y
se levanta de nuevo tan pronto como llegue nueva correspondencia.
Introduciendo ? en el inductor ?, se obtiene ayuda de todas las acciones disponibles con el
inductor ?
ENViO DECORRESPONDENCIA
Para enviar correspondencia la orden mail se utiliza como se muestra en seguida:
$ mail
jim
jim es el id de presentación del destinatario del correo. La mayoría de las órdenes del sistema
UNlX utilizan al id de presentación para referirse a los usuarios, en vez del nombre real del
89
Capítulo 3
usuario.
AI igual que la mayoría de las órdenesUNIX, mall permite más de un argumento:
luis jim
$ mail
4
Para enviar elmismo mensaje tanto a jim como al usuario mismo. Si se introduce esta
orden, el programa mall comenzaráa ejecutarse y luego se detendrti, esperando que se
escriba el mensaje decorreo. S e puedeusar la tecla BACKSPACE para corregir errores,
siempre y cuando no se haya presionado la tecla RETURN (lo cual significa que el sistema ha
aceptado la entrada). Para finalizar el texto se presiona CTRL-D.
Si no hubo errores, el programa mail envía silenciosamente el mensaje y luego regresa al
shell aesperar una nuevaorden. L a ausenciade noticiassignifica generalmente buenas
noticias y se puede suponer generalmente que si una orden actúa silenciosamente y regresa
al shell sin mostrar un mensaje de error es que probablement se ha completado con éxito.
e
El shell examina el buzón para determinar si ha llegado nueva correspondencia. Como el
sistema UNlX es un sistema multitarea, varias cosas pueden estar ocurriendo en el sistema al
mismo tiempo.
QUIÉN ESTÁ PRESENTE
El sistema UNlX proporciona herramientas que permiten ver quién más está presente en las
terminales y proporciona cierta idea de lo que están haciendo.
Los usuariosdeuna máquina pueden comunicarse fácilmente unoscon otros y pueden
compartir ficheros si es necesario. El sistema UNlX proporciona excelentes herramientas para
los idsde
presentación de usuarios, los ficheros y
identificar elstatus
deseguridadde
programas administrativos del sistema, y los ficheros individuales.
Es posible ver quién está actualmente presente en la máquina utilizando la orden who:
$ who
jim
luis
console
ttyos
Apr
Apr
7
7
14:O5 .
16:41
$
La salida anterior informa que hay dos usuarios actualmente presentes en el sistema, jim y
el usuario mismo (luis). Además que informa a jim está en la consola y el usuario en el terminal
remoto ttyos. El resto de la línea informa la fecha y hora en que cada usuario se presentó al
sistema.
En
90
un sistema UNlX grande puedehabermás
Implementación
de
de un centenar de usuarios presentes
un shell remoto
al
mismo tiempo; en máquinas más pequeñas puede haber unosólo.
CAMBIO DE CONTRASEÑA
El par id de presentación y contraseña forman
la clave de seguridad delsistema UNIX.
Si eladministrador del sistema estableció el,iddepresentaciónnuevo
sin contraseña,
probablemente no se verá el mensaje Password:cuando se presente; se obtendrá acceso al
sistemadirectamentedesde
el inductor login:. En éste caso se debería añadir una
contraseña tan pronto como sea posible.
El sistema de contraseñas de usuario está diseñado de modo que nadie puede saber la
contraseña de otro usuario, a menos que se le diga. Lo Único que el administrador del sistema
puede hacer para restaurar una contraseña perdidaes suprimir la contraseña actual y asignar
una nueva.
Generalmente el sistema exige que las, contraseñas tengan al menos seis caracteres y
contengan al menos un dígito u otro carácter no alfabético.
La orden passwd permite el cambio de contraseña.
Si durantealgúnpasoen
la introducción deunacontraseña
se produce un error, el
programa passwd terminará y regresará al shell. En todo caso da dos oportunidades. Si se
presiona DEL en un pasointermedio, permanecerá vigente la contraseña actual.
I
DESPEDIDA
Cuando se acabe de utilizar el sistema, se le deberá informar que se ha terminado. A este
despedida [logging out]. Cuando alguien se despidese libera la
procesoseledenomina
terminal. Despedirse de la terminal es una buena práctica.
LOS dos factores más importantes para mantener la seguridad de un sistema UNlX son
mantener las contraseñas seguras y'despedirsedel sistema siempre que se encuentre alguien
ante el terminal.
El procedimiento de despedida será diferente dependiendo de si la sesión 'se inició en el
sistema de ventanas X o no. En el primer caso se deberá seleccionar el menú Workspace, y
si es necesario se confirma la salida (exit) con una ventana deaparición [pop-up].
No hay que confundir la introducción de la orden exit dentro de una ventana xterm, (que
Universidad
Autónoma
91
Capítulo 3
finaliza unaventana,nouna
sesión); conla
introducción delaorden
exit en el menú
Workspace.
El sistema UNlX proporciona dos modos de despedirse del shell. Primero introduciendo la
orden exit, la cual detiene la ejecución del shell,se reinicializa y devuelveal inductor de
presentación inicial. Se puede apagar el terminal o presentarse de nuevo. Un método alterno
consiste en presionar CTRL-D. Ésta es la marca de fin de fichero y el shell la interpreta como
una señal de despedida.
Algunos sistemas UNlX están configurados de modoque al apagar el terminal o la consola
también se despide el usuario del sistema. Generalmente las terminales conectadasa la
máquina mediantelíneas telefónicas y módems actúan deésta manera.
MISCELANEA
I
En un terminal las órdenes u otras líneas de texto se finalizan presionando RETURN. En la
jerga del sistemaUNIX, el símbolo utilizado para finalizar una línea de texto es el carácter
nueva-línea. En lo sucesivo el término nueva-línea indicará la tecla fin-de-linea.
Generalmente en un terminal la tecla RETURN actúa como nueva-línea, pero de hecho el
carácter ASCIIpara nueva-líneaes el .carácter cambio de línea [linefeed]. Como ejercicio
presionar CTRL-J (cambio-de-linea) al acabar unalínea de texto.
Control de la salida al terminal. A veces sucederá que la salida de una orden contiene
más líneas de las que la pantalla (o la ventana xterm) pueden visualizar. En éste caso la
salida se deslizará. Hay dos herramientas que ayudan a controlar la salida. Primero usando la
orden more y ensegundo lugar basta presionar CTRL-S paraque la salida se detenga
inmediatamente y CTRL-Q para que se reanude; hay que asegurarse deutilizar CTRL-1 la Mima
vez o el terminal parecerá estar congelado.
ARCHIVOS Y ÓRDENES DE UNlX ÚTILES PARA
TRABAJAR CON PROTOCOLOS
Aquí se presentan los principales archivos y órdenes en las que se basa la realización de
UNlX y la visión externa que los usuarios del sistema puedan tener de la implantación de
protocolos. Por tanto, se trata de archivos de configuración de la red, de órdenes principales
de consulta o administración, de procesos demonios necesarios, de órdenes que permiten
92
-
Implementación deun shell remotó”
”
Ylll-.
Y
f l
que unusuariollameaunservicio,
y de objetos(estructuras y funciones) que facilitanla
esta visión
consultade los diferentesarchivos de configuración. Una últimacomponentede
concierne a la comunicación entre usuarios de diferentes lugares UNIX.
LOS ARCHIVOS DE CONFIGURACIóN
N archivo /etc/host.Contiene la información relativa a las diferentes máquinas de la red
locala la que pertenece el sistema. Se ha vistoque las máquinas poseenuna dirección
una maquina
Internet de 32 bits. Es interesantepoderledarunsentidoaladirecciónde
cuando se la designa.
El archivo /etc/hosts de un sistema contiene la tabla de correspondencia entre la dirección
de una redestenombresimbólicocontiene
una
Internet y unnombresimbólico.Dentro
componente unica. A cada máquina de la red le corresponde una línea del archivo etdhosts
de la forma siguiente:
132.227.60.2
knuth
sun
# sun litp
El formatoanterior corresponde respectivamente a la dirección Internet (132.267.60.2);al
nombre oficial (knuth); a una lista de alias (sun) y a un comentario (# sun litp).
Cuandose traspasa elcuadrode
una red local, los nombressimbólicos se organizan
jerárquicamente como una serie de cadenas que designan conjuntos (dominios) cada vez más
generales como se verá más adelante.
E/ archivo /etc/networks. Constituye la basede datos en las redes conocidas que
constituyen la red lógica Internet. Existe una serie de campos que tiene cada uno: el nombre
oficial de la red, su dirección Internet y un comentario, por ejemplo:
main-net-.
litp-ether 132.227
dolores
cicrp-net
1.32.227.70
192.33.154
E/ archivo /etc/sefvices.Contiene la lista de servicios Internet conocidos. Un servicio así
se caracteriza por su nombre, un número de puerto, un protocolo y una lista de alias. De esta
manera se encuentran las siguientes líneas en este archivo:
ftp
2l/tcp
tftp
69/udp
514/tcp
517/udp
shell
talk
cmd
# no passwords u s e r s
Este ejemplodescribeserviciosestándar
Internet (ftp y tftp) y orientadosa UNlX (shell y
talk) que se basan en los protocolos TCP y UDP.
93
Capítulo 3
E/ archivo /efc/profoco/s. Proporciona la listade los protocolos conocidos que se utilizan
en la red lógicaInternet.Paracadaprotocolodescribesunombreoficial,
un númerode
protocolo, una lista de alias y un comentario. Por ejemplo:
dumny for IF
# control message protocol
ii tcp
# user datagrarr!protocol
#
I
E
1.7
ÓRDENES DEADMINISTRACIóN
Un cierto
número
de órdenes
permiten
a un usuario
cualquiera
la
obtención
de
informaciones generales sobre el estado de la red.
Las órdenes hostid y hostname. Permitenrespectivamenteobtenerlasdirecciones
Internet y el nombre oficial del sistema local. De esta manera se obtiene:
< Brumaire > cat /etc/hosts I grep brumaire
132.227.60.51
brumaire
loghost
.: Brumaire;, hostname
brumaire
< Brurnaire> hostid
Ox84e33c33
# p c r t ufr
p7
La orden rupfime.Permite obtener el estado de las diferentes máquinas de la red local.
Sólo puede usarse si está activo el demonio rwhod.
< Brumaire
germinal
messidor
pluviose
> ruptime - a
up
2:02,
down 5 6 + 2 1 : 4 4
up
20:46,
users,
load
56. 7
0. 5.5542, ,
17 users,
load
00. 0
. L00, ,
25
La orden ping. Permite probar si una maquina dada está activa
las diferentes opciones, se cita -s.
< ljrumaire > ping - S ventose
Ping ventose: 1 3 2 . 2 2 7 . 6 0 . 1 4 responding
< Erumaire > ping - S nivose
Ping nivose: Host not responding
0.00
en este momento. Entre
La orden arp. Permite visualizar el contenido de la tabla de protocolos
ARP, quedala
e Internetdelasmáquinasconsultadas
correspondenciaentrelasdireccionesEthernet
previamente. A continuación se muestra un ejemplo.
El sistema operativo UNIX
arp -a
ethernet ARP table:
litp (132.227.60.1) at 2:7:1:0:73:73 trailers
germinal (132.227.60.59) at 0:0:84:e3:3~:3b'trailers
< Brumaire >
Laorden netsfat. Como su nombre lo indica, permiteobtenerinformación
sobre la
actividad de la red del sistema. Más precisamente, suministra información sobre los diferentes
sockets del sistema (puntos de comunicación que se estudiarán más adelante). Sin entrar en
detalles, simplemente cadasocket utilizado para comunicarse enla red está unido a un puerto
de uno de los protocolos TCP o UDP. Mediante la opción -I, se obtienen estadísticas sobre los
interfaces del sistema local (paquetes emitidos y recibidos, errores y conexiones, red
conectada y nombre del sistema). Laopción -r aportainformación sobre las tablas de
encaminamiento. La opción -a suministra información sobre los diferentes puertos TCP y UDP
(además de las informaciones sobre sockets utilizados para la comunicación local al sistema).
< Brumaire > netstat -i
Name
Mtu
Network
Address
Ipkts
Ierrs
Opkts
Oerrs
Collis
1500
en0
dolores
germinal
1539
lo0 1500
loopback
localhost
5146
O
O
18437
51463
12
9
O
O
I
LOS PROCESOS DEMONIOS
La utilización de servicios estándares (por ejemplo, TELNET o FTP) por un usuario, se
realizan por mediación de órdenes(telnet o ftp), que necesitan para funcionar la existencia de
procesos particulares (demonios) sobre la mhquina distante. A continuaci6n se presentan los
principales procesos demoniossusceptibles de encontrarse enun sistema UNIX.
EL SUPERDEMONIO inetd
En las primeras implantaciones de los servicios de la red, se lanzaban los demonios de una
vez para siempre. Por tanto, esta estrategia conllevaba la creación de un número importante
de procesos y su mantenimiento en estado durmiente (en espera de ser solicitados). En las
crear
versionesmas
recientes, un demonio principal (/etc/inetd) es elencargadode
automáticamente el servidor correspondiente a un servicio solicitado, este servidor particular
termina una vez que el servicio se ha proporcionado. Por tanto, el proceso está a la escucha
en los diferentes puertos correspondientes alos servicios disponibles.
I
El archivo /etc/inetd.conf es utilizado por el proceso lnetd cuando se lanza para conocer
el conjunto de puertos sobre los que se tiene que poner a la escucha. Este archivo contiene
una línea por servicio, cada línea suministra sucesivamente la siguiente información: el nombre
Universidad Autónoma Metropolitana. Unidad'lztapalapa
95
del servicio; el tipo de socket; el protocolo subyacente; una opción wait/no wait que se utiliza
para las comunicacionesenmodoconectado
(dgram), las otras se utilizan siempre con la
opción no wait (la opción wait evita, en el modo no conectado, lacreación de varios servidores
a la escucha sobre un mismo puertoy los conflictos que se podrían desencadenar);un nombre
de usuario que será propietario del proceso demonio asociado al servicio cuando se cree; la
referencia absoluta del archivo que contiene el programa de servicio (la mención "internal "
indica que el servicio es interno al proceso inetd); una lista de parámetros para el programa
(correspondientes alos parámetros argv[O], argv[l], ...).
A continuación se muestran algunosejemplos de líneas contenidas en este archivo:
ftp
stream
tcp
nowait
root
/usr/lpp/tcpip/etc/ftpd
ftpd
/etc/rshd
nowait
root
rshd
stream
tcp
shell
echo
dgram
udp
wait
root
inter'nal
4
Una
propiedad
que
es interesante del proceso inetd es que
es
reconfigurable
dinámicamente. Cuando recibe la señal número uno (SIGHUP), relee el archivo /etc/inetd.conf
antes de ponerse ala escucha.
LOS DEMONIOS DE SERVICIOS ESTANDARES
N demonio whod. El programa /etc/rwhod dialoga con sus homólogos sobre los otros
sistemas, éstos diálogos
permiten
puesta
la
al día de archivos en
el
directorio
/usr/spools/rwho, utilizados por los comandos who y ruptime.
Estos demonios tienen la responsabilidad de cargar la red y en muchas máquinas no se
ejecutan, por lo tanto los comandos rwho y ruptlme no se utilizan en éstas máquinas y las
informaciones que les concierne no se transmiten a las otras.
Los demonios telnetdy rlogind. Correspon'den a archivos del directorio /etc y permiten
el protocolo DARPA de
el "login"desde otro sistema. Eldemonio telnetd seapoyasobre
terminal virtual mientras que rlogin proporciona un servicio específico UNIX.
Los demonios ftpd y tffpd. Son respectivamente,los servidores de los protocolos FTP y
TFTP de transferencia de archivos de la familia Internet.
El demonio ftpd corresponde a un proceso a la escucha sobre el puertoTCP de número 21,
que reconoce un cierto número de órdenes (que leson dirigidas por clientes) tales como:
HELP
USER
PASS
XPWD
QUIT
96
ayuda
en
línea
especificación un
de
nombre
de
usuario
I
especificación de
una
palabra
de
paso
impresión
del
directorio de trabajo
sesión
de
final
Implementación
de
,
un shell remoto
1
N demonio rshd. Es el demonio UNlX parala ejecución decomandosremotas (por
mediación del comando rsh o de la función rcmd ) o la copia de .archivos mediante la orden
rcp.
I
LAS ÓRDENES DE SERVICIOS ESTANDARES
La orden felnef. Utilización general del comando telnet:
t e l n e [t a n f i t r i ó n[ p u e r t o ] ]
Este comando permite establecer una conexión con un puerto TCP dado de una máquina
de nombre dado. Si no se
especifica ningún número de puerto (es el caso mas común), se
establece una conexión con el demonio telnetd sobre el puerto remoto TCP, de número 23.
Entonces es posible crear una sesión de trabajo (el conjunto del diálogo se apoya sobre el
protocolo de terminal virtual TELNET).
En el caso en que nose suministre ningún parámetro, la orden pasa al modo "órdenes"
La orden ffp. Este comando constituye el interfaz que se apoya sobre el protocolo FTP
de la DARPA. Permite realizar las transferencias de archivos entre el sitio local (se lanza el
sistema o la orden) y un lugar remoto.
Para realizar una transferencia, es necesario crear una conexión con el servidor ftp de la
máquina distante. Entonces es posible realizar las transferencias en los dos sentidos. La
f o r m ag e n e r a ld e l
comando ftp e s :
ftp
[-VI
[-i] [-n]
[anfitrión]
Si no se le da un nombre de máquina anfitrióh o si el nombre dado no corresponde a una
de las máquinas especificadas en el archivo /etc/host, el proceso ftp pasa al modo órdenes
(prompt ftp >). En caso contrario, si es posible se establece una conexión con el demonio ftp
de la máquina remota. Se insiste en el hecho de que se tiene que identificar con la máquina
remota pero ésta identificación no significa que el usuario cree una sesión de trabajo sobre la
máquina remota; no hay creación de un proceso shell en esta máquina. El usuario dispone de
órdenes específicas que de formaeventual pueden llevar el mismo nombre que ordenesUNIX.
No hay que perder de vista que el protocolo FTP tiende a permitir la transferencia de archivos
entre sistemas diferentes.
AI principio el usuario tiene que dar unaidentificación y la palabra clave correspondiente (es
necesario que haya una palabra de paso) al sistemaremoto. Entonces en éste sistema el
usuario, a través de un proceso ftp, posee los derechos de usuario mediante el cual se ha
identificado.
97
Capítulo 3
I
Sin embargo cuando se utiliza la opción -n, se lanza en el transcurso de la conexióninicial
un proceso inicial de "auto-login". E n el transcurso de esta fase se consulta el archivo .netrc
del directorio privado del usuario (en la máquina local). Este archivo contiene información de la
forma siguiente separadas por espacios, tabuladores ó caracteres fin de línea:
máquina anfifrión
identificación
de
una máquina remota. Si la máquina dada
como parámetro de ftp aparece en una especificación de
éste tipo en el archivo .netrc, se explota la información
que siguen en el archivo (hasta el final de archivo o la
especificación del mismo tipo);
login nombre
identificación
de
usuario que se utiliza por defecto;
password cadena
especificación de una palabra de paso. El archivo solo
puede ser legible para el usuario.
Las órdenesgenerales, permitenconsultar o modificar las características generaleq del
comportamiento del proceso y de las transferencias.
tipo de transferencia por defecto para los archivos ASCII;
para materializar cada fin de transferencia mediante AG;
para la transferencia de archivos binarios;
by e
para cerrar
la
conexión y terminar
el
proceso ftp (<eof>tiene
el
mismo efecto).
close
para cerrar la conexión actual;
disconnect
proceso
(el
ftp no ha terminado);
glob
para volver
activo
el mecanismo de expansión
de
nombres para los comandos: mdelete, mget y mput;
help
para obtener una
ayuda
línea
en
(mismo efecto que ?);
open anfifrión[puerto]
para establecer una conexión con la máquina anfitrión
(eventualmente en el puerto especificado);
prompt
Interruptor correspondiente a la peticiónho petición de
confirmación en el caso de órdenes multiples;
user nombre [contraseiia] paraidentificar en el sistema distante bajo el nombre
dado mediante la palabra clave especificada;
status
para fijar las características del proceso ftp;
verbose
pasar
para
al modo "verbal".
ascii
bell
binary
LAS ORDENES DE SERVICIOS UNlX
La configuración de /a fed. E n ausencia de una distribución de los archivos de los
sistemas (NFS y las "pdginas arnarillas"ofrecen una solución en este sentido), se plantea el
problema de identificación de los usuarios entre las diferenteslmáquinas de la red. El problema
puederesolverse,ya sea globalmente a nivel del o de los administradoresde los sistemas
(archivos /etc/hosts.equiv de los diferentes sistemas), ya sea al nivel de cada usuario (archivo
.rhosts de los directorios privados de los usuarios).
E/ archivo /efc/hosfs.equiv. Sobre un sistema dado contiene una listade
98
remoto
un
de
máquinas
El sistema operatiyo UNlX
I
equivalentes a la máquinalocal.
Entonces, una identificación (es decir, un nombre de login y no un entero queidentifica a un
usuario) sobre una de estas máquinases equivalente a la propia identificación (si existe) sobre
la máquina local: esto significa que un usuario denombredadoen la máquinaremota se
identificará, por defecto, por el mismo nombre quesobre la máquina local.
El archivo .rhosfs. En el caso en que no se integren máquinas distantes en el archivo
hosts.equiv (pero que la máquina local las conoce a través del archivo /etc/hosts), es posible
que un usuario autorice a usuarios de éstas máquinas a que se identifiquen implícitamente
bajo su nombre. Para ello, tiene que crear su directorio privado un archivo .rhosts formado por
líneas de la forma :
nombre-de-máquina
identi~cación_de_usuano
La orden m h o . Suministra la lista de usuarios conectados en las máquinas de la red
donde el demonio rwhod está activo (a condición de que el propio demonio local esté también
activo).
Sin la opción -a, se ignoran los usuarios inactivos desde al menos una hora. Uso:
rwho [-a]
La copia de archivos:rcp. Se puede llamar a éste comando bajo una de las siguientes
formas:
rcp referencia-fuentereferencia-objeto
ó
rcp referencia-fuenfe ... referencia-~~~~~~~~~o~jeto
Las referencias utilizadas en ésta orden son extensionesde referencias UNIX. Están
constituidas por un nombre de máquinay una referencia UNlX clásica separada por elcarácter
11.!1
nombre-de-máquina:referencia-de-archivo
Unallamada de laprimeraformacopia
un archivo ordinario delamáquinafuentea
la
máquina objeto.
Unallamadadelasegundaformacopia
los diferentes archivos fuenteenel
directorio
objeto. Los archivos creados tienen como nombre en el directorio objeto la última componente
de su nombreoriginal.
La segunda forma puede también utilizar una opción -r que permite que se vuelva a copiar
deformacompletala
estructura en árbol (en tal caso referencia-fuenfe puede ser una
referencia de directorio).
t
La ejecución de comandos disfanfes: rsh. Este comando permite la ejecución de un
comando shell en la máquina designada. Si no se da ningún comando como parámetro,
se
lanza un shell remoto.
99
Capítulo 3
0
rsh anfitrión [-i identificación] [-n] orden
Se puede especificar la identificación de un usuario distante con la opción -1.
La utilización de la opción -n implica el cierre de la entrada estándardel comando distante.
N "login"remoto:rlogin.
Estecomando permite conectarsea distancia sobrela
máquina deseada (bajo una identificación dada). Se trasmite un cierto número
de
informaciones como el tipo de terminal (variable de entorno TERM), y se asegura el control de
flujo. El funcionamiento de la orden se basa sobre el mecanismo de seudoterminal.
rlogin anfitrión [-I identificación]
-
c
El carácter permite realizar unescape. La secuencia -. corta todas las conexiones y
provoca un retorno definitivo sobrela máquina local. Además, enunentornoenque
se
dispone del control de tareas (esdecir,quepermite
la suspenciónde un proceso), si el
carácter A Z es el carácter de suspensión, la secuencia A Z permite detener el proceso de
rlogin y volver al shell local sin cortar la sesión remota.
-
LAS ESTRUCTURAS DE BASE
A continuación se describirán las estructuras de base y las funciones que se utilizan cuando
se desarrollan aplicaciones distribuidas.
Los archivos de base para estas manipulaciones
son <netdb.h> y <netinet/in.h>, cuya
utilización supone la inclusión previa del archivo <sys/types.h>
#include <sys/types.h>
#include <netdb.h>
#include <netinet/in.h>
El manejo de las direcciones
entero largo (largo en el serItit
lenguaje "C"), sin embargo por razoneshistóricas le corresponde lasiguiente estructura:
La dirección de una
struct
!I
mdiquina. Consisteenun
in addr {
u-long S -addr;
I
1
Las direcciones Internet tendrán como indicador AF-INET (AF significa address format).
IO0
.
-.._-
Implementación
un de
-
shell remoto
I
...
Laestructurahostent.
Esta estructura
predefinida en netdb.h correspondeauna
cadena en el archivo /etc/hosts.
s t r u cht o s t e n t
{
char
* h name;
/ * nombre o f i c i a l de l a m á q u i n a * /
char
aliases; / * l i s t a de a l i a s * /
int
h addrtype;
/ * t i pdodei r e c c i ó n :
AF INET * /
hi n- lte n g t h ;
/ * l o n g i t u d de l a direcc-ión * /
char
*Th a d d r l i s t - ;
/ * l i s t a de d i r e c c i o n e s * /
# # d e f i n e h -a d d r h-a d d r-l i s t
/ l a primera direcci6n de l a l i s t a
**E
[o]
1;
I
La función b z e r o permite inicializar a O una zona de memoria de
dados.
h /
dirección y de tamaño
b z e r o (adr, l g )
c h a r * a d r ; / * d i r e c c i ó n de l a z o n a a i n i c i a l i z a r * /
int lg;
/ * número de b y t e s a i n i c i a l i z a r a O * /
N problema de /a representación de enteros. Si las máquinas intercambian enteros
(largos como las direcciones o cortos como
números
de
puertos), es prudente que
previamenteéstosenterosesténen
su forma"de red". Lasfuncionesque se muestrana
continuación, permiten el paso de la representación local a la representación red de un entero
largo o corto, o el paso inverso:
ntohl(x)
Network to host long
ntohs(x)
Networktohost
htonl(x)
Host to network long
htons(x)
Host to network short
short
Paso de la representación red de un entero largo x a
su representación local.
Paso de la representación red de un entero corto x su
representación local.
Paso de la representación local de un entero largo x a
su representación red.
Paso de la representación local de un entero corto x a
su representación red.
Las direcciones de redes.
La estructura n e t e n t y las funciones g e t n e t b y n a m e y
g e t n e t b y a d r r permiten obtenerlas informaciones contenidas enel archivo /etc/networks.
s t r u c tn e t e n t
{
char
name;
*n /*
char
**n aliases; /*
int
n-a d d r t y p e ; / *
u n s i g n e ldo n g
n-n e t ;
/*
nombre o f i c i a l de l a r e d * /
l i s t a de l o s a l i a s * /
t i p o de d i r e c c i ó n de l a red * /
d i r e c c i ó n de l a red * /
1;
101
'
Capitulo 3
I
El manejo de puertosy servicios
Seha visto que un servicio sobre unamáquina dadase caracteriza por un número de
puerto del protocolo correspondiente. Estos números de puerto juegan el papel de dirección
para losservicios. Por otro lado, el archivo /etc/servlces contiene la lista de los servicios
disponibles. La consulta de este archivo utiliza la estructura se vent.
f
struct servent
{
char
* S -name;
* * S aliases;
char
int
S -port;
char
proto;
*p
-
/ * nombre oficial
del
servicio
/ * lista d e alias * /
*/
/ * número
de
puerto
*/
/ * protocolo
utilizado
*/
1;
La estructura sockaddr-in. Por mediación de esta estructura será posible designar un
servicio sobre una máquina particular. La estructura se define por:
structsockaddrin{
short
sin family;
short
u
sin-port;
structinaddrsinaddr;
char
sin-zero[8];
/ * la familia d e dirección: AF- ..I N E T * /
/ * el número de puerto * /
/ * la direcciónInternet
/ * un
campo
*/
de 8 ceros * /
1;
Los protocolos
La consulta del archivo /etc/protocols utiliza la estructura:
structprotoent
{
char
*p
name;
char **p-aliases;
int
proto;
p
-
/ * nombreoficialdelprotocolo
/ * lista de alias * /
/ * número de protocolo * /
*/
1;
LA COMUNICACIóN ENTRE USUARIOS
En UNIX se constituye unacomunidaddonde
los usuarios tienen la posibilidad de
intercambiar archivos y dialogar mediante sistemas de mensajería o de foro.
I
Laconexióndemáquinas
UNlX utilizando los protocolos INTERNET convierten a ésta
comunicación en particularmente fácil.
102
Implementación
de
un shell remoto
Los mecanismos de direccionamiento
Permiten asociar una cadena de caracteres para la designación de una máquina
tanto, poder determinarun camino paraalcanzarla.
y, por
N demonio sendmail. Este es el encargado de determinar si una máquina a la que se
el
quiere mandar un mensaje, se puede alcanzar directa o indirectamente, enesecaso
mensaje debe de ser enrutado a una máquina que actúa como puente. El proceso sendmail
utiliza el archivo sendmail.cf para realizar éste direccionamiento. Existen dos sistemas
principales de direccionamiento que sedescribirán a continuación:
1 . Las direcciones uucp. Imponen la escritura deuna
máquina. Una dirección así tiene la forma:
maquinal!maquina2!
ruta quepermitealcanzar
la
. _ . .maquinaN!identifidacion
Permitedesignar al usuario de identificación dada sobrela
máquinadenombre
maquinaN. Los nombres anteriores designan las diferentes máquinaspor las quese
tiene que transmitir el mensaje enviado.
2. El dominio de los nombres Internet. El principio consiste en construir una estructura en
árbol de nombres, donde un nodo de un nivel dado es un subdominio de un nodo de
nivel superior. Las hojas del árbol son las máquinas del dominio general de Internet. Así,
partiendo de la raíz, será posible alcanzar una máquina particular atravesando un cierto
númerode dominios. Por ejemplo,Franciaes
un subdominio particular del dominio
general (como cada país del mundo).
De forma general, se puede se puede designar una máquina mediante
la cadena:
maquina.dominiol.dominio2
....
dominioN
La cadena anterior corresponde a un camino de la máquina hacia la raíz. Esta máquina
constituye una dirección completa que puede truncarse si se hace referencia a una máquina
de un dominio idéntico al de la máquina de donde se ha hecho esta referencia. Así ,el dominio
fr se puede omitir para direccionar otra máquina situada en Francia: Y , dentro del dominio ibp,
se puede omitir el sufijo .ibp.
Entonces, la dirección electrónica completa deun usuario es:
identificación@dirección-maquina
donde la identificación es la del usuario sobre la máquina designada.
Se definen unaserie de dominios principales en seguida.
Universidad AutónomaMctropolitana. Unidad lztapalapa
103
Capítulo 3
I
NOMBRE DE DOMINIO
INTERPRETACI~N .
Empresas comerciales (SUN,CDC, APPLE, ...)
Educación (NIT, BERKELEY, ...)
Instituciones militares (NAVY, ...)
Instituciones gubernamentales (NASA,...)
Dominio genérico
Gran Bretaña (AC [académico], ...)
Francia (INRA, IBP, ...)
COM
EDU
MIL
I
GOV
UUCP
UK
FR
Por ejemplo, el laboratorio Jet Propulsión Laboratory de la NASA tiene como dirección este
formato:
I
jpl.nasa.gov
y un usuario particular sobre una máquina dada de este laboratorio
identificació[email protected]
NOTA: En la escritura de direcciones las mayúsculas y las minúsculas sonequivalentes.
El Correo
SYSTEM V globalmente equivalente a la orden mail BSD.
Ofrece un interfaz más agradable que la orden mail básica para enviar correo o consultar el
buzón.
Sólo se describe la orden
mailx
Buzones. En una máquina donde tiene una cuenta, un usuario dispone de un buzón de
referencia, cuya referencia se muestra en seguida.
REFERENCIA
SISTEMA
/usr/spool/maiI/idenfificación
/var/maiI/identificación
BSD
SYSTEM V.4
El correodel usuario, salvo petición contraria, se escribe y se lee en el archivo de
referencia correspondiente.
1
Además el archivo de referencia mbox, en el directorio privado de un usuario, se usa para
grabar los mensajes leídos en el buzón principal. Por fin, el archivo $home/maix.rc contiene
órdenes ejecutadas al llamar a la orden (por ejemplo, la definición de alias).
El envío de correo. Sea la orden:
impiementación
de
104
-... .
.
. ".".-
un shell remoto
maixl [
-S
tema ] usuario
....
Lee en la entrada estándar el mensaje a enviara los usuarios que pertenecen ala lista
dada como parámetro. L a opción - S permite poner un titulo a la carta : se pide un titulo si no es
utilizada y la orden se lanza en modo interactivo .
Los usuarios se identifican mediante las convenciones descritas anteriormente (a condición
de que el demonio sendmall exista y esté bien configurado).
La lectura de correo. S e realiza con la orden malxl sin parámetros. E n lailustración
siguiente se presentan las principales opciones.
I
EFECTO
'
OPCIóN
Testde existencia de correo
Lectura de correo en el archivo (mbox si no hay referencia)
No hay inicialización en el archivo mailx.rc
No hay impresión de resumen.
-e
-f referencia
-n
-N
3
Cuando se hace la consulta de un buzón, se identifica un mensaje por un número ($ es el
(/cadena). E n lailustraciónsiguiente
se describen las
último mensaje), o porelcontexto
principales órdenes sin parámetros: se aplican al mensaje actual.
EFECTO
lista de órdenes con resumen
lista de órdenes sin resumen
salida
salida sin modificación
alias para un conjunto de nombres
supresión del mensaje
edición del mensaje
mensaje siguiente
envío de respuesta
grabación en archivo
recupera el mensaje
ORDEN
NOTA
help
list
quit
exit
alias alias nombre... .
delete
mensaje suprimido
final
al
del proceso
edit
Utilización
del editor dado por $EDITOR
next
Replay
referencia mbox defecto
por
save referencia
undelete
Seguimientodelcorreo.
El proceso sendmail interpreta
el
contenido
del archivo
.forward del directorio privado de un usuario como una lista de direcciones (dadas en uno de
los formatos aceptados) donde se tiene que hacer el seguimiento del correo del usuario. De
esta manera un usuario que tenga una cuenta en varias máquinas puede centralizar su correo.
La orden mail de SYSTEM V.4 admite una opción -F que, seguidadeuna
listade
que llega al usuario hacia las diferentes
direcciones,provoca la transferenciadelcorreo
direcciones. Para anular la orden basta con dar una dirección vacía.
105
Avisos de llegada de corfeo. Habitualmente, al usuario se le avisa dela
correo cuando comienza una sesión detrabajo (en el login).
I
LENGUAJE
ORDEN
Bourne Shell
MAILCHECK = nb
C- Shell
llegada de
EFECTO
Comprueba cada nb segundos la
llegada de correo en el buzón.
set mail = (nb fic1 ... ficn )
Comprueba
cada
uno de los nb
segundos, en el buzón indicado.
Por fin, en un entorno BSD, la orden siguiente permite el aviso de la llegada de correo:
biff [yn]
N teléfono. Las órdenes:
write usuario [puedo] talk usuario [terminal]
permiten que un usuario pida un diálogo con otro. Es preferible la segunda orden que permite
la comunicación con un usuario sobre otra máquina y rige el diálogo (mediante una separación
de la pantalla en dos regiones: emisión/recepción).
LOS PROCESOS EN EL SISTEMA UNIX
A continuación se revisarán los aspectos, más importantes relacionados con los procesos,
en el sistema operativo UNIX. El concepto de proceso es un tema capital como parte intrinseca
del sistema operativo, pero también como tema dentro de las redes de computadoras y de los
sistemas distribuidos.
CONTROL DE PROCESOS
Unprocesoes
un programa en ejecución y se identifica por un número entero, el
identificadordeproceso.Un
nuevo proceso se creacon
la llamadaalsistema
fork
(bifurcación) y consiste en una copia del espacio de direcciones del proceso original (el mismo
programa y las mismas variables con idénticos valores). Ambos procesos (el padre y el hijo)
106
Implementación
shell
de un
renhoto
continúan en la instrucción después de la I!amada fork con una sola diferencia: el código de
retorno de la llamada es cero para el nuevo proceso (hijo), mientras que al padre se devuelve
el identificador de proceso (distinto de cero) del hijo.
Típicamente,unode
los dos procesos emplea la llamada execve despuésdeuna
bifurcación para reemplazarsu espacio de memoria virtual con un nuevo programa. La llamada
al sistema execve carga en memoria un archivo binario (destruyendo el contenido en memoria
del programa que contienela llamada execve) y comienza su ejecución.
Un proceso puede terminar con la llamada al sistema exit (salir) y su proceso padre puede
esperar ese evento usandola llamada wait (esperar). Si falla el proceso hijo, el sistema simula
la llamada de la salida. La llamada al sistema wait proporciona el identificador de proceso hijo
que termina, para que el padre pueda distinguir cuál dd sus hijos es el que ha terminado. Una
recopilar
segundallamada al sistema, wait3, essemejante a wait peropermitealpadre
estadísticas de la ejecución del hijo. Entre el momento en que termina el hijo y el momento en
que el padre termina una de las llamadas de espera, el hijo es un zombie. Un proceso zombie
no puede haceralgo, pero existe para que su padre pueda recopilar su información de estado.
Si el proceso padre deun zombie termina antes que el hijo, el proceso init hereda al zombie (y
a su vez también espera). En la Figura 1 se presenta una utilización tipica de estos recursos.
proceso
hijo
- ejecucibn del
programa
> Programa
execve
Figura 1. Un shell bifurca un subproceso para ejecutar un programa.
Laformadecomunicación
más sencillaentreprocesoses
a través de conductos, los
cualespuedencrearseantesde
lallamada fork y cuyosextremos los establecen fork y
execve. En esencia, un conducto es una cola de bytes entre dos procesos. El acceso a un
conducto se realiza por medio de un descriptor de archivo, como sucede con un archivo
ordinario. Un proceso escribe en el conducto y el otro lee de él. El tamaño del sistema de
conductos original fue determinadopor el sistema. En 4.3BSD los conductos se implantan
sobreelsistemadeconexiones,el
cual tiene buffers detamaño variable. AI leer de un
conducto vacío o escribir en uno lleno, el proceso se bloquea hasta que cambie su estado; se
requieren arreglos especiales para establecer un conducto entre un padre y un hijo (para que
sólo uno lea y el otro escriba).
Todos los procesosde usuario desciendende un proceso original llamado init (con
identificador de proceso 1). Cada puerto de terminal disponible para uso interactivo tiene un
proceso getty que bifurcó init. El proceso getty asigna los valores iniciales de los parámetros
107
Capítulo 3
I
de la línea terminal y espera el nombre de conexión de un usuario, que pasa a través de una
llamada execve como argumento para un proceso login (conexión). Este proceso obtiene la
contraseña del usuario, la cifra y compara el resultado con una cadena cifrada que se lee del
archivo /etc/passwd. Si la comparación tieneéxito, se permite que el usuario se conecte al
sistema. El proceso login ejecuta un shell, o intérprete de comandos, después de asignar el
identificador de usuario numérico del proceso al cual se conecta el usuario. (El shell y el
identificador de usuario se encuentran, usando elnombre
del usuario, en /etc/passwd).
Normalmenteel usuario se comunica a través de este Shell durante el resto de la sesión; el
shell bifurca subprocesos para los mandatos que el usuario indique que deben ejecutarse.
El núcleo utiliza el identificador de usuario para determinar los permisos respecto a ciertas
llamadas del sistema, en especial aquéllas que comprenden el acceso a archivos. Existe
también un identificador de grupo,que se usa para otorgar privilegios similares a un conjunto
deusuarios. Un procesopuede estarsimultáneamente en varios grupos. El proceso loqin
coloca el shell en todos los grupos que los archivos /etc/passwd y /etc/group permitenal
usuario.
E n realidad haydos identificadores de usuariq que utilizael núcleo: el identificador de
usuario efectivo que es el que emplea para determinar los permisos de acceso a archivos. Si
el archivo de un programa que carga execve tiene activo el bit setuid (asignar identificador de
usuario) en su nodo, se asigna el identificador de usuario del dueño del archivo al identificador
de usuario efectivo, mientras que el identificador de usuario real permanece sin cambios.
Esto permite que varios procesos tengan privilegiosdistintos de los normales mientraslos
ejecutan usuarios normales. La idea de la asignación de identificador de usuario fue patentada
porDennis Ritchie y esuna delas característicasdistintivas de UNIX. Existe un bit setgid
similar para los grupos. Un proceso puede determinar sus identificadores real y efectivo con
las llamadas al sistema getuid y geteuid, respectivamente. Los otros grupos deunproceso
pueden encontrarse con la llamada getgroups.
I
Seiiales. Las señales son un recurso para manejar condiciones excepcionales de manera
semejante a las interrupciones del software. Existen varias señales diferentes, cada una de las
cualescorresponde
a una condición distinta. Una señalpuede
ser generadaporuna
interrupción desde el teclado, un error en un proceso (como una mala referencia a memoria) o
por varios eventos asincronos (como los cronómetros o señales de control de trabajos shell).
Además, la llamada al sistema klll (matar) puede generar casi cualquier señal.
La señal de interrupción, SIGINT, se usa para detener un mandato antes de que termine.
Generalmente se produce con el carácter AC o , en una configuración más tradicional, con el
carácter eliminar. S e define una tabla para los caracteres más importantes del teclado de cada
terminal y puede redefinirse fácilmente. La señal abandonar, SIGQUIT, casi siempre se genera
en ejecución y vacíasu contenido en
por el carácter A \ ; estaseñal detieneelprograma
memoria a un archivo llamado core núcleo en eldirectorioactual.
Este archivo puede ser
utilizado por los depuradores. La señal SlGlLL se produce por una instrucción ilegal, y SIGSEGV
por un intento de acceso a memoria fuera del espacio de memoria virtual del proceso.
Es posible efectuar arreglos para ignorarla mayoría de las señales
Ioa
Irnplementación de un
remoto
shell
(para que no tengan
El sistema oDerativo UNlX
efecto) o para invocar una rutinadel procesode usuario (un manejador de señales). El
manejador de señales puede hacer dos cosas sin que haya peligro, antes de volver de atrapar
una señal: emitir la llamada al sistema exit, o mbdificar una variable global. Existe una señal
(kill, SIGKILL) que no puede ser ignorada o atrapada por un manejador de señales; SlGKllL se
usa, por ejemplo, para matar un proceso sin control que ignora todas las demás señales, como
SlGlNT o SIGQUIT.
Es posible que se pierdan las señales: si se envía una señal del mismo tipo antes de que la
anterior sea aceptada por el proceso al cual está dirigida, se sobreescribirá la primera señal y
el proceso sólo verá la segunda. Además, no se presenta prioridad relativa entre las señales
no es posible
UNIX: si a un proceso se envían dosseñales diferentesalmismotiempo,
determinar cuál será la que reciba primero.
La intención original de las señales fue manejar condiciones excepcionales; sin embargo,
como ha sucedido con la mayoría de las característica,s de UNIX, se ha extendido el uso de las
señales.
Con frecuencia grupos deprocesoscooperanpara
lograr una
tarea común. Por ejemplo, pueden crear conductos y comunicarse por ellos. A este conjunto
de procesos se le denomina grupo de procesos o trabajo. Pueden enviarse señales a todos
los procesos de un grupo. Un proceso generalmente hereda del padre su grupo de procesos,
pero la llamada al sistema setpgrp le permite cambiar de grupo.
Grupos de procesos.
El shell C usa los grupos de procesos para controlTr el funcionamiento de varios trabajos.
Cualquier grupo puede, al mismotiempo,utilizar
un terminal para su E/S; este trabajode
primer plano recibe la atención del usuario en ese terminal, mientras los demás trabajos, no
unidos alterminal(trabajos de segundo plano), llevan acabo su funciónsininteraccióndel
usuario. El acceso a la terminal se controla por señales del grupo de procesos y cada trabajo
tiene un terminal controlador (heredado también de su padre). Si el grupo de procesos del
terminalcontroladorequivalealgrupo
deun proceso, entonces éste se ubica en elprimer
plano y puede efectuar E/S;si unproceso no equivalente (segundo plano) intenta hacer lo
mismo, se envíaunaseñal
SlGTTlN o SIGTTOU a un grupo de proceso, lo generalmente
ocasiona que el grupo se detenga hasta que el usuario lo pase a primer plano, donde recibiría
la señal SIGCONT que le indica quepuede llevar a cabo la E/S. De forma parecida,puede
enviarse una señal SIGSTOP para detener un grupo de procesos.
Manipulación de información. Existen llamadas al sistema para asignar y obtenerel
valor de un cronómetro de intervalos (getitimedsetitimer) y la hora (gettimeofday/settimeofday)
en microsegundos. Además, los procesos pueden solicitar su identificador de proceso (getpid),
su identificador de grupo (getgid), el nombre de la máquina donde se ejecutan (gethostname)
y varios más.
Rutinasdebiblioteca.
La interfaz de llamadas al sistema de UNIX estáapoyada y
extendida por un amplioconjunto de rutinas de biblioteca y archivos decabeceras; estos
últimos proporcionan la definición de complejasestructuras
de datos empleadasen
las
llamadas al sistema. Además, una extensa biblioteca de funciones ofrece apoyo adicional a
programas.
1o9
,
Por ejemplo, las llamadas al sistema E/Sde UNlX permiten leer y escribir bloques de bytes;
sin embargo, algunas aplicaciones querrAn leer y escribir sólo un byte a la vez. Aunque seria
posible leer y escribir un byte al mismo tiempo, esto requeriría una llamada al sistema por cada
byte, untiempo de procesamiento adicional considerable. E n vez de hacer esto, un conjunto
de rutinas de biblioteca (el paquete de E/S estándar al que se tiene acceso por medio del
archivo de encabezado <stdio.h>) ofrece otra interfaz, que lee y escribe miles de bytes a la vez
utilizando buffers locales, y efectúa las transferencias usando estos buffers (en memoriadel
usuario) cuando desea E S . El paquete de E/Sestándar también apoya la E/S con formato.
S e proporciona apoyo adicional de biblioteca para funciones matemáticas, acceso a redes,
conversión de datos, etc. Aunque las rutinas de bibliotecafinalmente efectúan llamadas al
sistema cuando
éstas
se requieren
(por
ejemplo, la rutina de biblioteca getchar [leer
caracteres] emitirá una llamada read si el buffer del archivo está vacío), generalmente no es
necesarioque el programador distingaentreelconjunto
básico de llamadas al sistema al
núcleo y las funciones adicionales que proporcionan las bibliotecas.
ADMINISTRACIóN DE PROCESOS
Uno de los principales problemas de diseño de un sistema operativo es la representación
de los procesos. Una diferencia sustancial entre UNlX y muchos otros sistemas es la facilidad
para crear y manipularvarios
procesos,queen
UNlX están representados por diversos
bloques de control. No existen bloques de control del sistema a los cuales pueda lograrse el
acceso en el espacio de direcciones virtuales de un proceso de usuario; los bloques de control
asociados a un proceso se almacenan en el núcleo, y la información que contienen es utilizada
por el núcleo para controlar los procesos y planificar la UCP.
a
un proceso es la estructura de proceso, que contiene todo lo que se necesita saber sobre el
proceso cuando éste sale por un intercambio, como son su identificador Único, información de
planificación (por ejemplo, la prioridad del proceso) y apuntadores a otros bloques de control.
Existe un arreglo de estructuras de proceso, cuya longitud es definida por el sistema durante el
enlace. El planificador mantiene unidas las estructuras de los procesos listos enuna lista
doblemente enlazada (la cola de procesos listos), y hay apuntadores de cada estructurade
proceso a su padre, su hijovivo más joven y otros parientes de interés, comouna listade
procesos que comparte el mismo código de programa (texto).
Bloques de control de procesos. La estructura de datos más básica que se asocia
El espacio de direcciones virtuales de un proceso de usuario está dividido en segmentos
de texto (código del programa), datos y pila. Los datos y los segmentos de pila siempre se
encuentran en el mismo espacio de direcciones, pero pueden crecer independientemente, por
lo general en direcciones opuestas:en la mayoría de los casos, la pila crece hacia abajo
mientras los datos crecen hacia arriba. E n ocasiones (como en un Intel 8086 con espacios de
datos e instrucciones separadas), el segmento de texto está enunespaciode
direcciones
distinto del de datos y la pila, y usualmente es de sólo lectura.
110
Implementación
remoto
shell
de un
Todo proceso con textos compartidos tiene un apuntador de su estructura de proceso a una
estructura de texto, la cual contiene el número de procesos que están utilizando el segmento
de texto, así como un apuntador a una lista de sus estructuras de proceso y donde puede
encontrase, en el disco, la tabla de pdginas para el segmento de texto cuando se intercambie.
E n sí, la estructura de texto siempre reside en memoria principal: el sistema asigna un arreglo
de estas estructuras durante el enlace. E s posible intercambiar los segmentos de texto, dntos
y pila para los procesos; cuando se intercambian, se paginan.
Las tablas de páginas contienen información de la correspondencia entre memoria virtual y
memoria física. La estructura de proceso contiene apuntadores a la tabla de páginas, que se
el
usan mientrasel
proceso reside en memoriaprincipal, o la dirección del procesoen
dispositivo de intercambios, que se emplea al intercambiar el proceso. No existe una tabla de
páginas aparte para segmentos de texto compartidos; cada uno de los procesos que comparte
el texto cuenta con entradas para sus páginas en la tabla.
La información sobre el proceso que únicamente se necesita mientras el proceso reside en
memoria (es decir, no se ha sacado por intercambio) se conserva en la estructura del usuario
(o estructura u), y no en la estructura de proceso. S e efectúa una correspondencia entre la
estructura u y el espacio de datos virtual del núcleo. Allí se conserva una copia del bloque de
control deprocesos
VAX para almacenar los registros generales, apuntador de la pila,
contador de programa y registros base de la tablade páginas correspondientes al proceso,
cuandoésteno
está en ejecución. Existe espaciopara almacenar los parámetros de la
llamada al sistema y para devolver valores; enese
espacio se conservan todos los
identificadores de grupo y usuario relacionados con el proceso (no sólo elidentificador de
usuario real que se almacenaen
la estructura dedatos).Asímismo,
allí se encuentran
estructuras de datos para señales, cronómetros y límites. El directorioactual y las tablas de
archivos abiertos, de mayor importancia para el usuario común, se conservan en la estructura
del usuario.
Cada proceso tiene unafasede
usuario y una de sistema. La mayor partedeltrabajo
ordinario lo realiza el proceso de usuario, pero cuando se emite una llamada al sistema es el
proceso de sistema quién la efectúa. Nunca se ejecutan al mismo tiempo las fases de usuario
y desistema de un proceso. El procesode sistema cuenta conuna piladistinta de la que
utilizael procesode usuario. L a pila del núcleo correspondienteal proceso se encuentra
inmediatamente después de la estructura de usuario: juntos, la pila del núcleo y la estructura
de usuario, integran el segmento de datos del sistema para el proceso.
L a Figura 2 ilustra cómo se emplea la estructura de proceso para
partes de un proceso.
encontrar las distintas
La llamada al sistema fork asigna una nueva estructura de proceso (con nuevo identificador
de proceso) para un hijo, y copia la estructura de usuario. Por lo general, no es necesaria una
nueva estructura de textos, ya que los prwesos comparten su texto; basta actualizar los
contadores y listas apropiados. Para los segmentos de datos y de pila de un proceso hijo se
construye una nueva tabla de páginas y se asigna una nueva memoria principal. AI copiar la
estructura de usuario, se conservan los descriptores de archivos abiertos, los identificadores
de usuario y grupo, el manejo de señales y la mayoría delaspropiedades similaresdeun
111
Capítulo 3
proceso.
La llamada al sistema vfork, no copia los datos y la pila al nuevo proceso; en cambio, el
nuevoprocesocompartela
tabla depáginas del anterior. De cualquier manera, se crean
nuevas estructuras de usuario y de proceso. Una aplicación comúnpara esta llamada al
sistema es que el shell ejecute un mandato y espere su terminación. El proceso padre utiliza
una llamada vfork para producir el proceso hijo. Como éste quiere usar inmediatamente una
llamada execve para cambiar todo su espacio de direcciones virtuales, no es necesaria una
copia completa del proceso padre. Algunas estructuras de datos, como las que se requieren
para manipular conductos, puedenconservarse en registros entre las llamadas vfork y execve.
Un proceso puede cerrar archivos sin afectar a otros, ya que las estructuras de datos del
núcleo que se requieren dependen de la estructurade usuario, la cual no se comparte. El
proceso padre utiliza la llamada wait para suspender su ejecución hasta que termine el hijo,
para que así el padre no modifiquela memoria que necesita el hijo.
4
Cuando el proceso padre es grande, la llamada fork puede generar ahorros considerables
eneltiempode
la UCP del sistema. Sin embargo,es unallamada al sistema bastante
peligrosa, ya que los cambios a la memoria de ambos procesos sólo ocurren cuando se emite
la llamada execve. Una alternativa consiste en compartir todas las páginas duplicando la tabla
de páginas y marcando las entradas de ambas tablas como copiar al escn'bir. Se colocan los
bits de protección paraqueatrapen
cualquier intento de escritura enestaspáginas
compartidas y,si ocurre esta trampa, se asigna un nuevo marco y a éI se copia la página
compartida. Lastablas de páginas se ajustan para mostrar que la página ya no se comparte (y
porconsiguiente ya no tiene que estar protegida contra escrituras) y la ejecución puede
continuar.
I
Una llamada al sistema execve no crea algún proceso o estructura de datos nuevos, sino
que reemplaza el texto y datos de un proceso. Se conservanlos archivos abiertos (aunque hay
unamanerade especificar el cierre de ciertos descriptores de archivo al emitir la llamada
execve); se conservan así mismo, la mayoríade las propiedadesdemanejode
señales,
aunque por razones obvias, se cancelan las disposiciones para llamar a una rutina de usuario
específica al ocurrir una señal. También permanecensin cambios el identificador del proceso y
casi todas las demás propiedadesdel proceso.
112
Implementación
de
un shell remoto
El sistema oDerativo UNlX
I
I
~-
estructura
U
pila del
núcleo
- estructura
de usuario
estructura de datos del sistema
estructura
tablas residentes
I I
I '
I
I
I
espacio de usuario
contenido intercambiable de procesos
Figura 2. Componentes de la planificación de la UCP.
I
UNlX SISTEMA VVERSIóN 4. MANUAL DEREFERENCIA
Osborne McGraw-Hill [1992]
Stephen Coffin
Págs. 3-23, 25-36.
SISTEMAS OPERATIVOS. CONCEPTOS FUNDAMENTALES
Addison-Wesley Iberoamericana[1994]
James L. Peterson
Peter B. Galvin
Págs. 568-572, 576-579.
McGraw-Hill [1992]
Jean-Marie Rifflet
Págs. 203-224,226-231.
113
CAPÍTULO
4
SISTEMAS
OPERATIVOS
DISTRIBUIDOS
I
SISTEMAS OPERATIVOS DISTRIBUIDOS
[TOMADO Y ADAPTADO DE Goscinski y PetersonI4
Los sistemasdistribuidos son desarrollados a causa de la enorme rapidez de cambio
tecnológico en el áreade los microprocesadores. El término sistemas distribuidos esusado
para definir un amplio rango de sistemas de computadora, desde sistemasdébilmente
acoplados (los procesadoresno
compartenmemoria
ni reloj; cada uno tiene su propia
memoria local y su reloj) tales como redes de área ancha, sistemas fuertemente acoplados
(los procesadores comparten memoria) tales como redes de área local, hasta sistemas muy
fuertemente acoplados (los procesadores comparten memoria y reloj)tales como sistemas
multiprocesador.
I
Las redes de área local y las redes de área ancha
rápida proporcionan una oportunidad
para conectar computadoras, en particular computadoras personales, estaciones de trabajo y
dispositivos periféricos, juntos. Las computadoras personales y las estaciones de trabajo han
llegado a ser alternativasmuyatractivas
para el enfoque de tiempocompartido (entorno
computacional multiusuario que permite a los usuarios iniciar sus propias sesionesen la
medidaque se requiera, comocuando se usan muchos servicios en línea. Un sistema que
sirve a muchosusuarios,
pero sólo parauna aplicación, es técnicamente de tiempo no
compartido) porque:
1 . La construcción basada en microprocesadores es muy barata y poderosa.
2. Pueden soportar la transferencia ' de datos
entre
procesador y dispositivosde
entradalsalida (ratón, teclado, monitor, impresora, digitalizador, etc.).
3. Cada una de ellas tiene una función dedicada.
4. Proporcionan un tiempo de respuesta predecible para las solicitudes de los usuarios.
Las capacidades de las computadoras personales y de las estaciones de trabajo son muy
amplias cuando se conectan por medio de una red de comunicación de datos (como una red
de área local o una red de área ancha rápida) aún cuando una conexión de este tipo genera el
problema de diseñar
grandes
sistemas compuestos de
procesadores
pequeños.
Este
problema se resuelve principalmente en el nivel de software de estos sistemas.
I
Capitulo 4
Los sistemas distribuidos desarrollados con base en redes de área local y redes de área
ancha rápidas tienen ventajas y desventajas.
de
Las ventajas de los sistemas distribuidos desarrollados enbasealainterconexión
computadoras personales, estaciones de trabajo, y computadoras conectadas por medio de
redes de área local y redes de área ancha rápidas son:
1. El sistema entero es más confiable y aprovechable que un sistema de tiempo compartido
(unas pocas partes del sistema pueden ser inoperantes sin causar disturbios a la gente
que usa las otras partes).
recursos
de hardware
costosos
tales como
2. Es posible compartir unos cuantos
impresoras,discos duros, graficadores, de una manera tanefectiva como la de los
recursos de software compartidos.
computaciónmuy considerable, pero susrecursos de
3. Una red puede tener poder de
computación son distribuidos.
I
Las desventajas (problemas) de desarrollo de sistemas distribuidos basados en redes de
área local y redes deárea ancha son los siguientes:
1. La seguridad podría prescribir que algunos datos no puedan ser transferidos todos o en
parte a cualquier otra máquina, incluyendo el lugar de solicitud del usuario; así el usuario
debe usar un procesador remoto para acceder datos.
no armonizar conla
distribución de las
2. La distribución física de recursospodría
demandas de servicios. Esto implica que algunosrecursos
podrían estar ociosos
mientras otros estarían sobrecargados.
o una estación de trabajo pudieran tener
computadorapersonal
3. Aúncuandouna
capacidades computacionales significativas, supoderes
menor queelesperado
de
computadoras grandes.
Todos
estos
problemas
pueden
recursos:
ser
solucionados
mediante
el
compartimiento de
lntercambio de información compartida.
Este tipo de compartimiento está relacionado
con la primera de las desventajas listadas arriba, que es la seguridad de datos. En las redes,
no hay un sistema operativo central confiable. Esto implica que un propietario específico de
datos debecompartiruna
máquina con usuarios que necesitan acceder los datos, y para
protegerdatos específicos, lamáquina del propietario restringe lo que los otros usuarios
involucrados pueden hacer con la máquina. Ejemplos de este tipo de compartimiento son los
programas de correo electrónico y las bases de datos locales.
Distribucióndecargacompartida.
Este tipo de compartimientoes
resultadodel
problema de conexiónrelacionado con el desbalanceo be ca@a en una red.El compartimiento
puede ser usadopara distribuir la cargamásuniformemente.
Un ejemplo deestetipode
compartimiento es un usuariocorriendo un programa interactivo. Sihaymáquinas ociosas
disponibles en la red, podría ser ventajoso usar la máquina remota para ejecutar el programa.
118
I
-.-""
..."
Sistemas operativos distribuidos
Compartimientoparaelparalelismocomputacional.
Cuando los recursosde
computaciónen las redesde cornputadoilas son distribuidos paraobtenermáspoderde
procesamientoque el que está disponible en cualquier computadorapersonal dada, es
necesario algún grado de compartimiento para correr algunos procesos en paralelo. Ejemplos
de este tipo de compartimiento es el procesamientos de seilales ghficas de computadora,
verificadores de diseilo de reglas para diseiio de sistemas asistidos por compufadora y la
simulación de sistemas fisicos.
Un sistema operativo de un sistema distribuido desarrollado sobre la base de una red de
debería
soportar todos los problemas
área local (o una red de área ancha rápida)
representados arriba. Esto
hace
que efectivamente tal sistema operativo pudiera ser
distribuido. El lugar de un sistema operativo en un ambiente distribuido y su distribución son
ilustrados en la Figura 1.
I
Computadora A
Computadora B
Programa de
usuario
de
Programa de
usuario
r1o a usuarm
Ruta
datos
datos
Sistema
operativo
de
Sistema
operativo
Comunicaci6n proceso a proceso
Ruta
datos
Dispositivo de
comunicación
1
datos
+
de
Transmisión dedatos
b
Dispositivo de
comunicación
Medio
comunlcaclon
Figura 1. El lugar de un sistema operativo en un ambientedistribuido.
Los sistemasoperativosdistribuidos
tienen muchosaspectosencomúncon
los
sistemas operativos centralizados, pero también difieren en muchos aspectos. Un sistema
sistema
operativo distribuido contiene los mismos elementos de administración queun
operativo centralizado: administración de procesos (objetos), administración de memoria,
administración de entrada/salida (€/S), administración de la comunicación, administración de
dispositivos y administración de archivos. Esta lista de elementos de administración define
también lo que un sistema operativo debería hacer.
119
6
Capítulo 4
Enun
sistema operativo distribuido,. los recursosestán
dispersos en el espacio, e
interconectados por una red de comunicaciones. Además, los recursos de computación y la
red son generalmente entidades de control autónomas. Así, la meta primaria de un sistema
operativo distribuido es controlar la localización de recursos, y entonces integrar y controlar los
recursos de computación y los servicios de la red de comunicaciones en un sistema simp!(?.
Los recursos del sistema también deberían ser protegidos contra el acceso de usuarios no
autorizados. Estoproporciona servicios equivalentesa aquéllos deun sistema operativo
centralizado convencional. Además, un sistema operativo distribuido debería proporcionar al
usuario una computadora virtual que sirva como un entorno conveniente.
Estasmetasdeberían
ser llevadas acaboaúncon
la presenciade las restricciones
impuestas por los diseñadores y usuarios del sistema, y de las limitaciones de los subsistemas
componentes.Estas restricciones son normalmente: requerimientos para la fransparencia y
seguridad, habilidad para funcionar con fallas,.del subsistema, capacidad de procesamiento,
flexibilidad, simplicidad, integridad y algunas veces un requerimiento para integrar subsistemas
área ancha rápidas, la
heterogéneos.Enelcasoderedesde
área local y redesde
construcción de un sistema operativo que cumple con los requerimientos de la definición dada
arriba implica el diseño y problemasdeimplementaciónnoconocidosen
el áreade Ius
sistemas operativos centralizados.
UNA DEFlNlClON Y FUNCIONES DE UN SISTEMA OPERATIVO
DISTRIBUIDO
Un sistema operativo distribuido debería:
1. Controlar la localización de los recursos de la red para permitir usarlos de la forma más
efectiva.
2. Proporcionar al usuario una computadora virtual conveniente que sirva como un entorno
de programación dealto nivel.
3. Ocultar la distribución de los recursos (transparencia).
4. Proporcionarmecanismospara
la protección de los recursos del sistema contra el
acceso de usuarios noautorizados.
5. Proporcionar una comunicaciónsegura.
Un sistema operativo distribuido es aquel que es visto por sus usuarios como un sistema
operativo centralizado ordinario, peroque corre .en unidades centrales deprocesamiento
múltiples e independientes, donde:
l . El uso de múltiple procesadores deberíaser invisible (transparente) para el usuario.
6
2. El usuario ve el sistema como un procesador virtualÚnico, no como una colección de
máquinas distintas conectadas porun subsisterna de comunicación.
120
Implementación
un de
remoto
shell
i
I
Cualesquiera decísiotles de adtnlnlstracl6n (cot,trol) deberían ser hechas cut1 base et1 urla
informaci6n de datos adecuada y actualizada. La falta de datos actualizados hacen que todos
los problemas de administración sean muy dificiles o imposibles de resolver. Uno de los
problemas más importantes de los sistemas operativos distribuidos es la falta de información
de estado global y de información de datos actualizada.
1
Aspectos de la administración de recursos tales como una planificación del procesador,
balanceo de carga, detección, prevención y recuperación de abrazos mortales, comunicación y
sincronización entre procesos, direccionamiento y protección, tolerancia a fallas, comunicación
segura, y los servicios aserproporcionados,
los cualescrean
la experiencia parala
administración de elementos, deben ser resueltos teniendo la distribución en mente. Es bien
sabido que la teoría de control para el desarrollo de algoritmos y métodos distribuidos es muy
compleja.
En la distribución de elementos de procesamiento y otros recursos, uno de los elementos
más importantesde un sistema operativo distribuido es la comunicación entre procesos
remotos (procesos en diferentes lugares) llamada comunicación entre procesos (remota)
(IPC). El alto desempeño de dicha comunicación es la facilidad más crítica que debe ofrecer
un sistema distribuido, y depende de las primitivas de comunicación entre procesos, y de los
protocolos de transporte que soportan estas primitivas. Es arriba del protocolo de la capa de
transporte donde se conjuga lo que el sistema operativo ofrece a sus usuarios y lo que el
subsistema de comunicación proporciona realmente.
El sistema de comunicacióndeberíaposeer
,muchas funciones especiales, tales como
registrode procesos,y el establecimiento, cierre ymanipulación de rutas entre procesos
comunicantes. Además este elemento debería llevar a cabo el enrutamiento de mensajes, y
proporcionar una transferencia confiable.
Pueden distinguirse dos tipos de sistemas operativos para redes de área local: sistemas
operativos de red y sistemas operativos distribuidos. El factor más importante usado para
diferenciar sistemas operativos de red de sistemas operativos distribuidos es la transparencia,
esto es, la forma enque
los usuarios perciben que estár: siendo usadas múltiples
computadoras. La definición de un sistema operativo distribuido presentada aquí ilustra que
este tipo de sistema oculta la existencia y distribución de múltiples computadoras. Los usuarios
que trabajan con sistemas operativos de red están conscientes de donde está localizado cada
tipo derecurso usado. El sistema operativo de red está construidosobre un conjuntose
sistemas operativos centralizados (locales) existentes y maneja la interface y coordinación de
operacionesremotas y las comunicaciones entre los sistemas operativos locales. Por otra
parte,el sistema operativo distribuido es construido tomando en cuenta elhardware, para
controlar y optimar todas las operaciones y recursos en un sistema distribuido, no solamente el
nivel de comunicación de la red.
121
Capitulo 4
CARACTERiSTlCAS BASCAS DE,LOS SISTEMAS OPERATIVOS DE RED
Los dos factores principales tomados en cuenta para desarrollar e implementar sistemas
operativos de red para redes deárea local y redes de área ancha son:
1. Un deseo de mejorar el rendimiento de las computadoras sin los límites de la capacidad
del procesador.
2. La necesidad de compartir recursos.
Los sistemas operativos de red fueronconsiderados como una colección de sistemas
operativos de computadoras conectadas a una red incorporando módulos para proporcionar
acceso a recursos remotos.
Unapercepción tal essimple y barata cuando se implanta, peroen general, un usuario
necesita saber la localización de un recursorequerido.
Un sistema operativo de red tiene el siguiente conjunto de características que lo distinguen
de un sistemaoperativo distribuido:
1. Cadacomputadora tiene susistema operativo privado, en vez de correr parte deun
sistema operativo, global, de un sistema grande.
2. Cada usuario generalmente trabaja en su propia computadora o en una computadora
designada, usando una computadora diferente que invariablemente requiere algún tipo
de “conexión remota”, en lugar de tener un sistema operativo que localice dinámicamente
I
en
procesos
las CPUs.
3. Los usuarios están generalmente conscientes de donde está almacenado cada uno de
con
comandos
de
sus archivos y deben mover archivos entre computadoras
“transferencia de archivos” explícitos, en lugar de tener un administrador de colocación
de archivos por parte de el sistema operativo.
4. El sistema tiene poca o ninguna tolerancia a fallas; si un porcentaje de las computadoras
personales fallan, un porcentaje de los usuarios estará desocupado, en vez de que cada
uno simplemente sea capaz de continuar su trabajo normal, aunque con un porcentaje
de rendimiento más bajo.
red es ilustrado en la Figura 2. Pueden ser
El ambientede un sistemaoperativode
distinguidos los siguientes módulos estructurados jerárquicamente: el de comunicación, uno
del sistema operativo de red, uno delsistema operativo local y unode los procesos del
usuario.
El módulodecomunicaciónen
el sistema opwativode red proporcionaunaentrega
comunicación
para
las
confiable de
mensajes
entre computadoras y facilidades de
computadoras conectadas porla red.
La capa del sistema operativo de red proporciona los siguientes servicios: acepta
solicitudes para operaciones remotas, determinala localización de recursos necesarios, define
formas de iniciación de estas operacionesy servicios de retorno. Es necesario enfatizar que en
esta etapa el sistema operativo de red liga y coordir.a las acciones remotas y la comunicación
entre sistemas operativos locales.
122
.
_
“
Implcmentación
un de
remoto
shell
”
“
,
El sistema operativo local es tradicional centralizado. La única diferencia (menor) entre el
sistema operativo local y el centralizado es que tiene que llamar al sistema operativo de red
cuando una solicitud para una operación de rendimiento no puede
ser servida localmente.
Esto significa que el sistema operativo local ve al sistema operativo de red como un servidor
local, normal.
La cuarta capa de el sistema operativo de red es creada por los usuarios.
Computadora A
Computadora B
Procesos delusuario
Procesos del usuario
Sistema operativo local
Sistema operativo local
Sistema operativo de red
Sistema operativo de red
Módulo de comunicación
Módulo de comunicación
A
Red de computadorh
Figura 2. Un entorno deun sistema operativo de red.
DIFERENCIAS ENTRE SISTEMAS OPERATIVOS DE RED Y SISTEMAS
OPERATIVOS DISTRIBUIDOS
Las diferencias entre los sistemas operativos de red y los sistemas operativos distribuidos
pueden simplementeser explicados basándose enel análisis de la localización de los módulos
delacomunicación
entre procesosenuna
estructura jerárquica desistemas operativos
un sistema
centralizados, y su influencia en los servicios ofrecidos a los usuariosde
distribuido.
Para iniciar esta explicación es útil analizar los sistemas operativos centralizados. El modelo
de un sistema operativo centralizado y los servicios que están disponibles para un usuario se
ilustran en la Figura 3.
123
Capítulo 4
Estructura jerárquica
de
un sistema
operativo centralizado
Servicios ofrecidos al usuario.
accesiblesRecursos
Archivos
Impresoras, graficadores
Procesamiento
Procesos
I
Figura 3. Laestructurajerárquica
de un sistema operativo centralizado y los servicios
ofrecidos a un usuario, si los recursos adecuados están disponibles.
Este modelo basado en el concepto jerárquico es muy útil cuando se analiza la influencia
de la localizacióndeun sistema de comunicacribn entre procesos, tomandoencuenta los
servicios proporcionados a un usuario, en otras palabras, los recursos ofrecidos a un usuario.
Se supone que los diferentes recursos están conectados a una red como se ilustra en la
Figura 4. Para simplificar el análisis, se ha supuesto, que al menos un recurso de cada tipo
está en la red. Esto significa que un conjunto de recursos, similares a aquellos en un sistema
centralizado, está disponibles para los usuarios que están trabajando en la red.
La localización de los módulosdecomunicación
entre procesos (IPC) en la estructura
jerárquica del sistema operativo para un sistema distribuido y los servicios remotos ofrecidos a
un usuario son ilustrados en la Figura 5.
I
Se ve que entre más bajo esté colocado el módulo de comunicación entre procesos, la
transparencia de la red aumenta. Un análisis de la Figura 5.c muestra sin embargo, que
solamente la estructura del sistema operativo que contiene el módulo de comunicacióv erYre
procesos como unaparte integral de la capa de administración de procesos suministra
servicios que
completan
los requerimientos del sistema operativo distribuido, que es,
solamente como una estructura que oculta la localización de recursos.
Un sistema de red típico es una colección de sistemas operativos centralizados locales en
compañía de impresoras, graficadores y servidores de archivo conectados juntos por medio de
una red. El sistema operativo dered ve los recursoscomo localizados por suspropias
computadoras. Esto implica quelos usuariosque desean correr un procesoremotamente,
tienenqueconocersu
localización correcta en la red. Después de esto, el usuario debe
asociar sus procesos con el proceso remoto, y en1:iar una solicitud para correr ese proceso en
lacomputadora escogida. El sistema operativo local destino verá eseproceso como un
proceso recientemente creado. Así, si se requiere alguna sincronización con cualquier proceso
de la
computadora
fuente, esta operación
es
responsabilidad
del usuario y sólo es
parcialmente soportada por el sistema.
Implementación
un de
124
.
~"*.-m
shell remoto
-l..
.
Servidor de
Archivo
Disco duro
Servidor de
Impresora
Impresora 1
Servidor de
impresora
Impresora 2
I
I
I
Subsistema de comunicacion
g
Servidor de
graficador
Graficador
Servidor de
nombre
Computadora
I
I
I
I
I
Procesador M
o
Usuario 1
I
Usuario N
m
w
Servidores de Procesamiento
Figura 4. Red basada en un sistema distribuido.
I
Resumiendo, se puede decir que cualquier sistema operativo maneja funciones; administra
procesos, la E/S, dispositivos, archivos, y en general la administración de recursos es llevada a
cabo como funciones un conjunto de funciones locales autónomas. Estas funciones deben
interactuar, pero las decisiones locales son hechas sin considerar los procesos y recursos
remotos. Las decisiones y control orientado a operaciones remotas son hechas solamente en
el nivel decomunicación de red.
En cambio, un sistema operativo distribuido es un sistema operativo de red simple visto
lógicamente como un sistema operativo simple que existe para todas las computadoras
(componentes) distribuidos(s). No hay sistemas operativos individuales para las computadoras
conectadas poruna red. Los usuarios no se enteran en dónde están almacenados sus
archivos; ni tampoco donde son ejecutados sus programas por procesos remotos. La
tolerancia a fallas es muy alta. Todas las decisiones y control son (deberían ser) llevadas a
cabo globalmente; los recursos dentro de la red son administrados de forma global usando
mecanismos globales más que mecanismos locales: en suma, la diferencia principal entre
éstos dos conceptos de sistemas operativos es la forma de ser y administrar las recursos
(global o localmente).
MIGRACIONES EN UN SISTEMA DISTRIBUIDO
usuario enla instalación A quiere acceder a datos (por
ejemplo, un archivo) que residen en la instalación B, existen dos métodos básicos para que el
sistema transfiera los datos. Una estrategia es transferir todo el archivo a la instalación A y, a
partir de ese momento, todo acceso al archivo es local. Cuando el usuario ya no requiere
acceso al archivo, se envía de regreso una copia a la instalación B (si el archivo ha sido
modificado). Si se ha efectuado una modificación mínima a un archivo de gran tamaiio, hay
que transferir todos los datos. ÉSta estrategia se utiliza en el sistema de archivos Andrew.
Migración de datos. Siun
125
Capítulo 4
ESTRUCTURA JERÁRQUICA DE UN
OPERATIVO
SISTEMA
DE RED
SERVICIOS
REMOTOS
OFRECIDOS A
UN USUARIO
Administrador de archivo
Operaciones de archivo
1
a) La IPC yace sobre la capa de administración
de los dispositivos de EIS
Administrador de dispositivos de EIS
Operaciones de archivo remotas
Impresi6n y graficacibn remotas
..IPC-
Administrador de memoria
Administrador de procesos
b) La IPC yace sobre la capa de administración
de memoria
t
Administración de dispositivos de EIS
Administración de memoria
Administración de procesos y de la IPC
I
I
Operaciones de archivo remotas
Impresión y graficación remotas
Creación de procesos remotos,
protección, sincronización, etc.
I
c) La IPC es una parte integral de la capa de
administración de procesos
Figura 5. Colocación de unIPC en una estructura de un sistema operativo.
El otro enfoque consiste en transferir a la instalación A sólo las porciones del archivo que
en ese momento realmente son necesarias para la tarea actual. Si más tarde se requiere otra
porción se efectuará otra transferencia y, cuando el usuario ya no quiera acceder al archivo,
todas las porciones modificadasse deberán enviar de regreso a B. El protocolo del Sistema de
El sistema también debe
Archivos en Red (NFS) de Sun Microsystemsutdizaéstemétodo.
realizar varias traducciones de los datos si las instalaciones no son directamente compatibles.
Migración de cáilculos. En ciertas circunstancias puede ser más eficiente transferir los
cálculos por el sistema, en vez de los datos. Por ejemplo, considérese un trabajo que necesite
acceder a varios archivos degran tamaño que residen en instalaciones diferentes, para
obtener un resumen de ésos archivos. Sería más eficiente que el acceso a los archivos se
efectuara en las instalaciones donde residen yluego enviar los resultados deseados a la
instalación que inició los cálculos.
Hay varias maneras de llevar a cabo éstos cAlculos. Suponga que el proceso p requiere
acceder a un archivo en la instalación A. El acceso al archivo se lleva a cabo en la instalación
A y podría iniciarse mediante una llamada a procedimiento remoto; el proceso p invoca un a
procedimiento predefinido de la instalación A, el cual se ejecuta y devuelve a p los parámetros
necesarios.
!
Implementación
de
126
",-
un shell remoto
Como alternativa, elprocesoppuede
enviar un mensajeala instalación A. El sistema
operativo en A crea un nuevo proceso
q, cuya función es realizar la tarea especificada; cuando
q termina su ejecución, envía a p el resultado requerido par medio del sistema de mensajes.
En éste esquema, los procesos p y q pueden ejecutarse concurrentemente y, de hecho puede
haber varios procesos concurrentes endistintas instalaciones.
Puedenusarse
ambos esquemaspara el acceso a archivos que residen en varias
instalaciones. Unallamadaaprocedimiento
remoto puedegenerar otra llamada del mismo
tipo, o incluso la transferencia de mensajes a otra instalación. De manera parecida, el proceso
q puede, durante su ejecución, enviar un Fensaje a otra instalación, creándose otro proceso
a
que a su vez puede
repetir el ciclo o enviar un mensaje de regreso q.
’
Migración de procesos. Cuando se presenta un proceso para su ejecución, no siempre
se ejecuta en la instalación que lo inició. Puede ser provechoso ejecutar todo el proceso, o
alguna parte, en instalaciones diferentes por varias razones:
1. Equilibrio de cargas. Distribución de subprocesos (particiones de un proceso mayor) en
una red.
2. Aceleracidn de c8lculos.Ejecución concurrente de subprocesos.
3. Preferenciasdehardware.
El proceso podría ejecutarse más eficientemente en
determinado hardware.
4. Preferencias de software. Cierto software para 1un proceso podría estar sólo disponible
en determinada instalación.
\
Básicamente existen dos técnicas complementarias que se empleanparamoverprocesos
en una red. El sistema puede intentar ocultar el hecho de que el proceso se ha movido del
lugar donde está el cliente. Éste esquema tiene la ventaja de que el usuario no necesita
codificar su programa explícitamente para lograr la migración, y generalmente se emplea para
equilibrar las cargas y acelerar los cálculos entre sistemas homogéneos.
El otro enfoque consiste en permitir (o requerir) que el usuario especifique explícitamente
como debe migrar el proceso. Por lo general éste método se emplea cuando el proceso se
debe mover parasatisfacer una preferencia de hardwareo software.
ASPECTOS DE DISEÑO
El reto para muchos diseñadoresha sido ofrecer al usuario transparencia en la multiplicidad
de procesadoresy dispositivos de almacenamiento.
Un sistema distribuido transparente, facilita la movilidad del usuario, transportando su
entorno (por ejemplo, su directorio base) al lugar donde se conecte. Tantoel sistema de
archivos Andrew como el proyectoAthena ofrecen esta funcionalidad a gran escala.
127
Capítulo 4
El término tolerancia a fallas es muy amplio. Las fallas decomunicación, las fallas de
los dispositivos de
máquina (del tipo que
detiene
su
operación), los choques
en
almacenamiento ylas fallas en los medios de almacenamiento, se consideran
fallas que deben
tolerarse en cierto grado. Unsistema tolerante debe continuar su funcionamiento, quizá de
manera degradada, cuando se enfrente a ellas.Dicha degradación puede ser en cuanto a
rendimiento, funcionalidad o ambas, pero debe ser proporcional, de alguna forma, a las fallas
detiene cuando sólo fallan uncz
que la ocasionaron. No es tolerante un sistemaquese
cuantos de sus componentes. El sistema DEC VAXcluster permite que varias computadoras
compartan un conjunto de discos. Si falla un sistema, los usuarios pueden acceder aún a su
información desde otro sistema.
A la capacidad de un sistema para adaptarse a un incremento en
el serviciose le llama
capacidad de escalación. Por ejemplo, respecto a u? sistema de archivos, una saturación se
presenta cuando la tasa de utilización de l a CPU del servidor es muy elevada o cuando los
discos están casi llenos. La capacidad de escalación es una propiedad relativa, pero puede
medirsecon precisión. Unsistema escalar debe reaccionar conmayorsuavidadanteun
aumentode la carga que un sistema no escalar. Elproblemapuede resolverse añadiendo
nuevos recursos, pero se puede generar una carga indirecta adicional en otros recursos (por
ejemplo, al añadir máquinas a un sistema distribuido la red puede congestionarse y aumentar
las cargas de servicio) o, lo que es peor, la ampliación del sistema puede representar costosas
modificaciones en el diseño. En resumen, el diseño escalar debe resistir una elevada carga de
servicio, adaptarse al crecimiento de la comunidad de usuarios y permitir una sencilla
integración de recursos adicionales.
La tolerancia a fallas y la escalación están relacionadas. Un componente con mucha carga
puede paralizarse y comportarse como si tuviera una falla. Además, al desplazar la carga de
un componente(cuando falla) a su mediodealmacenamientode
respaldo, éste se puede
saturar. Generalmente es esencial contar conrecursosderepuestoparaasegurar
la
confiabilidad y para manejar con suavidadlas cargas picos. Las consideraciones de tolerancia
a fallar y capacidad de escalación requieren un diseño que presente la distribución del control
y los datos.
En gran medida, los sistemas distribuidos a muy gran escala son sólo teoría. Un principio
paradiseñarsistemasde
muy grandeescala esquela
demandade servicio de cualquier
componente del sistema debe estar limitado por una consfante independiente del número de
nodos en el sistema.
No debenemplearse los recursos centrales ni los esquemasde control central para
construir sistemas escalares (y tolerantes a fallos). Cómo ejemplos de entidades centralizadas
se tienen los servidores de validación centrales, los servidores de nombres centrales y los
servidores de archivos centrales. La centralización es una forma de asimetría funcional en
las máquinas
que
constituyen el sistema. La alternativa ideal es una configuración
funcionalmente sirnéfrica;es decir, todas las máquinas componentes tienen un papel igual en
el funcionamiento del sistema y, por consiguiente, cadamáquina tiene un cierto nivel de
autonomía. En la práctica, es virtualmente imposible adherirse a este principio, sin embargo, la
autonomía y la simetría son objetivos importantes que deben servir como guía.
128
Implementación
un de
shell remoto
La aproximación práctica a la configuración simétrica y autónoma es el agrupamiento. El
sistema se divide en un conjunto de agrupamientossemiautónomos y cada uno consiste en un
conjunto de máquinas y un servidor dedicado al agrupamiento. Si .un agrupamiento está bien
equilibrado (es decir,si el servidores suficiente para satisfacer todas las demandas del
agrupamiento), se puede emplear un bloque de construcción modular para el crecimiento del
sistema.
I
La estructura de procesos del servidores un problema mayor en el diseño de cualquier
servicio. Los servidores deben operar de manera eficiente en los períodos pico, cuando hay
quedarservicio
simultáneamentea cientos de clientes activos. Una opción es asignarun
proceso para cadacliente; sin embargo, hay que considerar el costo de los frecuentes cambios
de contexto entre procesos. Un problema relacionado es el hecho de que todos los procesos
del servidor necesitan compartir información. AI parecer, una de las mejores soluc; ; i s para la
arquitectura del servidores la utilización de procesos ligeros o hilos. La abstracción que
presenta un grupo de procesos ligeros es que los hilos de control están asociados a algunos
recursos compartidos. Usualmente, un proceso ligero no está limitado a un cliente, sino que
atiende las solicitudes de varios. Los hilos de planificación pueden ser expulsivos o no
expulsivos. Si se permite que los hilos se ejecuten hasta finalizar, entonces no senecesita
proteger explícitamente los datos compartidos; de Io contrario, es necesario usar un
mecanismodecerradura
explícita. Es indispensable algún tipo deesquemade
p! 'xesos
ligeros para que los servidores tengan capacidad deescalación.
COORDlNAClÓN DISTRIBUIDA
I
Aquíse analizarán los mecanismos que hacen posible la sincronización y comuniclciin
entre procesos, así como los métodos para tratar con el problema de los bloqueos mutuos, y
con los problemas particulares que presenta sólo un sistema distribuido a diferenciLrde un
sistema centralizado.
ORDENACIóN DE SUCESOS
En un sistema centralizado siemprees posible determinar el ordenenqueocurren
dos
sucesos, ya que se disponedeuna
memoria y un reloj comunes y únicos. En muchas
aplicaciones la posibilidad dedeterminar el orden tiene importancia primordial, como en la
asignaciónde recursos. Sin embargo, en un sistema distribuido no hay ni memoria ni reloj
comunes, por lo que la relación de ocurrencia previa es únicamente una ordenación parcial de
los sucesos.Como la capacidadpara definir unaordenación total es crucial en muchas
aplicaciones, se presenta un algoritmo distribuido para ampliar la relacióndeocurrencia
previa con el propósito de obtener una ordenación total y consistente de todos los sucesos en
el sistema.
129
Capítulo 4
La relación de ocurrencia previa: Consideraciones:
1. Sólo se consideran procesos secuenciales, por lo que todos los sucesos que se ejecutan
en un proceso están completamente ordenados.
2. Por laley de causalidad, sólo puede recibirse un mensajedespuésde quese hay?
enviado.
3. Tanto el envío como la recepción de un mensajeson sucesos.
La relación de ocurrencia previa (denotada con +) para un conjunto de sucesos se define
de la manera siguiente:
J
1. Si A y B son sucesos en el mismo proceso y A se ejecutó antes que B, entonces A+B.
2. Si A es el suceso de envío de un mensaje de un proceso y B es el suceso de recepción
. de ese mensaje por otro proceso, entonces A+B.
3. Si A+B y B+C, entonces A - K .
Como un suceso no puede ocurrir antes de si mismo, la relación
parcial irreflexiva.
+ es
una ordenación
Si dos sucesos A y B, no están relacionados por + (es decir, A+B y B+A), entonces se
puede decir que ambos procesos se ejecutan concurrentemente. Enéste caso, ninguno de los
procesos afecta causalmente al otro; sin embargo, si A+B, es posible que el suceso A afecte
al suceso B.
Las definiciones de concurrencia y ocurrencia previa se ilustran con un diagrama espaciotiempo en la Figura 6. La dirección horizontal representa el espacio (procesos distintos) y la
vertical señala el tiempo. Las líneas verticales etiquetadas denotan procesos(o procesadores),
mientras que los puntos etiquetados indican sucesos. Viendo el diagrama se concluye que los
sucesos A y B son concurrentes si y sólo si no existe una ruta de A a B o de B a A. (Figura 6).
1
Q
P
Figura 6. Tiempo relativo para tres procesos concurrentes.
Observando la Figura 6, algunos de los sucesos relacionados por la relación de ocurrencia
130
Implementación
shell un
de
I.
R
remoto
previa son:
Algunos de los sucesos concurrentes enel sistema son:
PO Y 90
90 Y rl
ro Y 91
1
'
No se puede saber cuál de dos procesos concurrentes ocurrió primero, sin embargo como
algunos de ellos no puede afectar al otro, esto no es importante. Lo importante es que los
procesos que se interesan por el orden de dos sucesos concurrentes estén de acuerdo en
algún tipo de ordenación.
Implanfaci6n. Paradeterminarqueun
suceso A ocurrió antesque un sucesoB, se
necesita un reloj común o un conjunto de relojes perfectamente sincronizados. Como ninguno
de éstos existe en un sistema distribuido, se debe definir la relación de ocurrencia previa sin
emplear relojes físicos.
A cada suceso del sistema se le asocia una marca de tiempo; luego, se puede definir el
requisito de ordenación global: para todo par desucesos A y B, si A+B, entonces la marca de
tiempo de A es menor que la de B. (Obsérvese que el caso contrario no tiene por qué ser
verdadero).
En un entorno distribuido para implantar la ordenación global en cada proceso Pi se define
un reloj Iógico, RLi. Este reloj lógico puede implantarse como un contador sencillo que se
incrementa entre cualquier par de sucesos consecutivos que se
ejecuten en un proceso.Como
el reloj lógico tiene un valor monbtonamente creciente, asigna un número a cada suceso, y si
un suceso A ocurre antes queel evento B enel proceso P, entonces RLI(A)< RL,(B).
Este esquema asegura que se cumpla el requisito ¿e ordenación global para cualquier par
desucesosen
un mismo proceso, peronoaseguradicho
requisito entre procesos. Para
ilustrar el problema, considérenselos procesos PI y P2,que se comunicanentre sí. Supóngase
que P, envía un mensaje a P2 (suceso A) con RL1(A)=200, y PZrecibe el mensaje (suceso B)
con RL2(B)=195(por que el procesador de Pzes más lento que el procesador de PI, y su reloj
avanza más despacio).
Para resolver ésta dificultad se requiere que un proceso adelante su reloj lógico cuando
reciba un mensajecuyamarcade
tiemposea
mayorqueel
valor desu
reloj lógico.
Concretamente, si elproceso Pi recibe un mensaje (suceso B) conmarcade
tiempo t y
RLi(B)<t,entoncesdebeadelantar
su reloj de manera que RLi(B)=t+l. Así, enel ejemplo,
cuando P2, recibe el, mensajede
PI, RLzadelantarásu
reloj lógico de manera que
RLz(B)=201.
131
Capítulo 4
Para efectuar unaordenación total, se tiene queobservar
que, con el esquemade
ordenación propuesto pormarca de tiempo, si las marcas de tiempo de dos sucesosA y B son
iguales, entonces los sucesos son concurrentes. En este caso se pueden emplear los números
de identidad de los procesos para romper el empate y crear una ordenacióntotal.
EXCLUSION MUTUA
En esta parte se presentan varios algoritmos para implantar la exclusión mutua en un
entorno distribuido. Se supone que el sistema consta de n procesos, cada uno de los cuales
reside en un procesador distinto. Para simplificar el análisis, se suponetambién que los
procesos tienen una numeración Qnica de unoea n, y que hay una relación uno a uno entre
procesos y procesadores (es decir, cada procesotiene su gropio procesador).
Enfoquecenfralizado. Con el enfoque centralizado paraproporcionar la exclusión
mutua, se escoge uno de los procesos en el sistema para coordinar la entrada a la sección
crítica. Cada proceso que quiere invocar la exclusión mutua envia un mensaje de solicitud al
coordinador. Cuando el proceso recibe un mensajederespuesta
del coordinador, puede
continuar y entrar a su sección crítica. Después de salir de allí, el proceso envía al coordinador
un mensaje de liberación y prosigue su ejecución.
AI recibir un mensaje de solicitud, el coordinador comprueba si algún otro proceso está en
su sección crítica. Si nohay alguno, el coordinador envía deinmediatounmensajede
respuesta; de lo contrario, la solicitud se coloca en la cola. Cuando el coordinador recibe un
mensaje de liberación saca uno de los mensajes de solicitud de la cola (de acuerdo con algún
algoritmo de planificación) y envía un mensaje de respuestaal proceso solicitante.
Este algoritmo asegura la exclusión mutua. Si la política de planificación del coordinador es
justa (como la planificación de servicio por orden de llegada), no puede ocurrir el bloqueo
indefinido. Este esquema requiere tres mensajes por cada entrada a la sección crítica: una
solicitud, una respuesta y una liberación.
Si falta el proceso coordinador, entonces un nuevo proceso debe ocupar su lugar. Una vez
que se elige un nuevo coordinador, éste debe llevar a cabo un ondeo entre los procesos en el
sistema para- reconstruir sucola de solicitudes y, después de esto, puedenreanudar los
cálculos.
P
El algoritmo siguiente está basado ,-n el
esquema de ordenación de sucesos
descrito anteriormente.
Enfoquecomplefamenfedistribuido.
de
Cuando un proceso Pi quiere entrar en susección critica, generaunanuevamarca
tiempo, NIT, y envía el mensaje solicitud (Pi, MT) atodos
los procesos del sistema
(incluyéndose a si mismo). AI recibir un mensaje de solicitud, un proceso puede responder de
inmediato (es decir, enviar un mensaje de respuesta a Pi) o puede diferir la respuesta (pues,
132
Implementación
un de
l"l."
l.
P
remoto
shell
."._
___".
__
-
por ejemplo, ya se encuentra en su secci6n crítica). Un proceso que harecibido un mensaje de
respuestadetodos los demás procesosen el sistema puede entrar en su sección crítica
colocandoenuna
cola todas las solicitudes que reciba y posponiendo sus respuestas.
Después de salir de su sección crítica, el proceso envía mensajes de respuesta a todas las
solicitudes que difirió.
"
La decisión de si el proceso Pi responde de inmediato a
difiere su respuesta, depende de tres factores:
un mensaje solicitud (Pi, MT) o
1. Si el proceso Pi se encuentra en su sección crítica, entonces difiere su respuesta a Pi.
2. Si el proceso Pi no quiere entrar en su sección crítica, entonces envía de inmediato una
respuesta a Pi.
3. Si el proceso Pi quiere entrar en su sección Crítica pero aún no lo ha hecho, entonces
compara la marca de tiempo de su solicitud con la marca de tiempo MT de la solicitud
efectuada por el proceso Pi. Si su propio marco de tiempo es mayor que MT, entonces
envía inmediatamente una respuesta a Pj (Pi lo solicitó antes); de lo contrario, se difiere
la respuesta.
Este algoritmo presenta el siguiente comportamiento deseable:
1. Se obtiene la exclusión mutua.
mutuos.
2. Se asegura que no haya bloqueos
3. Se asegura que no existan bloqueos indefinidos, ya que la entrada en la sección crítica
se planifica de acuerdo con la ordenación de,la marca de tiempo, lo que asegura que los
procesos se atiendan por orden dellegada.
4. El menor número de mensajes requeridos por entrada a la sección crítica cuando los
procesos actúan independientey concurrentementees 2x(n-1).
Este esquema requiere la participación de todos los procesos del sistema. Este enfoque
tiene tres consecuencias indeseables:
l.Los procesos necesitan conocer la identidad de todos los demás procesos. Cuando un
nuevo proceso se une al grupo queparticipa en el algoritmo de exclusión mutua, hay que
iniciar las siguientes acciones:
a) El proceso debe recibir los nombres de todoslos demás procesos enel grupo.
b) Hay que distribuir el nombre del nuevo proceso alos demás procesosdel grupo.
1. Si falla uno de los procesos, se viene abajo todo el esquema. Se puede resolver éste
problema supervisando continuamente el estado de todoslos procesos en el sistema. Si
solicitud.
uno falla, se notifica a los demás para queya noleenvíenmensajesde
Cuando el proceso se recupere debeiniciar el procedimiento que le permita
integrarse de
nuevo al grupo.
2. Los procesosquenohanentradoen
susección
critica deben efectuar pausas
frecuentes para asegurar, a los demás procesos, que pretenden entrar en su sección
crítica. Por lo anterior, éste protocolo es adecuadolpara pequeños conjuntos estables de
procesos cooperativos.
133
Capítulo 4
Enfoque de paso de testigo. Un testigo es un tipo de mensaje especial que pasa por el
sistema, y la posesión del testigo permite entrar en la sección crítica. Puesto que sólo existe un
testigo en el sistema, únicamente. puede haber un proceso en su sección crítica al mismo
tiempo.
Mientras los procesos estén conectados entre sí, es posible implantar un anillo lógico,
haciendo circular por éI el testigo. Cuando un proceso recibe el testigo, puede entrar en su
sección critica, reteniendo el testigo. Una vez que el proceso sale de su sección critica, vuelve
a pasarse el testigo. Si el proceso que recibe el testigo, no quiere entrar a su sección crítica, lo
pasa a su vecino.
Si el anillo es unidireccional, se asegura que no se presenten bloqueos indefinidos. El
número de mensajes requeridos para implantar laexclusión mutua puede variar desde un
mensaje de entrada, en el caso de un alto nivel de contiendas (es decir, todos los procesos
quieren entrar a su seccióncrítica), hasta unncmero infinibde mensajes si el nivel de
contienda es bajo (ningún proceso quiere entrar a su sección crítica).
Hayque considerar dostiposdefallas:primero,si
el trabajo se pierde, es necesario
convocar una elección para generar uno nuevo; segundo, sí falla un proceso, se debe
establecer un nuevo anillo lógico.
PREVENCIóN DE BLOQUEOS MUTUOS
Los algoritmos de prevención y evitación de bloqueos mutuos convencionales, pueden
emplearse enun sistemadistribuido,si
se efectúan las modificaciones necesarias. Por
ejemplo, para emplear la técnica de ordenación de recursos para la prevención de bloqueos
mutuos, se asignan números únicos a todos los recursos del sistema, y un proceso sólo puede
solicitar un recurso de cualquier procesador con número y únicamente si no tiene un recurso
con número Único menor o igual a i. De manera parecida, en un sistema distribuido, se puede
utilizar el algoritmo del banquero, designando a uno delos
procesos del sistema (el
banquero) para que mantenga la información necesaria para llevar a cabo el algoritmo. Todas
las solicitudes de recursos deben canalizares a través del banquero.
I
La primera estrategia es fácil de implantar y requiere poco tiempo de procesamiento
adicional. La segunda estrategia también es de fácilimplantación, aunque puede requerir
demasiado tiempo de procesamiento adicional.
Se presenta ahora un esquema de prevención c!e bloqueos mutuos basado en el enfoque
de ordenación por marca de tiempo con expropiación de recursos. Por cuestiones de sencillez,
únicamente se considera el caso de un solo ejempl?r de cada tipo de recursos.
Para controlar la expropiación, se asignav números de prioridad única a cada proceso, los
cuales se usan para decidir si un proceso Pi debe esperar a un proceso Pi. Por ejemplo, se
puede dejar que Pi espere a Pj si Pi tiene mayor prioridad que Pj, de lo contrario, se retrocede
134
Implementación
de
""-.-"
remoto
un shell
"
I
X
-
.-.
a Pi. Este esquema previene los bloqueos mutuos, pues para cada arista Pi+Pi del grafo de
esperas, Pi tiene mayor prioridad que Pi, por lo que no puedeexistir un ciclo.
Un problema con esta estrategia es la posibilidad de los bloqueos indefinidos, ya que es
posible quesiempreretrocedanalgunos
procesos con prioridad muy baja. Este problema
puede evitarse utilizando marcas de tiempo, asignando una marca única ai crear cada uno de
los procesos en el sistema. Se han propuesto dos esquemas complementarios que utilizan
marcas de tiempo paraprevenir los bloqueos mutuos.
Esquema no expropiativo. Cuando el proceso Pi solicita un recurso que en ese momento
retiene Pi, se permite que Pi espere sólo si tiene una marca de tiempo menor a la de Pi (es
decir, Pi es más viejo que Pj); de lo contrario, Pi retrocede.
'
Esquema expropiativo. Cuando un proceso Pisolicita un recurso que en ese
momento
posee Pi, se permite que Pi espere sólo si tiene una marca de tiempo mayor a la de Pi (es
decir, Pi es más joven que Pi); de lo contrario, Pi retrocede (Pi es expulsado porPi).
Ambosesquemaspueden evitar los bloqueos indefinidos, siempreque al retroceder un
proceso, no se le asigne una nueva marca detiempo.
En el esquema no expropiativo, el proceso más viejo debe esperar a que otro más joven
libere su recurso. Por tanto, cuanto más envejece un proceso, más tiende a esperar. Por el
contrario, en el esquema expropiativo, un procesolviejo nunca espera a unojoven.
Además hay menos retrocesos en el esquema expropiativo. El principal problema con estos
dos esquemas es que pueden ocurrir retrocesos innecesarios.
DETECClbN DE BLOQUEOS MUTUOS
El algoritmo de prevención de bloqueos mutuos puede expropiar recursos, incluso si no ha
ocurrido ningún bloqueo mutuo. Paraevitar expropiaciones innecesarias, se puede emplear un
algoritmo de detección de bloqueosmutuos, construyendo un grafo de esperas quedescriba el
estado de asignación de los recursos. Como se supone que sólo hay un recurso de cada tipo,
un ciclo en de el grafo esperas representaun bloqueo mutuo.
El mayor problema con un sistema con un sistema distribuido es decidir como mantener el
grafo de esperas. Se requiere para ello, que cada instalación cuente con un grafo de esperas
local. Los nodos del grafo correspondenatodos los procesos (locales o no) queen ese
momento poseen o solicitan algunos de los recursos locales de la instalación. (Ver Figura 7).
Estos grafos locales de esperas están construidos1 de la manera usual para procesos
y
recursos locales. Cuando un proceso Pi de la instalación A necesita un recurso que retiene el
proceso Pi en la instalación B, Pi envía un mensaje de solicitud a la instalación B; luego se
inserta la arista Pi+Pj en el grafo local de esperas de la instalación B.
135
Capítulo 4
Si un grafo de esperas local tiene un ciclo, ha ocurrido un bloqueo mutuo. Sin embargo,
el sistema completo, se debe
para demostrar quenoha
ocurrido un bloqueomutuoen
demostrar que la unión de todos los grafos locales es acíclica. En la Figura 8 se muestra que
ha ocurrido un bloqueo mutuo, aunquesus correspondientes grafos locales son acíclicos.
x-x
PS
Instalación B
Instalación A
Figura 7. Grafos locales de esperas.
Figura 8. Grafo global de esperas para la Figura 7.
i
Enfoquecentralizado.
En el enfoque centralizado, un grafo global deesperas se
construye como la unión de todos los grafos locales de esperas, y se mantiene en un proceso
Único: el coordinador de detección de bloqueos mutuos. Puesto que existe una demora en
las comunicaciones del sistema, se debe diferenciar entre dos tipos de grafos de espera: el
grafo real, pero desconocido del sistema en un momento determinado; el grafo construido en
una aproximación generada por el coordinador durante la ejecución :de un algoritmo. No es
fácil hacer los grafos construidos.
Existen tres instantes de tiempo diferentes en los quese
esperas:
136
"
Implementación
un de
puede construir el grafo de
shell remoto
"
"
, "
-x___
.
"
"
"
"
-
Sistemas operativos
distribuidos
. ""
.-.
"
"
I
-
.."
,
..
I.Al hlsorlctr o olimitrar urlu urivttr do UI~Od~ los grctlos locales de espora.
2. Peri6dicamente, cada vez que ocurra determinado número de cambios en el grafo de
esperas.
3. Cada vez que el coordinador
necesite invocar el algoritmo de detección deciclos.
Considerando la opción 1, al invocar el algoritmo de detecdión debloqueosmutuos, el
coordinador busca en su grafo global; si encuentra un ciclo, se selecciona una víctima para
retroceso. El coordinador debe notificar a todas las instalaciones que se ha seleccionado un
proceso determinado como víctima; a su vez, las instalaciones deben retroceder el proceso
víctima.
Con este esquema puedenocurrir retrocesos innecesarios debido a dossituaciones:
1. Pueden existir ciclos falsos en el grafo global de esperas, debido a que se presente una
inserción antes de unaeliminación de un recurso.
2. Sirealmenteha ocurrido un bloqueomutuo y se haseleccionado la víctima, pero al
mismo tiempo alguno delos procesos ha abortado por razones ajenas al bloqueo mutuo,
se presenta retroceso innecesario.
Obsérvese que estos
otras dos opciones.
mismos problemasse heredan en las soluciones que emplean las
Se presenta ahora un algoritmo centralizado de detección de bloqueos mutuos,utilizando la
opción 3, que detecta todos los bloqueos mutuos que realmente ocurren, y no los falsos. Para
evitar que se notifiquen falsos bloqueos mutuos, se requiere que las solicitudes procedentes
de distintas instalaciones cuenten con identificadores únicos (marcas de tiempo). Cuando el
proceso Pi dela instalación A, solicita un recurso de Pi, enla instalación B, seenvía un
mensaje de solicitud con marca de tiempoMT y se inserta una arista Pi+Pi con la etiqueta MT
en el grafo local de esperas de A. Esta arista se inserta en el grafo local de B únicamente si B
ha recibido el mensaje de solicitud y no puede concederel recurso de inmediato. Una solicitud
de Pi a Pi, en la misma instalación, se maneja de la manera habitual, sin asociar marcas de
tiempo a la arista Pi+Pj. Entonces, elalgoritmo de detecciónes el siguiente:
El controlador envía un mensaje deinicio a aada instalación del sistema.
AI recibir éste mensaje, una instalación envía al coordinador su grafo local de esperas.
Cada uno de estos
grafos contiene toda la información local que tiene la instalación
respecto al estado del grafo real. El grafo refleja un estado instantáneo de la instalación,
pero no está sincronizado respecto a ningunaotra.
Una vez que el controlador ha recibido una respuesta de cada instalación, construye el
grafo de la siguiente manera:
El grafo construido contiene un vértice para cada proceso enel sistema.
El grafo tiene una arista P+Pj si y sólo si
existe una arista Pi+Pj en uno delos grafos de esperas
ii) aparece una arista P+Pj con una etiqueta MT en más de un grafo de esperas.
137
CaDítulo 4
El sistema estará en un estado de bloqueo mutuo si y sólo si hay al menos un ciclo en el
grafo construido.
Enfoque Jerarquico. El algoritmo jerárquico de detección de bloqueos mutuos es un
algoritmo distribuido.
Al igual queelenfoque centralizado, cada instalación mantiene su propio grafo local; la
controladores
diferencia es queel
grafo global de esperas
se
distribuye
entre
varios
organizados en forma de árbol, donde cada hoja contiene el grafo local de esperas de una
instalación. Cada controlador que no es una hoja mantiene un grafo de esperas con
información relevante sobre los grafos de los controladores que se encuentran en el subárbol
bajo él.
En particular, sean A, B y C controladores,tales que C sea el antepasado comúnmás
cercano de A y B (C es Único, ya que se está tratando con un árbol). Supóngase que el nodo
Pi aparece en el grafo local de esperas de A y 6; entonces, Pi también debe aparecer en el
grafo local de
1. El controlador C.
2. Cada uno de los controladores en el camino de C a A.
3. Cada uno de los controladores en el camino d e C a B.
Además, si Pi y Pi aparecen en el grafo de esperas del controlador D y existe un carnino de
Pi a Pj en el grafo de uno de los hijos de D, entonces debe Aparecer en el grafo D una arista
Pl+Pj.
Si hay un ciclo en cualquiera de los grafos de espera, entonces el sistema está en estado
de bloqueo mutuo.
Para ilustrar este enfoque considérese el sistema de la Figura 7; en la Figura 9 se muestra
un árbol para este sistema.
I
N enfoque completamente distribuido. En el algoritmo completamente distribuido
de detección de bloqueos mutuos, todos los controladores comparten de manera equitativa
la responsabilidad de detectar bloqueos mutuos. En este esquema, cada instalación,
construye un grafo de esperas que representa una parte del grafo total, dependiendo del
comportamiento dinámico del sistema. La idea es que, si hay un bloqueo mutuo, aparecerá un
ciclo en (por lo menos) uno de los grafos parciales. Se presenta a continuación un algoritmo de
este tipo que comprende la construcción de grafos parciales en cada instalación.
Cada instalación mantiene su propio grafo local de esperas, añadiendo un nodo adicional
Pcx.En el grafo hay un arco Pi->P,, si Pi espera, de otra instalación, un elemento de datos
retenido por cualquier proceso. De manera similar, hay un arco P,x->Pj en el grafo si existe un
proceso en otra instalación que desea adquirir un recurso que en ese momento retiene Pj en
esta instalación local.
Para ilustrar esta situación considérense los dos grafos locales de esperas de la Figura 7.
AI añadir el nodo PC, en ambos, se obtienen los grafos locales presentados en la
138
un shell
"_""
".-"
".
Figura 10.
Si ur, grafo ioca!dessperascontiene
un cicloque no incluyeal nodo P, entonces el
sistema está en estado de bloqueo mutuo. Sin embargo, si existe un ciclo que comprende P,
significg que hay la posibilidad de un bloqueo mutuo. Para afirmar que se presenta un bloqueo
mutuo, hay que lrlvocar un algoritmo distribuido de detección.
1
Instalación C
Figura 9. Grafo de esperas jerárquico.
l""----
!nstdación I,
lmtalación l2
Figura 10. Grafos locales de esperas.
Supbngase que en la instalación I, es grafo local de esperas contieneun ciclo que implica al
Este c~clo *jebe
ser de la forma
nodo PtK.
) P k l - >Kk2
-+,..+Kn+Pey,
I
.
/(.
,
,
.
.
UniversidadAutónomaMetropolitana.Unidadlztapalapa
,
139
CaDítulo 4
que indica que la transacción Pkn en li espera adquirir un elemento de datos de alguna otra
instalación, por ejemplo, Ij. AI descubrir este ciclo, la instalación Ij manda a la instalación I, un
mensaje de detección de bloqueosmutuos que contiene información sobre el ciclo.
Cuando la instalación lj recibe el mensaje de detección de bloqueos mutuos, actualiza su
grafo local de esperas con la nueva información. Lilego consulta el grafo recién construido en
busca de un ciclo que no comprenda a Po,, si existe, se ha encontrado un bloqueo mutuo y se
invoca un esquema de recuperación apropiado.. Si se descubre un ciclo que implica a PC,,
bloqueos
mutuos
a
la instalación
entonces Ij transmite un mensaje de detección de
correspondiente, por ejemplo Ik. La instalación lk, a su vez, repite el procedimiento. De ésta
manera, tras un número finito de rondas, se descubre un bloqueo mutuo o se detienen los
c5lculos de detección de bloqueos mutuos.
SOLIDEZ
Un sistema distribuido puede padecer varios tipos de fallas de hardware, de las cuales las
más habituales son la falla de un enlace, la de una instalación y la pérdida de un mensaje.
Para asegurar que el sistema es sólido, se debe detectar cualesquiera de estas fallas,
reconfigurar el sistema para que los cálculos puedcn continuar y recuperarlo cuando se repara
una instalación o un enlace.
Detección de fallas. En un entorno que no tiene memoria compartida, generalmente no
es posible distinguir entre una falla de enlace, una falla de instalación y la pérdida de un
mensaje.
Para
detectar
las
fallas de enlace e instaiaciones se utiliza un procedimiento de
intercomunicación. Supóngase que existe un enlace físico directo entre las instalaciones A y B.
A intervalos fijos, las dos instalaciones envían un mensaje ‘Estoy bien’. Si la instalación A no
recibe este mensaje después de cierto tiempo, puede Fuponerse que ha fallado la instalación
B, que I ia fallado el enlace entre A y B o que se ha perdido el mensaje de B.
La instalación A puede tratar de distinguir entre una falla de enlace y una de instalación
enviando a B un mensaje, ‘‘Está usted bien?’ por otra ruta (si existe). Como no se sabe por
adelantado cuánto tardará en llegar el mensaje de A a B y en volver, se debe usar el esquema
del tiempo límite. En el momento en que A envía el mensaje ‘¿Está usted bien?’ especifica un
intervalo de tiempo durante el cual está dispuesta a esperar una respuesta de B. Si A recibe el
mensaje de respuesta en ese intervalo puede llegar a la conclusión de que B está lista; sin
embargo, si no recibe en ese intervalo, A puede llegar a la conclusión de que al menos ha
ocurrido una de las situaciones siguientes:
l. Ha fallado la instalación B.
2.No funciona el enlace directo (si existe) entre A y B.
3. No funciona la ruta alternativa entre A y B.
140
Implementación
de
remoto
un shell
”..
4. Se ha perdido el mensaje.
No obstante, la instalación A no puede decidir cuál es la queha ocurrido (o cuáles).
Reconfiguración. Si la instalación A ha descubierto, que ha ocurrido una falla, entonces
se debe iniciar un procedimiento que permita al sistema reconfigurar y continuar su modo
normal de funcionamiento.
1
Si ha fallado un enlace directo entre A y B, ésta información se debe difundir a todas las
instalaciones del sistema, para que las tablas de encaminamiento puedanactualizarse.
'
Si se creeque
ha fallado una instalación, se ledebe
notificar acadaunade
las
instalaciones del sistema paraque ya no intenten usar los servicios dedicha instalación.
Nótese que la falla puede ser en una instalación que sirve de coordinador central de alguna
actividad, por lo queen éste caso se requiere la elección deunnuevo coordinador. Si la
instalación que falla es parte de un anillo lógico, hay que construir uno nuevo.
Recuperacidn despues de fallas. Después de reparar una instalación o enlace fallido
debe integrarse al sistema gradualmente y sin brusquedades.
Si ha fallado un enlace entre A y B, o bien han fallado las instalaciones A o 6 ,se debe
notificar al sistema.
ACUERDOS
Para que un sistema sea confiable se necesita un mqcanismo que permita a un conjunto de
procesos ponerse de acuerdo en un Valot'común. Existen varias razones por las cuales es
posible queno se logre este cuerdo. Enprimer lugar, elmediodecomunicaciónpuede
presentar fallas, produciendomensajes alterados o perdiéndolos. Segundo, los procesos
pueden tenererrores, comportándose demanera imprevisible.
Este problema ha sido expresado como el problema de los generales bizantinos. Varias
divisiones del ejército bizantino, cada una con su propio general, rodean un campamento del
enemigo. Los generales bizantinos deben llegar a un acuerdo sobre si deben atacar o no, al
amanecer. Es crucial que estén de acuerdo,ya que el ataque de sólo algunas de las divisiones
sería rechazado.Las divisiones están dispersas geográficamente, y los generales sólo se
pueden comunicar entre ellos por medio de mensajeros que corren de un campamento a otro.
Hay por lo menos dos razones por las cuales es posible que los generales no lleguen a un
acuerdo:
l . Los mensajeros pueden ser capturados por el enemigo: esta situación corresponde a
una situación poco confiable.
2. Puede haber generales traidores; esta situación corresponde a los procesos con fallas
en un sistema de computación.
141
Capítulo 4
Comunicaciones poco confiables. Supóngase que, si los procesos fallan, lo hacen de
m?.:-!xa limpia, y queelmediode
comunicacioneses poco confiable. Supóngase queel
proceso Pi en la instalación A, que ha enviado un mensaje al proceso Pi de la instalación 6 ,
necesita saber siPj ha recibido el mensaje para decidircomo continuar sus cálculos. Por
ejemplo Pi, puede decidir calcular una función S si Pj ha recibido su mensaje, o una función F
si P, no lo ha recibido (por alguna falla del equipo).
Para detectar fallas se puede emplear un esquema de tiempo limife. Cuando Pi envía un
mensaje, también especifica un intervalo de tiempo durante el cuál está dispuesto a esperar
un mensaje de confirmación de Pj. Cuando Pj recibe el mensaje, envía de inmediato una
confirmación a Pi; si éste la recibe dentro del intervalo de tiempo especificado puede suponer
con seguridad que Pj ha recibido su mensaje. Sin embargo, si vence el tiempo límite, Pi
necesita volver a transmitir su mensaje y esperar una confirmación. Este proceso continúa
hasta que Pi reciba un mensaje de confirmación o el sistema le notifique que la instalación 6
no está disponible. En el primer caso se calculará S; en el segundo, se calculará F. Observe
que, si son las únicas alternativas viables, Pi deberá esperar hasta que se le notifique una de
las dos.
ha recibidos su mensajn de
Supóngase ahora que Pi también necesita sabersiPi
confirmación para que pueda decidir cómo proceder con sus cálculos. Por ejemplo, Pj querrá
calcular S únicamente si está seguro de que Pi recibió su confirmación. En otras palabras, Pi y
Pj calcularán S si y sólo si están de acuerdoy, si se presenta una falla, no será posible
lograrlo. Concretamente, no es posible que Pi y Pj lleguen a un acuerdo total sus estados
respectivos en un entorno distribuido.
I
Procesos con fallas.Supóngase que el medio de comunicaciones es confiable, pero que
los procesos pueden fallar de manera imprevisible. Considérese un sistema de n procesos, en
el cuál no hay más de m que tengan fallas. Supóngase además que cada proceso Pi tiene un
valor privado Vi y se desea construir un algoritmo que permita que cada proceso Pi sin fallas
construya un vector Xi = (Ai,,, Ai,2 ,..., Ai,,) tal que
I
1. Si Pi es un proceso sin fallas, entonces Ai,j = Vj.
2. Si tanto Pi como Pj son procesos sin fallas, entonces Xi = Xi.
Existen varias soluciones para este problema, que es el de los generales bizantinos, y todas
comparten las mismas propiedades:
1. Sólo puede elaborarse un algoritmo correcto si n 2. 3 , m + l .
2. La demora, en el peor caso, para llegar a un acuerdo es proporcional a m + l demoras
producidas por el paso de mensajes.
3. El número de mensajes requeridos para llegar a un acuerdoes muy grande. Ningún
proceso es confiable, por lo que todos los procesos deben recopilar toda la información y
tomar sus propias decisiones.
I
En vez de presentar una solución general, lo cuál sería bastante complicado, se presenta
un algoritmo para el caso donde m = l y n=4. El algoritmo requiere dos rondas de intercambio
142
Implcmentación deremoto
un shell
Sistemas oDerativos distribuidos
de información:
1. Cada proceso envíasu valor privado a los otros tres procesos.
2. Cada proceso envía alos demás la información que ha obtenido en la primera ronda.
Unprocesocon fallas puedenegarsea enviar mensajes. En este caso, un proceso sin
fallas puede elegir un valor arbitrario y simular que esevalor fue enviado por eseproceso.
Una vez quese completan las dos rondas, un procesosin fallas Pi puede construir su vector
Xi = (Ai,,, Ai,*, Ai,J,Ai,J de la manerasiguiente:
1
1. Ai,i = Vi.
2. Para j#i, si concuerdan por lo menos dos de los tres valores notificados sobre el proceso
Pi (en las dos rondas deintercambio), entonces se utiliza el valor mayoritario para asignar
el valor de Ai,i; de lo contrario, se utiliza un valor por omisión (por ejemplo, nulo) como
valor de Ai,j.
ALGORITMOS DE ELECCIÓN
Como se señaló anteriormente muchos de los algoritmos distribuidos emplean un proceso
coordinadorque realiza funcionesnecesariaspara los demásprocesos del sistema. Estas
funciones incluyen aplicar la exclusión mutua,mantener un grafo local deesperaspara la
detección de bloqueos mutuos, reemplazar
un testigo perdido o controlar un dispositivo de
entrada o salida en el sistema. Si el proceso coordinador falla por culpa de una falla de la
instalación donde reside, la única forma de que el sistema continúe
la ejecución es reiniciar
una nueva copia del coordinador en otra instalación. A los algoritmos que determinan dónde
se debe reiniciar la nueva copiadel coordinador se les llama algoritmos de elección.
Los algoritmos de elección danporsentadoque
existe un númerode prioridad Único
asociado a cada proceso activo en el sistema. Para tacilitar la notación suponemos que el
número de prioridad del proceso Pi es i, y para simplificar el análisis se supondrá que existe
una correspondencia uno a unoentre procesos e instalaciones, por lo que se referirá a ambos
como procesos. El coordinador siempre es el proceso con mayor número de prioridad; así, al
fallar un coordinador, el algoritmo debe elegir elproceso activo conmayornúmerode
prioridad. Hayque enviar este númeroacadaunode
los procesos activos en el sistema;
además, el algoritmo debe
proporcionar
un mecanismo para
que
un
nuevo
proceso
recuperado identifique al coordinador vigente.
1
En esta sección se presentan dos interesantes ejemplos de algoritmos de elección para dos
configuraciones distintas de sistemas distribuidos. El primer algoritmo puede aplicarse a
sistemas donde cada proceso puede
enviar un mensaje a todos los demás procesos en el
sistema. El segundo algoritmo se aplica en sistemas organizados como anillo (lógico o físico).
Ambos algoritmos requierenn2mensajesparauna
elección, donde n es elnúmero de
procesos en el sistema. Se supone que un proceso que ha fallado sabe, al recuperarse, que
Universidad
Autónoma
143
Capitulo 4
se ha presentado la falla y, por tanto, emprende las acciones
conjunto de procesos activos.
convenientes para reunirse al
€1 a~gOfifrl70del grandu//Ón. Supóngase que el proceso Pi envía una solicitud a la que
no responde el coordinador en el intervalo de tiempo T. En esta situación se supone que ha
fallado el coordinador y Pi trata de proclamarse como nuevo coordinador. Esta tarea se logra
mediante el siguiente algoritmo.
El proceso Pi envía un mensaje de elección a todos los procesos con mayor número de
prioridad y durante un intervalo de tiempo T espera una respuesta de cualquiera de estos
procesos.
Si no se recibe alguna respuesta en el intervaloT,se supone que han fallado totius los
procesos con números mayores que i y Pi se elige como nuevo coordinador. El proceso Pi
reinicia una nueva copia del coordinador y envía un mensaje para informar a todos los demás
procesos con prioridades menores que i que Pi es el nuevo coordinador.
Sin embargo, si se recibe una respuesta, Pi inicia un intervalo de tiempo T', durante el cual
espera recibir un mensaje que le informe que se ha elegido un proceso con mayor número de
prioridad. (Algún otro proceso se está eligiendo como coordinador y debe notificar los
resultados en el período T'). Si no se recibe ningOn mensaje en ese intervalo T', se supone
que el proceso con mayor número ha fallado y el proceso Pi debe reiniciar el algoritmo.
Si Pi no es el coordinador, entonces, en cualquier momento de su ejecución, Pi puede
recibir uno cle los siguientes mensajes del proceso Pj: '
1. Pi es el nuevo coordinador o>¡). El proceso Pi, a su vez, almacena esta información.
2. Pj inició una elección U<¡). El proceso Pi envía una respuesta a Pi e inicia su propio
algoritmo de elección, siempre y cuando Pi no haya iniciado aún dicha elección.
El proceso que completa su algoritmo tiene el mayor número de prioridad y se elige como
coordinador. Ya ha enviado sunúmero a todoslos procesos activos con número menor. AI
recuperarse un proceso fallido, comienza de inmediato la ejecución del mismo algoritmo. Si no
hay proc;?sos activos con número mayor, el proceso recuperado obliga a todos los procesos
con núrr ero menor que le permitan ser el coordinador, aunque ya exista un coordinador activo
con número menor. Por esto, a este algoritmo se le denomina aCgoritmo del grandullón.
En un algoritmo que consta de los procesos PI a Pd, se tienen las siguientes operaciones:
1. Todos los procesos están activos; P4 es el proceso coordinador.
2. PI y P4 fallan. P2 determina que P4 ha falladoal enviar una solicitud que no ha sido
respondida en el intervalo T, e inicia su algoritmo de elección enviando una solicitud ;IiT3.
3. P3 recibe la solicitud, responde a P2e inicia su propio algoritmo enviando una solicitud a
p4.
4. P2 recibe la respuesta de P3y comienza a esperar durante el intervalo T'.
5. P4 no responde en el intervalo T, por lo que P3se elige como nuevo coordinador y envía
el número 3 a P2 y PI (que PI no recibe, ya que ha fallacjo).
6. Más tarde, cuando PI se recupera envía una solicitud d& elección a Pz, P3y P4.
144
.
__.-
I
un shell
IyL__x..__.__~""
"
"
.
7. P2 y P3 responden y comienzan sus propios algoritmos de elección. P3 será elegido
nuevamente, utilizando los mismos procesos que antes.
8. Por último, P4 se recupera y notifica a PI, P2 y P3que es el coordinador actual. (P4 no
envía solicitudes de elección, ya que es el proceso con mayor número en el sistema).
Un algoritmo de anillo. El algoritmo
de
anillo
supone
que
los enlaces son
unidireccionales y que los procesosenvían sus mensajesa los vecinosque tienen a la
derecha. La principal estructura de datos queutiliza el algoritmo es la lista de procesos activos,
que contiene los números de prioridad de tcdos los procesos activos en el sistema al terminar
el algoritmo; cada proceso mantiene su propia lista de procesos activos. El algoritmo funciona
de la manera siguiente:
1. Sielproceso Pi detecta una falla del coordinador, creaunanueva lista de procesos
activos, vacíaen un principio. Luego envía unmensaje elección(¡) al vecinode su
derecha y agregael número y asu lista de procesosactivos.
2. Si Pi recibe un mensaje elección(j) del proceso a su izquierda, debe responder de una de
las tres formas siguientes:
a) Si es el primer mensaje de elección que ha visto o enviado, Pi crea una nueva lista de
procesos activos con los números i y j, y luego env a el mensaje elección(¡) seguido por el
mensaje elección(j).
b) Si i#j (es decir, el mensaje recibido no contiene el número de Pi), entonces Pi añade j a
su lista de procesos activos y pasa el mensaje asu vecino de la derecha.
c) Si i = j (es decir, Pi recibe el mensaje elección(i)), entonces la lista de procesos activos
los procesos activos enel sistema. El
para Pi contieneahora los númerosdetodos
proceso Pi puede entonces determinar el número mayor de la lista de procesos activos
para identificar el nuevo procesocoordinador.
i
Este algoritmo no especifica cómo un proceso en recuperación determina el número del
proceso coordinador activo. Una solución sería requerir que un proceso en recuperaciónenvíe
un mensaje de consulta que se transmita por el anillo hasta el coordinadoractivo, el cual envía
una respuesta que contienesu número.
SISTEMAS DE ARCHIVOS DISTRIBUIDOS
Unsistemadearchivosdistribuido
(SAD) es una implantación distribuida del clásico
modelodesistemasde
archivos de tiempocompartido, donde varios usuarios comparten
archivos y recursos de almacenamiento. El propósito de un SAD es apoyar el mismo tipo de
compartición cuando los archivos están dispersos físicamente en varias instalaciones de un
sistema distribuido.
145
Capítulo 4
ANTECE DENTES
Un sistema distribuido es un conjunto de máquinas débilmente acopladas, interconectadas
por una redde
comunicaciones. Se utilizará el término mdquina para representar una
computadora central o una estación de trabajo. Desde el punto de vista deuna máquina
específica en un sistema distribuido, las demás máquinas y los recursos son remotos, mientras
que los recursos propios de la máquina son locales
Se dice que un sistema de archivos ofrece servicios de archivos a clientes. Una interface
con el cliente para el servicio de archivo se forma con un conjunto de operaciones de archivo
primitivas, como crear, eliminar, leer o escribir un archivo. El principal componente del
de
hardware controlado por
el
servicio de archivos es un conjunto dedispositivos
almBsenamiento secundario (generalmente discos magnéticos), en los cuales se almacenan
los archivos y de donde se recuperan según las necesidades de los clientes.
Un SAD es un sistema de archivos
cuyos
clientes, servidores y dispositivos de
almacenamiento están dispersos en las máquinas de, un sistemadistribuido; por tanto, las
actividades de servicio tienen que efectuarse a lo largo de la red, y en vez de un sólo depósito
de datos centralizado, existen múltiples dispositivos independientes de almacenamiento. Como
se verá más adelante, la configuración y la implantación de un SAD pueden variar. En algunas
configuraciones, los servidores se ejecutan en m3quinas dedicadas; en otras, una máquina
puede ser un servidor o un cliente. El SAD puede implantarse como parte deun sistema
operativo distribuido, o bien como una capa de software cuya tarea es administrar la
comunicación entre los sistemas operativos y los sistemas de archivos convencionales. Las
características distintivasde un SAD sonlamultiplicidad
y la autonomía de los clientes y
servidores en el sistema.
Enuna situación ideal, unSAD debe parecer a susclientes un sistema de archivos
convencional, centralizado. La multiplicidad y dispersión de susservidores y dispositivos de
almacenamiento deben ser transparentes; es decir, la interfaz de un SAD con el cliente no
debe hacer distinciones entre los archivos remotos y locales. Depende del SAD localizar los
archivos y hacer los arreglos necesarios para la transferencia de datos. Un SAD transparente
facilita la movilidad del cliente, llevando el entorno del usuario (es decir, su directorio particular)
a doncs se conecte.
La medida del rendimiento más importante en un SAD es la cantidad de tiempo neces- ia
para satisfacer lassolicitudes
de servicio. En los sistemas convencionales, este tiempo
consiste en el tiempo de acceso a disco y un poco de tiempo de procesamiento de la UCP. Sin
embargo, enun SAD el acceso remoto cuenta además con tiempo adicional debido a la
estructura distribuida, que incluye el tiempo necesario para erhtregar la solicitud a un servidor y
también el tiempo para entregar la respuesta al cliente atravesando la red. En cada dirección,
además de la transferencia de información, existe tiempo adicional de la CPU para el manr,io
del software del protocolo de comunicaciones. El rendimiento de un SAD puede considerarse
el rendimiento enun
SAD ideal
;a
como otro aspecto de su transparencia; esdecir,
equiparable al de un sistema de archivos convencional.
146
Implemer~taciónde un shell remoto
I
"
La principal característica quedistingueaun
SAD es que administra un conjuntode
dispositivos de almacenamiento dispersos, y el espacio global de almacenamiento que
administra puede estar compuesto porvarios
espaciosmás
pequeños, diferentes y con
ubicación remota. Usualmente hay una
correspondencia
entre estos
espacios
de
almacenamiento y los conjuntos de archivos. S e utilizará el término unidad componente para
denotar
el
menor conjunto de archivos que puede
almacenarse
en
una
máquina,
independientemente de otras unidades. Todos los archivos que pertenecen a la misma unidad
componente deben residir en una misma ubi'cación.
NOMlNAClbN Y TRANSPARENCIA
La nominaci6n es unacorrespondencia entreobjetos lógicos y físicos. Por ejemplo, los
usuarios tratan con objetos de datos lógicos representados por nombres de archivos, mientras
que el sistema manipula bloques de datos físicos almacenados en las pistas de los discos.
Generalmente, un usuario se refiere a un archivo utilizando un nombre, el cual se transforma
en un identificador numérico de bajo nivel, que a su vez se corresponde con bloques en disco.
Esta correspondencia multinivel ofrece a los usuarios Id abstracción de un archivo, que oculta
los detalles de cómo y dónde se almacena el archivo en disco.
E n un S A D transparente se agrega una nueva dimensión a la abstracción: la ocultación de
la ubicación del archivo en lared. E n un sistema de archivos convencional,la función de
nominación produce como resultado unintervalo compuesto por direcciones en disco; en un
S A D , este intervalo crecepara incluir la máquina específica en cuyodisco se almacena el
archivo. Si se extiendeun pocomás eltratamiento de los archivos como abstracciones, se
llega a la posibilidad de réplicas de archivos. Dado un nombre de archivo, la correspondencia
devuelve unconjunto de posiciones de las réplicas de este archivo. E n esta abstracción se
ocultan tanto la existencia de copias como su ubicación.
Estructuras de nominación. Existen dos conceptos que hay que distinguir en relación
con la correspondencia de nombres en un SAD:
l.Transparencia en la ubicacidn. El nombre del archivo no revela ningún indicio sobre la
ubicación del almacenamiento físico del archivo.
Independencia de la ubicación. No es necesario modificar el nombre de unarchivo
cuando cambia su ubicación en el almacenamiento físico.
Ambas definiciones están relacionadas con elnivel de nominación antes mencionado, ya
que los archivos tienen nombres diferentes a niveles distintos (es decir, nombres en el nivel de
usuario e identificadores numéricos en elnivel
desistema). Unesquema de nominación
independiente de la ubicación es unacorrespondenciadinámica, ya que puede efectuar la
correspondencia entreelmismonombre
de archivo y varias ubicaciones en dos instantes
diferentes. Por tanto, la independencia de la ubicación es una propiedad más fuerte que la
transparencia.
En la práctica, la mayoría de los SAD ofrece una correspondencia estática, independiente
de la ubicación, para los nombres a nivel de usuario. Sin embargo, estos sistemas no apoyan
la migración de archivos; es decir, es imposible cambiar automáticamente la ubicación de un
archivo, por lo que el concepto de independencia de la ubicación es bastante irrelevante para
Universidad Autónoma Metropolitana. Unidad
lztapalapa
147
Capítulo 4
estos sistemas. Los archivos están permanentemente asociados a un conjunto específico de
bloques en disco; los discos pueden moverse a mano de una máquina a otra, pero la
migración de archivos representan una acción automática iniciada por el sistemaopera!ivo.
Sólo Andrew y algunos sistemas de archivos experimentales permiten la independencia de la
ubicación y la movilidad de archivos. El sistema Andrew admite la movilidad de archivos sobre
todo con fines administrativos. Un protocolo ofrece la migración de las unidades componentes
de Andrew para satisfacer solicitudes de alto nivel de los usuarios, sin cambiar los nombres a
nivel de usuario ni los nombres de bajo nivel de los archivos correspondientes.
Existen unos cuantos aspectos que pueden distinguir aún más entre transparencia estática
e independencia de la ubicación:
l. AI separar los datos de su ubicación, lo que representa la independencia de la ubicación,
se obtiene una mejor abstracción para !os archivos. Un nombre de archivo debe denotar
sus atributos más importantes: su contenido no su ubicación. Los archivos
independientes de la ubicación pueden conectarse como conectores lógicos de datos
que no están unidosa una ubicación de almacenamiento específica. Si sólo se pmrmite la
transparencia estática de la ubicación, el nombre de archivo aúndenota un conjunto
específico, aunque oculto, de bloques físicos en disco.
2. La transparencia estática de la ubicación proporciona a los usuarios una manera
adecuada de compartir datos, ya quepueden compartir archivos remotos con sólo
nombrarlos en una forma transparente a su ubicación, como si los archivos fuesen
locales. No obstante, es complicado compartir el espacio de almacenamiento, ya que los
nombres lógicos aúnestán unidos estáticamente a dispcsitivos de almacenamiento
físico. La independencia de la ubicación promueve la compartición del propio e.;pacio de
almacenamiento y de los objetos de datos. Cuando los archivos pueden moviliza! ‘.-e,el
espacio de almacenamiento de todo el sistema parece un solo recurso virtual. Un
beneficio de esta perspectiva es la posibilidad de equilibrar la utilización de disco en el
sistema.
3. La independencia de la ubicación separa la jerarquía de nombres de la jerarquía de los
dispositivos de almacenamiento y de la estructura entre computadoras. En cambio, si se
usa la transparencia estática de la ubicación, aunque los nombres sean transparentes,
se puede exhibir facilmente la correspondencia entre unidades componentes y
miquinas, ya que éstas están configuradas con un modelo similar al de la estructura de
nombres. Estopuede restringir,sin que sea necesario, la arquitectura del sistema y
entrar en conflicto con otros factores. Un ejemplo de una estructura dictaminada por la
jerarquía de nombres,que contradice las líneas maestras de centralización, es un
servidor a cargo de un directorio raíz.
’
Una vez que se ha completado la separación entre nombres y ubicaciones, varios clientes
pueden acceder a los archivos residentes en sistemasservidores remotos. Es mas, estos
clientes pueden estar sin disco y apoyarse en los servidorey para obtener todos sus archivos,
incluyendo el núcleo del sistema operativo; sin embargo, se necesitan protocolos especiales
para la secuencia de arranque. Considérese el problema de hacer llegar el nucleo a una
estación de trabajo sindisco. Como esta estacióndetrabajo
no tienen núcleo, no puede
utilizarel código del SAD para recuperar el núcleo; en cambio, se invoca un protocolo de
arranque especial, almacenado en memoriade sólo lectura (ROM) en el cliente, capaz de
recuperar un archivo especial (el núcleo o código de arranque) de un destino fijo. Una vez que
148
un shell
el núcleo se ha copiado y cargado a través de la red, el código del SAD es capaz de lograr la
disponibilidad de todos los demás archivos del sistema operativo. Son muchas las ventajas de
los clientes sin disco, incluyendo un costo menor (ya que no se ,necesita un disco en cada
máquina) y mayor facilidad (cuando tiene lugar una actualización del sistema operativo, sólo
hay que modificar la copia del servidor y no las de todos los clientes). La desventaja es la
complejidad adicional de los protocolos de arranque y las pérdidasenelrendimiento
procedentes del uso de una red envez de un disco local.
'
Esquemasde nominación. Hay tres enfoques principales para los esquemasde
más sencillo, los archivos se nombranconuna
nominaciónen un SAD. Enelenfoque
combinación del nombre de su anfitrión y su nombre local, lo que garantiza un nombre Único
dentro de todoel sistema. Por ejemplo, en Ibis, un archivo se identifica de manera única con el
nombre anfitri6n:nombre-local, donde nombre-local es una ruta semejante a las de UNIX. Este
esquema de nominación no es transparente ni independiente de la ubicación; no obstante,
puedenemplearse las mismas operaciones tanto para archivos remotoscomo locales. La
aisladas queson sistemas
estructura del SAD es un conjuntodeunidadescomponentes
enterosde archivos convencionales.En esteprimer enfoque, las unidadescomponentes
permanecen aisladas, aunque se ofrecenmedios para referirse a un archivo remoto.
El segundo enfoque, popularizado por el'Sistema de Archivos en Red
(NFS) de Sun, ofrece
una forma para unir directorios remotos a directorios locales, lo que da la apariencia de un
árbol de directorios coherente. Sólo se puede lograr el acceso transparente a los directorios
remotospreviamentemontados.Sepresenta
cierta integración de los componentespara
apoyar la compartición transparente, aunque es limitada y no uniforme, ya que cada máquina
puede unir distintos directorios remotos a su estructura. La estructura que resulta es versátil:
por lo general, un bosque de árboles UNlX con subárboles compartidos.
La integración total de los sistemas de archivos componentes se logra usando el tercer
enfoque,dondeuna
sola estructura de nombres global abarcatodos los archivos en el
sistema. Idealmente la estructura compuesta de sistemas de archivos debe ser isomorfa de la
estructura de un sistema de archivos convencional, pero, en la práctica, existen varios archivos
especiales (por ejemplo, los directorios binarios y los larchivos de dispositivos de UNIX) que
dificultan la consecución de este objetivo.
Un criterio importanteparaevaluar
las estructuras denominación es sucomplejidad
administrativa. La estructura más compleja y difícil de mantener es la NFS, ya que cualquier
directorio remoto puede unirse al árbol de directorios locales y la jerarquía resultante puede
estar poco estructurada. Un servidor que ya no está disponible tiene como efecto que tampoco
este disponible un conjunto arbitrario de directorios en distintas máquinas; además, se utiliza
un mecanismo de acreditación aparte para controlar qué máquina puede unir qué directorio a
su árbol.
Técnicas de implantación. Para implantar una nominación transparente se requiere un
mecanismo para la correspondencia entre un nombre de archivo y la ubicación asociada. Para
que esta correspondencia sea manejable, hay que agrupar conjuntos dearchivos en unidades
componentes,nopor
archivo. Estaagrupacióntambién
tiene fines administrativos. Los
sistemas semejantes a UNlX utilizan el árbol jerárquico de direcciones para proporcionar una
149
Capítulo 4
transformación de nombres a ubicaciones y para agrupar de forma recursiva los archivos en
directorios.
Para mejorar la disponibilidad de la información decorresponder,cia indispensable, se
pueden aplicar métodos como la replicación, memoria caché local, o ambos. Como ya se ha
visto, la independencia de la ubicación significa que lalcorrespondencia cambia con el t i e m y ;
por tanto, la replicación de la correspondencia imposibilita la actualización sencilla y
para superar este obstáculo es presentar
consistente de esta información. Unatécnica
identificadores d e archivos independientes de la ubicación de bajo nivel. Se efectúa una
transformación de los nombres de archivos a identificadores de archivo debajo nivel que
indican a que unidad componente pertenece ese archivo pero siguen siendo independientes
de la ubicación. Es posible replicar y colocar los identificadores en memoria cache, sin que
pierdan validez con la migración de unidades componentes. El precio inevitable que hay ,¡.re
pagar es un segundo nivel de transformación de unidades componentes a ubicaciones, el cual
requiere un mecanismo de actualización sencillo pero consistente. Si se implantan árboles de
directorios semejantes a UNIX, usando estos identificadores de bajo nivel independientes de la
ubicación, toda la estructura permanece invariable durante la migración de unidades
componentes; lo Único que cambiaes la correspondencia entre unidades componentes y
ubicaciones.
Una manera común para implantar estos identificadores de bajo nivel consiste en utilizarnombres estructurados, cadenas debits que generalmente tienen dos partes: la primera
identifica la unidad componente a la cual pertenece el archivo; la segunda identifica el archivo
específico dentro de la unidad. Puede h?ber variafitcs con más partes; sin embargo, lo que no
cambia en los nombres estructurados es que cada una de sus partes es única en todmomento, solamente respecto al contexto de las demás partes. Se puede tener siempre esta
exclusividad teniendo cuidado de no reutilizar un nombre Fue aún se usa, ai;-.; . ) ( l o una
cantidad suficiente de bits (este método se usa en Andrew), o usando una marca de tiempo
como una de las partes del nombre (lo que se hace en Apollo Domain). Otra manera d,.?
considerar esto consiste en tomar un sistema transparente a la ubicación, como Ibis, y añadirle
otro nivelde abstracción para producir un esquema de nominación independiente de la
ubicación.
SERVICIOS REMOTOS
Considérese un usuario que solicita el acceso a un archivoremoto. Suponiendo que se
localizó al servidor que antiene elarchivo mediante el esquema de nominación apropiado,
debe efectuarse la transferencia de datos para satisfacerla solicitud de acceso remoto del
usuario.
Una manera de lograr esta transferencia es a través del método de servicio remoto, con el
cual se entregan al servidor las solicitudes de acceso; la máquina servidora lleva a cabo dichos
accesos y los resultados se devuelven al usuario. Existe una correspondencia directa entre los
B C C ~ Y O Sy el tr5fico que va y viene del servidor. Las solicitudes de acceso se traducen a
-3
.,-,
mensajes para los servidores y susrespuestas se empaquetancomomensajes
que se
devuelven al usuario. Cada proceso es manejado por el servidor y ocasiona tráfico en la red;
por ejemplo, una lectura provoca el envío de un mensaje de solicitud al servidor y la respuesta
al usuario con los datos solicitados.
Se debe notar que se presenta una analogía directa entre los métodos de acceso a disco
en los sistemas de archivos convencionales y el método de servicio remoto .en un SAD. El
método de servicio remoto es análogo a efectuar un acceso a disco para cada solicitud de
acceso.
Unade las formas más comunes deservicioremoto
es el paradigmade
procedimientos remotos (RPC) que se analizará posteriormente.
llamada a
Es fácil implantar un sistemade archivosdistribuidos como un conjuntode clientes y
procesos demonios RPC. Los mensajes se dirigen al puerto SAD de su servidor donde se
efectuará una operación de archivo. El mensaje contiene la operación del disco que hay que
realizar, como puede ser leer, escribir, renombrar, eliminar o estado, correspondientes a las
los datos
llamadas al sistemanormalespara
archivos. El mensaje derespuestacontiene
resultado de la llamada, ejecutada por el proceso demonio SAD en nombre del cliente. Por
ejemplo, un mensaje puede contener una solicitud para transferir todo un archivo a un cliente,
o estar limitado a simples solicitudes de bloques; en el segundo caso, podrían necesitarse
varias llamadas deeste tipo para transferir todo un archivo.
MEMORIA CACHÉ
En los sistemas de archivos convencionales, el fundamento para la memoria caché es la
reducción de la E/S de disco (lo que aumenta el rendimiento), mientras que en un SAD el
objetivo es reducir el tráfico de la red.
Esquema básico. El concepto de memoria caché es sencillo: si los datos necesarios para
satisfacer la solicitud de acceso no se encuentran en la memoria caché, se trae una copia del
servidor al usuario y los accesos se llevan a cabo con la copia en memoria caché. La idea es
conservar allí los bloques de disco de acceso más reciente, para así manejar localmente los
accesos repetidos a la misma información y no aumentar el tráfico de la red. Se utiliza una
política de reemplazo (por ejemplo, la de utilización menos reciente) para limitar el tamaño de
la memoria caché. No existe correspondencia directa entre los accesos y el tráfico al servidor.
Los archivos se siguen identificando con una copia maestra residente en la máquina servidora,
pero hay copias de partes del archivo en memorias caché diferentes. Cuando se modifica una
reflejar en el archivo maestroparapreservar
la
deestas copias, los cambiossedeben
semántica de consistencia pertinente. El problema paramantener las copias consistentes
respecto al archivo maestro se denomina problema de consistencia de memoria caché y se
analizará más adelante.
La memoria caché representaun tema mucho más complejo que el servicio remoto, ya que
existen más variantes en cuanto a funcionalidad e implantación. La granularidad de los datos
enmemoriacachépuede
variar desdebloques de un archivo aun archivo completo. La
Universidad
Autónoma
151
’
mayoría de las vecesse colocanen memoria cachémás datos que losnecesariospara
satisfacer un acceso, para que así con los datos puedan atenderse varios accesos. El sistema
Andrew coloca archivos enteros enesta
memoria, pero noestádiseñadopara
manejar
archivos muy grandes, pues se requiereque
quepanen el archivo local del usuario. AI
aumentar el tamaño de la unidad de memoria caché, se incrementa la tasa de aciertos, pero
retrasa la transferencia real de datos y aumenta el potencial de problemas de consistencia, por
lo que, para seleccionar: la unidad de memoria.cach6, hay que considerar parámetros como la
unidad de transferencia de la red y la unidad de servicio del protocolo, si se utiliza una RPC.
La unidad de transferencia de la red (un paquete Ethernet) es aproximadamente 1.5 K B . , por
lo que hay que desensamblarlasunidadesde
datos en memoria caché al entregarlas, y
reensamblarlas en la recepción.
Y
Obviamente, el tamaño de bloque y el tamaño total de la memoria caché son importantes
en los esquemas para bloques en memoria saché. E n los sistemas semejantes a UNlX son
frecuentes los bloques con tamaño de 4 KB. u 8 KB..
E n el caso de memorias caché degrantamaño
(másdeun
megabyte) sonbuenos los
bloques grandes (más de 8 KB.); con memorias caché más pequeñas no son tan prácticos,
pues reducen el número de bloques en la memoria.
La memoria caché en disco tiene una granventaja
sobre la de memoria principal: la
confiabilidad. Si la memoria caché
se
conserva en un medio volátil, se pierden las
modificaciones a los datos si llega a ocurrir una falla; además, si los datos se conservan en
disco, siguen allí durante la recuperación y no es necesario cargarlos de nuevo. Por otra parte,
la utilización de la memoria principal tiene varias ventajas:
1.
2.
3.
4.
Permiten que las estaciones de trabajo no tengan disco.
E s mucho más rápido el acceso a datos en memoria principal que a disco.
La tendencia tecnológica actual es hacia memorias más grandes y baratas.
Las memorias caché del servidor (las que se utilizan para acelerar la E/S de disco) se
encontrarán en memoria principal sin importar dónde estén ubicadas las de los usuarios;
si también se emplea la memoria principal de la máquina del usuario, se puede construir
unsolomecanismode
memoria caché que pueda ser usado por los servidores y los
usuarios (como lo que se hace en el sistema Sprite).
Muchas de las implantaciones de acceso remoto pueden considerarse como híbridas de la
memoria caché y el servicio remoto. For ejemplo, en el caso de NFS y Locus, la implantación
está basada en el servicio remoto, pero se amplía con memoria caché para mejorarel
rendimiento. Por otra parte, la implantación de Sprite está basada en la memoria caché, pero
se adopta el método de servicio remoto en ciertas circunstancias.
Polífica de actualización. La política empleadapara escribir los bloquesde datos
modificados en la copia maestra del servidor tiene un efecto decisivo sobre la confiabilidad y el
rendimiento del sistema. La política más sencilla consiste en escribir los datos directamente en
el disco tanpronto como se coloquen en una memoria caché. La ventajade la escritura
directa es su confiabilidad, ya que se pierde poca información si un sistema cliente falla. Sin
embargo, está política requiere que cada acceso deescritura espere hasta que se envie la
152
remoto
un
de
información al servidor, lo que representa una escritura de escaso rendimiento. La memoria
caché con escritura directa equivale a usar el servicio remoto para accesos de
escritura y
explotar la memoria caché únicamente para
accesos de lectura. NFS proporciona el acceso de
escritura directa.
Otra política de escritura consiste en demorar las actualizaciones a la copia maestra; las
modificaciones se escriben en la memoria caché y más tarde se escriben directamente en el
servidor. Esta política presenta dos ventajas respecto a la escritura directa: primero, como las
escrituras son en memoria cache, estos
accesos terminan con mayor rapidez; segundo, en
ocasiones los datos se reescriben antes de enviarlos al servidor, situación en la cual nunca
presentan
hace falta escribirlos. Por desgracia los esquemas de escriturademorada
problemas de confiabilidad, yaque los datos no escritosse pierden si falla la máquina del
usuario.
Consistencia. Una máquina client: se enfrenta al'problema de decidir si una copia de
datosenmemoriacaché
local es consistente con la copiamaestra (y, por tanto, puede
usarse). Si la máquina cliente determina que sus datos en memoria caché están desfasados,
copia
ya nopuede servir para los accesos y hayque colocar en la memoriacachéuna
verificar la validez de los datosen
actualizada de los datos. Existen dosenfoquespara
memoria cache:
Enfoque iniciadopor el cliente. El cliente inicia una comprobaiion devalidez, en la cual se
pone en contacto con el servidor y comprueba si los datos locales son consistentes con la
copia maestra. La frecuencia de la comprobación devalidez es el punto clave de este enfoque
y determina la semántica de consistencia resultante. Puede variar, de una comprobaciónantes
de cada acceso, a una
verificación sólo la primera vez que se accede al archivo (al abrirlo
básicamente).Cada
acceso acopladoaunacomprobaciónde
validez sedemora,
en
comparación con un acceso atendido de inmediato por la memoria cache. Otra posibilidad es
iniciar la comprobacióna intervalos fijos regulares; con esto, lacomprobaciónde validez,
dependiendo de sufrecuencia, puede cargartanto a la red como al servidor.
Enfoque iniciado por el servidor. El servidor anota, para cada cliente, las partes de los
archivos que coloca en memoria caché, y cuando detecta una inconsistencia, debe reaccionar.
Una posible fuentede inconsistencias ocurre cuandodos clientes, que trabajan enmodos
conflictivos, colocan en memoria caché un archivo. Si se implanta la semántica de sesiones,
entonces,cuando
un servidor recibe una solicitud para cerrar un archivo queha
sido
modificado, debe reaccionarnotificando a los clientes que deben considerar comoinválidos los
y descartarlos. Los clientes que tienen abierto el archivo en ese
datosenmemoriacaché
momento descartan su copia alterminar la sesión; otros clientes la descartan de inmediato. En
la semántica de sesiones, el servidor no necesita ser informado de las aperturas de archivos
que ya se encuentran en memoria cache; su reacción se origina únicamente con el cierre de
una sesión de escritura y, por consiguiente, sólo se demora este tipo de sesión. En Andrew se
haimplantado la semánticade sesiones y seemplea un método iniciado por el servidor,
conocido como llamada derespuesta.
Por otra parte, si se implanta una semántica de consistencia más restrictiva, como la de
UNIX, el servidor debe interpretar un papel más activo. Hay que notificar al servidor cuando se
153
Capítulo 4
abre un archivo e indicar, con cada apertura, el modo (lectura o escritura). Suponiendo que se
da esta notificación, el servidor puede actuar cuando detecta que unarchivo
se abre
simultáneamente enmodos conflictivos, deshabilitando la memoria cachépara ese archivo
(como se hace en Sprite). E n realidad, al desactidar la memoria caché, se cambia a un modo
de trabajo por servicio remoto.
REPLICACIÓN DE ARCHIVOS
La replicación de archivos en máquinas diferentes es una redundancia útil para mejorar la
disponibilidad. La replicación en varias máquinas también pueden beneficiar el rendimiento, ya
que, al seleccionaruna réplica cercanapara atender una solicitud de acceso, eltiempo de
4
servicio es menor.
I
El requisito fundamental de un esquema de replicación es que las réplicas de un archivo
residan en máquinas independientes de las fallas; es decir, que la disponibilidad de una réplica
no se vea afectada por la disponibilidad de las demás. Este requisito obvio quiere decir que la
administraciónde réplicas es una actividad en la cual la ubicación es decisiva,puesdeben
existir mecanismos para colocarla réplica en una máquina concreta.
Es deseable ocultar a los usuarios los detalles de la replicación y esttarea del esquema de
nominación efectuar la correspondencia entre un nombre de archivo replicado y una réplica en
particular. La presencia de réplicas debe ser invisible para los niveles superiores, sin embargo,
hay que distinguir las réplicas con nombres diferentes en los niveles inferiores. Otro aspecto
de la transparencia consiste en proporcionar control de mayor nivel de las réplicas, que incluye
la determinación del grado de replicación y la colocación de las réplicas. E n ciertas
circunstancias es deseable exponer estos detalles a los usuarios; por ejemplo, Locus ofrece a
los usuarios y administradores del sistema mecanismos para controlar el esquema de
replicación.
El mayor problema relacionado con las réplicas es su actualización. Desde la perspectiva
del usuario,las réplicas de un archivo representan la mismaentidad
lógica, por lo que
cualquier actualización se debe reflejar en todas las demás réplicas. Específicamente,hay que
conservar la semántica de consistencia cuando se considera que los accesos a réplicas son
no es un factor
accesos virtuales al archivo lógico correspondiente. Si laconsistencia
primordial, puede sacrificarse en aras de la disponibilidad y el rendimiento; esto es una
encarnación del equilibrio fundamental en el área de tolerancia a fallas. La opción es preservar
la consistencia a toda costa, creando así la posibilidad de postergación indefinida, o sacrificar
la consistencia en alguna situación de fallas catastróficas para poder garantizar el progreso.
Locusempleaen
gran medida la replicación y sacrifica la consistencia en el caso de la
partición de la red para beneficio de la disponibilidad de archivos tanto para accesos de lectura
como de escritura.
154
lmplementación
remoto
shell un
de
nski
DISTRIBUTED OPERATING SYSTEMS
THE LOGICAL DESIGN
Addison-Wesley Publishing Company[1991]
Andrej
Págs. 4-8, 21-26.
I
SISTEMAS OPERATIVOS. CONCEPTOSFUNDAMENTALES
Addison-Wesley Iberoamericana[1994]
James L. Peterson
Peter B. Galvin
Págs. 462-466, 471-495, 499-512, 515-516.
I
CAPÍTULO 5
MODELO
f
CLIENTE-SERVIDOR
Y CONCURRENCIA
MODELO
CLIENTE-SERVIDOR
CONCURRENCIA
Y
9
[TOMADO Y ADAPTADO de ComerI5
,
Desde el punto de vista de una aplicación, TCP/IP, como la mayoria de los protocolos de
comunicacióndecomputadora,
únicamente proporciona mecanismosbásicosusadospara
transferir datos. E n particular, TCP/IP permite a unprogramador establecer comunicación
entre dos programas de aplicación y pasar datos de fda y vuelta. Así, se dice que TCPllP
proporciona comunicación pareja-a-pareja. Las aplicaciones pares pueden ejecutarse en la
misma máquina o en máquinas diferentes o distantes.
Aunque TCPllP especifica los detalles de como pasar datos entre un par de aplicaciones
comunicantes, no indica cuando o porque interactúan las aplicaciones pares y no específica
comodeberían los programadores organizartales programas de aplicación enun entorno
distribuido. E n la práctica, un método organizacional domina el uso de TCP/IP a tal punto que
casi todas las aplicaciones lo usan. El método es conocido como el paradigma clienteservidor. De hecho, lainteraccióncliente-servidor
ha venido a ser tanfundamental en los
sistemas de red pareja-a-pareja que forma la base para la mayor parte de comunicaciones de
computadora.
.
EL MODELO CLIENTE-SERVIDOR (MOTIVACIóN)
La motivaciónfundamental
para el paradigma cliente-servidor surge del problemade
rendezvous(encuentro).Para
entenderel
problema, hay que imaginar queun
humano
intenta iniciar dos programas en máquinas separadas y tiene que comunicarlas. También hay
que recordar que las computadoras operan a muchas órdenes de magnitud más rápido que los
seres humanos. Después de que el humano inicia el primer programa, éste inicia su ejecución
y envía un mensaje a su pareja. E n unos pocos milisegundos, determina que la pareja todavía
no existe, así que emite un mensaje de error y termina.Mientrastanto,el
humano iniciael
segundo programa. Desafortunadamente, cuando el segundo programa inicia su ejecución
encuentra que la pareja ya ha cesado su ejecución. Aún cuando los dos programas reintenten
comunicarse continuamente, cada uno de ellos puede ejecutarsetanrápidamente
que la
probabilidad de que los mensajes que envían uno a otro sean simultáneos, es baja.
El modelo cliente-servidor resuelve el problema de encuentro, afirmando que en cualquier
Capítulo 5
0
par
de
aplicaciones comunicantes, un lado debe iniciar
su
ejecución y esperar
(indefinidamente) para que el otro lado lo contacte. La solupión es importante porque TCP/IP
no responde asolicitudes de comunicación dellegada por sí mismo.
ComoTCP/IP no proporcionaalgúnmecanismo
que creeautomáticamenteprogramas
corriendo cuando llega un mensaje, un programa, debe esperar para aceptar la comunicación
antes de quellegue cualquier solicitud.
Asi, para asegurar que las computadoras están ya listas para comunicarse, la mayoria de
los administradores del sistema disponen que los programas decomunicación tienen que
iniciarse automáticamente cada vez que se carga el sistema operativo. Cada programa corre
siempre, esperando que llegue la siguiente solicitud para ofrecer su servicio.
TERMINOLOGíA Y CONCEPTOS
El paradigma cliente-servidor divide las aplicaciones decomunicaciónen
categorías, dependiendo de si la aplicación espera la comunicación o la inicia.
dos grandes
Clientes y servidores. El paradigma cliente-servidor usa la dirección de iniciación para
categorizar si un programa es uncliente o servidor.
En general, una aplicación que inicia la comunicación pareja-a-pareja es llamada cliente.
Los usuarios finales normalmenteinvocan un cliente cuandousan un servicio de red. La
mayoría de software cliente consiste de programas de aplicación convencional. Cada vez que
una aplicación cliente se ejecuta, contactaa un servidor,envía una solicitud y esperauna
respuesta. Cuando la respuesta llega, el cliente continúaprocesando.Frecuentemente los
clientes son más fáciles de construir que los servidores, y normalmente norequieren privilegios
especiales del sistema para operar.
En comparación, un servidor es cualquier programa que espera la llegada de una solicitud
de comunicación de el cliente. El servidor recibe una solicitud del cliente, llevando a cabo la
computación necesaria, y regresa el resultado al cliente.
Privilegios y complejidad. Como los servidoies frecuentementenecesitanacceder
datos, o puertosde un protocolo, que el sistema operativo protege, el software servidor
requiere privilegios del sistema especiales. Cuando un servidorse ejecuta con un privilegio
especial del sistema, debe ser tomado
con
cuidado
para
asegurar
que
no pase
inadvertidamente privilegios al cliente que lo usa. Por ejemplo, un servidor de archivos que
operacomo un programa privilegiado debe tener códigoque verifique si un archivo dado
puede ser accedido por un cliente dado. El servidor no puede contar con las verificaciones
usuales del sistema operativo porque su estado de privilegio las anularía.
Los servidores deben tener código que manejelos aspectos de:
lmplementación
de
160
_".."
'
.
..
u n shell remoto
.-..
".
Modelo cliente-servidor v concurrencia
1. Autenticidad. Verificar la identidad de el cliente.
2. Autorización. Determinar si a un cliente dado le es permitido acceder el servicio que el
servidor proporciona.
3. Seguridad de los datos. Garantizar que los datos no sean intencionalmente reveladoso
comprometidos.
4. Privacidad. Información guardada acerca deun individuo no autorizado.
5. Protección. Garantizar que las aplicaciones de la red no puedan abusar de los recursos
del sistema.
Los servidores que llevan a cabo computación intensa o manejo de grandes volúmenes de
datos operan más eficientemente si manipulan solicitudes concurrentemente. La combinación
de privilegios especiales y de operaciones concurrentes normalmente hace a los servidores
más eficientes de diseñar e implementarque a los clientes.
SOFTWARE CLIENTE ESTANDAR CONTRANO ESTÁNDAR
Hay dos grandes clases de programas de aplicación cliente: aquellos que involucran
servicios normalizados TCP/IP(pe.correoelectrónico)
y aquellcs que involucran servicios
definidos por el lugar (pe. una base de datos de una institución privada). Los servicios de
aplicación normalizados consisten de aquellos servicios definidos por TCP/IPbien conocidos,
cuyos identificadores de puerto de protocolo son reconocidos universalmente; se considerarán
aquí todos aquellos cuyos servicios de aplicación están definidos localmente o servicios de
aplicación no normalizados.
La diferencia entre servicios normalizados y otroses solamenteimportantecuando
la
comunicación es exterior al ambiente local. Dentro de un ambiente dado, los administradores
del sistema normalmente definen los nombres de servicio de tal forma que los usuarios no
puedan distinguir entre servicio local y normalizado. Los programadores que construyen las
aplicaciones de red que serán usadas en otros lugares deben comprender la diferencia, no
obstante, se deberá ser cuidadosopara evitar ladependenciaen
servicios que soloson
válidos localmente.
Aunque TCPAP define muchos protocolos de aplicación estándar, la mayoríade
los
vendedores de computadoras comerciales proporcionan solamente unos cuantos programas
de aplicación cliente normalizados con su software TCPAP. Por ejemplo, el software TCP/IP
normalmente incluye un cliente de terminal remota que usa el protocolo normalizado TELNET
para conexión remota,un cliente de correo electrónico que usa el protocolo normalizado SMTP
para transferir correo electrónico a un sistema remoto, y un cliente de transferencia de archivos
que usa elprotocolo normalizado FTP para transferir archivos entre dos máquinas.
Porsupuesto,muchasorganizacionesconstruyen
aplicaciones quehabitualmenteusan
TCPAP para comunicarse. Habitualmente el rango de lbs aplicaciones no normalizadas va de
lo simple a lo complejo, e incluye serviciosdiversos
como transmisión de imágenes y
161
Capitulo 5
0
vidcocotrlcrerlcia, trallstiusibll d e voz, coleccih de dalos relrlotos et) tierrlpo real, slsleltm d c
reservación de línea de hotel y otros servicios, acceso a bases de datosdistribuidas, etc.
Paramefrización de clientes. Algúnsoftwarede cliente proporcionamásgeneralidad
cliente permiteal usuario especificar tanto la
que otros. En particular, algúnsoftwarede
máquina remota en la cual opera el servidor como el número de puerto del protocolo en el
cual el servidor está a la escucha.
Conceptualmente, el software quepermite a un usuario especificar el número de puerto del
protocolo tiene másparámetrosdeentradaque
otro sbftware, y se usa el término cliente
parametrizado completamente para designarlo. Muchas implementaciones del cliente
TELNET interpretan un segundo
argumento
opcional, como
número
de
puerto. Para
especificar solamente una máquina remota, el usuario proporciona el nombre de la máquina
remota:
telnet nombre-de-la-maquina
Dado sólo un nombre de máquina, el programa telnet usa el bien conocido puerto para el
servicio TELNET. Para especificar ambos, una máquina remota y un puerto en ésa máquina,
el usuario especifica tanto el nombre de la máquinacomo el del puerto:
telnet nombre-de-la-maquína
puerto
No todos los vendedores proporcionan una parametrización completa para su software de
aplicación cliente. Por eso, en algunos sistemas, pudiera ser difícil o imposible usar cualquier
número de puerto, además del puerto oficial TELNET del vendedor o escribir un software de
cliente TELNET nuevo que acepte un argumento de puerto y lo use. Por supuesto, cuando se
construye el softwarecliente, es recomendada la parametrización completa.
La parametrización completa es especialmentd útil cuando se prueba un cliente o servidor
nuevos, porque ello permite verificar el proceso de independencia del softwareexistente ya en
uso. Por ejemplo, un programador puede construir en par cliente-servidor TELNET, invocarlo
con puertos de protocolo no normalizados, y proceder a probar el software sin disturbio de los
servicios normalizados. Otros usuarios pueden continuar accediendoel servicio TELNET
antiguo sin interferir durante la prueba.
Servidores orientados a conexión contra orientados a no conexión. Cuando los
programadoresdiseñansoftware
cliente-servidor, debendeescoger
entre dos tipos de
interacción: un tipo orientado aconexión o un tipo orientado ano conexión. Los tipos de
los dos protocolos principales de transporte que
interacción correspondendirectamentea
proporciona la serie de protocolos TCPAP. Si el cliente y el gemidor comunicantes usan UDP,
la interacción es orientada a no conexión;si usan TCP la interacción es orientada a conexión.
Desde el punto de vista de la aplicación del programador, la diferencia entre interacciones
orientadas o no a conexión es crítica porque determina el nivel de integridad que el sistema
subyacente proporciona. TCP proporciona la integridad necesaria para comunicarse a través
7
162
"
lmplementación
de
un shell remoto
-~
de una intered. Verifica que los datos lleguen y los retransmite automáticamente en caso de
que no lleguen. Calcula una verificación sobre los datos y garantiza que no fueron corrompidos
durante la transmisión. Utiliza una secuencia de númerbs para asegurarque los datos lleguen
en orden, y elimina automáticamente los paquetes duplicados. Proporciona control de flujo
para asegurar que el emisor no transmita más rápido de lo que el receptor pueda consumir.
Finalmente informatanto al cliente como al servidor si la red subyacente llega a ser inoperable
por alguna razón.
En contraste los clientes y servidores que usan UDP no tienen garantía alguna acerca de la
integridad de los datos liberados. Cuando algún cliente envía alguna solicitud, la solicitud se
puede perder, duplicar, degradar o llegar fuera de orden. Los programas de aplicación cliente
y/o servidor deben tomar las acciones apropiadas paradetectar y corregir tales errores.
*
UDP puede ser engañosoporqueproporciona un mejor esfuerzo de entrega; UDP no
introduce errores (ello dependeúnicamentede lacapaIP internet subyacenteque entrega
paquetes). La entregade IP, depende del hardwaresubyacentede
las redes y de; las
pasarelas intermedias. Desde el puntode vista del programador, la consecuencia de usar
UDP, es que trabaja bien si la internet subyacente trabaja bien.
Por ejemplo, UDP trabaja bien enunambiente
local porque los errores de integridad
ocurren rara vez en un ambiente local. Los errores usualmente surgen solamente cuando la
comunicación se expande a unaintered de área ancha.
Los programadores algunas veces cometen el error de escoger transporte orientado a no
y entoncespruebanel
conexión (es decir, UDP) construyendouna aplicación quelausa,
software de aplicación sólo en una red de área local. Como ésta red, rara vez o nunca retarda
los paquetes, los deja caer, o los entrega fuera de orden, esto hace parecer que la aplicación
trabaja bien, sin embargo, siel mismo software es usadoa través deuna intered de área
ancha, produce fallas o resultados incorrectos.
Los principiantes, así como los profesionistas más experimentados, prefieren usar la
interconexión de tipo orientado a conexión. Un protocolo orientado a conexión hace que la
programación sea más simple, y liberaal programador de la responsabilidad de detectar y
corregir errores. De hecho, agregar integridad a un protocolo de mensajes intered orientado a
no conexión como UDPes una tarea nada trivial que normalmente requiere de experiencia
considerable en el diseño deprotocolos.
Generalmente los programas deaplicación usan UDP si:
(1) El protocolo de aplicación específica que debe ser usado UDP, (presumiblemente, el
protocolo de aplicación ha sido diseñado para manipular la integridad y liberar errores); (2) el
protocolo de aplicación cuenta con un hardware de difusión o de difusión restringida, o (3) la
aplicación no puede tolerar gastos fuertes o los retardos requeridos por los circuitos virtuales
TCP.
Servidores sin estadocontraservidoresconestado.
La información que un
servidor mantiene acerca de el estado de las interacciones actuales con clientes es llamada
163
CaDítulo 5
I
información deestado. Los servidores que no 'guardan alguna información son llamados
servidores sin estado; los otros son llamados servidores con estado.
El deseo de eficiencia motiva a los diseñadores a guardar la información de estado en los
servidores. Guardando una pequeña cantidad de información en un servidor se puede reducir
eltamaño de los mensajes que elcliente y elservidorintercambian y esto puede permitirle
también al servidor responder a las solicitudes rápidamente. Esencialmente, la información de
y calcular una
estado permite a un servidorrecordar lo que elclientesolicitópreviamente
repuesta incremental encadanueva
solicitud que llega. E n contraste, la motivación de no
guardar la información de estado yace en la integridad del protocolo: la información de estado
en un servidor puede llegar a ser incorrectasi los mensajes sonperdidos, duplicados o
entregados fuera de secuencia, o si la computadora cliente falla y se vuelve a cargar . Si el
servidor usa información de estado incorrecta cuando calcula una respuesta, podria responder
incorrectamente.
€jemp/o de un sewidor de archivos con estado. Un ejemplo ayudará a explicar la
diferencia entre servidores con y sin estado. Considérese un servidor de archivos que permita
a los clientes acceder remotamente la información guardada en los archivos de un disco local.
El servidor opera como un programa de aplicación, espera a que un cliente haga contacto con
éI sobre la red, el cliente envía uno de dos'tipos de solicitud, es decir, ya sea una solicitud para
extraer datos de un archivo especificado o bien una solicitud paraalmacenar datos en un
archivo específico. El servidor lleva a cabo la solicitud y responde al cliente.
Por un lado, si el servidor de archivos es sin estado no mantiene información acerca de las
interacciones. Cada solicitud de un cliente para extraer datos de un archivo debe especificar el
nombre completo del archivo (éste podría ser muy grande), una posición en el archivo desde la
cual los datos deberánser extraídos, y el número de bytes a extraer.Similarmente cada
solicitud hacia elservidor para almacenar datos enun archivo deberá contener el nombre
completo del archivo, una posición en el
archivo
en la cual los datos deberán ser
almacenados, y los datos a almacenar.
Por otro lado, si el servidor de archivos mantiene la información de estado de sus clientes,
puede eliminar la necesidad de pasar los nombres de archivo en cada solicitud. El servidor
mantiene una tabla que contiene la información de estado acerca del archivo que está siendo
accedido actualmente. L a Tabla Imuestra un posible arreglo de la información de estado.
Cuando un cliente abre porprimera vez un archivo, ,el servidor agrega una entrada a su
tabla de estado, que contiene elnombre del archivo, un rnanejador (unentero usado para
identificar al archivo) y una posición actual en el archivo (inicialmente cero). El servidor envía
entonces un manejador de regreso al cliente para usar en solicitudes subsecuentes. Cada vez
que el cliente extrae datos adicionales de el archivo, envía un pequeño mensaje que incluye el
manejador. El servidor usa el manejador para buscar el nombre de archivo y la posición actual
en su tabla de estado, incrementa la posición de archivo en ésta tabla, así la siguiente solicitud
de elclienteextraerá
nuevosdatos.
De ésta forma, elcliente
puede enviarsolicitudes
repetidas para moverse a través de elarchivo entero, cuando elclientetermina de usar un
archivo, envíaunmensaje
informandoalservidor
que elarchivoya
no será utilizado, en
respuesta elservidorelimina
la información de latabla deestado. E n tanto que todos los
164
Implementación
remoto
shell
de un
mensajes viajen confiablemente entre el cliente
interacción más eficiente.
y el servidor, un diseño con estado hace la
I
Si bien la información de estado puede mejorar la eficiencia, también puede hacer difícil o
casi imposible el mantenimiento de duplicaciones, retardos o entregas de mensajes fuera de
orden en la red fundamental (por ejemplo
si
el
cliente
y el
servidor
usan UDP para
comunicarse). ¿Que sucedería si en el ejemplo anterior si la red duplicara una solicitud leída?.
AI llamar al servidor que contiene una noción de la posición del archivo en su información de
estado, se suponeque elservidor.actualizala
posición del archivo cada vez que elcliente
extrae datos de archivo. E n consecuencia si la redduplica una solicitud leida, el servidor
del archivo,
recibirá doscopias, cuando la primera copia llega, elservidorextraedatos
actualiza la posición de archivo en su información de estado y regresa el resultado al cliente.
El cliente podría ver la segunda respuesta como un duplicado y descartarla, o podría reportar
un error porque recibió dosrespuestas diferentesa una solicitud sencilla. E n otro caso, la
información de estado en el servidor puede llegar a ser incorrecta, porque difiere de la noción
que tiene el cliente del estado verdadero.
MANEJADOR
NOMBRE DE ARCHIVO
POSICIóN ACTUAL
1
dept.archi.txt
test.pr0grama.c
tcp.libro.doc
tetris.exe
O
456
2
3
4
38
128
Tabla 1 . Ejemplo de una tabla de la información.de estado para un servidor de archivos con
estado.
Cuando una computadora arranca, la información de estado también puede ser incorrecta.
se llevea cabouna operación quecrea información de
estado adicional, elservidor podría no recibir los mensajes que lepermitan descartar la
información. Eventualmente la información de estado acumulada agota la memoria del
servidor. E n elejemplo del servidor de archivos, si un cliente abre 100 archivos y entonces
falla, el servidor mantendrá 100 entradas inútiles por siempre en su tabla de estado.
Si un cliente fracasadespuésque
Un servidor con estado podría llegar también a la confusión (o responder incorrectamente)
si un nuevo cliente empieza la operación después de arrancar usando los mismos números de
puerto que el cliente previo que estaba operando cuando el sistema falló. Podría parecer que
éste problema puedeser resueltofácilmente haciendo que elservidorborre
la información
previa del cliente cada vez que llega una nueva solicitud de interacción. S e debe recordar que
la intered podría retardar y duplicar mensajes, por lo que cualquier solución para el problema
de nuevos clientes que reusan lospuertos después de arrancar, deben manejartambiénel
caso donde un cliente inicia normalmente, pero su primer mensaje al servidor llega duplicado
(y una copia está retrasada).
165
Capítulo 5
*
I
E n general, los problemas del mantenimientocorrecto de estado,puedenser
resueltos
solamente con protocolos complejos que se ajustan a los problemas de entrega no confiable y
arranque de un sistema de computadora.
La información de estado como aspecto de un profocolo. Aunque se ha discutido
la información de estado en el contexto de los servidores, la cuestión de si un servidor.es con
o sin estado, se centra más en la aplicación de el protocolo que en la implementación. Si el
protocolo de aplicación especificaque elsignificado deun mensaje particular dependede
alguna manera de los mensajes previos, podría ser imposible proporcionar una interacción sin
estado.
E n esencia, el aspectode
la información de estado se enfocaen sielprotocolo
de
aplicación asume la responsabilidad de entrega confiable. Para evitar problemas y hacer
confiable la interacción , un diseñador de un protocolo de aplicación debe asegurarse de que
cada mensaje no sea de alguna manera ambiguo. Esto es, un mensaje no puede depender de
si está siendo entregado en orden, ni depender de'
si
los mensajes previos han sido
entregados. El diseñador de un protocolo debe construir la interacción de tal manera que el
servidor dé la misma respuestano importa cuantas veces o como llegue una solicitud. Los
matemáticos usan eltérmino idempotencia para referirse a la operación matemática que
siempre produce el mismo resultado. Aquí se usa el término para referirse a los protocolos que
logran que un servidor de la misma respuesta a un mensaje dado, no importa cuantas veces
llegue.
Servidores como clienfes.Los programas no siempre encajan en la definición de cliente
o servidor. Un programa servidor podría necesitar acceder servicios de red que requieren que
funcione como cliente. Por ejemplo, supóngaseque e l programa servidor de archivos del
ejemploanterior, necesita obtener la hora del díaparapoder
estampar en los archivos el
tiempo de acceso. Supóngase también que el sistema en el cual opera no tiene reloj que de la
hora del día, para obtener la hora, el servidor actúa como un cliente enviando una solicitud a
un servidor de tiempo como se muestra en la Figura 1 .
E n un entorno de red que tiene muchos servidores disponibles, no es inusual encontrar un
servidor para aplicación actuando como un cliente para otra. Por supuesto, los diseñadores
deben ser cuidadosos para evitar dependencias circulares entre servidores.
CONCURRENCIA EN REDES
El término concurrencia se refiere a la computación simultánea aparente. Por ejemplo, un
sistema de computación multiusuario puede lograr concurrencia por medio de "tiempo
compartido", o un diseño que se las arregla para que un procesador sencilloconmuteentre
múltiples tareas lo suficientemente rápido como para dar la apariencia de proceso simultáneo.
1
166
El procesamiento concurrente es fundamental para la computación distribuida y ocurre de
muchasformas. Entre las máquinasdeuna red simple, muchas parejas deprogramasde
aplicación pueden comunicarse concurrentemente, compartiendo la red que las interconecta.
Por ejemplo, la aplicación A en una máquina puede comunicarse con la aplicación B en otra
máquina, mientras la aplicación C en una tercera máquina se comunica con la aplicación D en
una cuarta. Aunque todas ellas comparten una red simple, las aplicaciones aparecen para ser
procesadas como si operaran independientemente. El hardware de la red fuerza a las reglas
de acceso para que cada par de máquinas comunicantes intercambien
información. Las reglas
de acceso previenen que un par de aplicaciones dado sea excluido por otras aplicaciones que
consumen el ancho de bandatotal de la red.
La concurrencia también puede ocurrir dentro de un sistema de computadora dado. Por
ejemplo, cada uno de los usuarios en un sistema de tiempo compartido pueda invocar una
aplicación en otra máquina. Un usuario puede transferir un archivo mientras otro usuario
maneja una sesión de conexión remota. Desde el punto de vista de un usuario parece que
todos los programas son procesados simultáneamente.
ii
Cliente
Figura 1. Unprograma
servidor de tiempo.
servidor de archivos actúacomo
un cliente conrespectoa
un
Además de la concurrencia entre clientes en una máquina simple, el conjunto de todos los
clientes en un conjunto de máquinas puedeejecutarse concurrentemente. La Figura 2 ilustra la
concurrencia entre programas cliente que corren en varias máquinas.
El software cliente normalmenteno requiere atención o esfuerzo especial por parte del
programador para hacerlo usable concurrentemente. El programador de aplicaciones diseña y
construye cada programa cliente sin considerar la ejecución concurrente; la concurrencia entre
múltiples programas clientes ocurre automáticamente porque el sistema operativo permite que
cadaunode
los múltiples usuarios invoque un clien$e concurrentemente. Así los clientes
Universidad
Autónoma
167
Capítulo 5
I
i11divicltrnlesoperan cot110cualquier programa convencional.
1
CONCURRENCIA EN SERVIDORES
En contraste a la concurrencia del software cliente, la concurrencia en un servidor requiere
esfuerzoconsiderable. Como muestrala Figura 3, un programa servidor simple,debe de
manejar
llegada
dela
solicitudes concurrentemente.
I
Para comprender porque la concurrencia es importante, se considerarán varias operaciones
que requieren comunicación y10 cálculos considerables. Por ejemplo, piénsese en un servidor
de conexión remota . Si opera sin concurrencia,puede manejar solamente una conexión
remota a la vez. Una vez que un cliente contacta con el servidor, éste debe ignorar o desechar
los requerimientos subsecuentes hasta que elprimer usuario finalice. Claramente, tal diseño
limitala utilidad del servidor, y evita que múltiples usuarios remotos accedan a una máquina
dada al mismo tiempo.
Figura 2. La concurrencia entre programas cliente ocurre cuando los usuarios los ejecutan
en múltiples máquinas simultáneamente o cuando un sistema operativomultitareapermite
múltiples copias para ejecutarse concurrentemente en una computadora simple.
TERMINOLOGíA Y CONCEPTOS
Como pocos programadores de aplicación tienen experiencia con el diseño de programas
concurrentes, la comprensión de la concurrencia en los servidores puede ser desafiante.
El concepfo de proceso. E n los sistemas de procesamiento concurrente, la abstracción
168
Implementaclón
de
remoto
E n shell
Modelo cliente-servidor Y concurrencia
de proceso define una unidad fundamental de computación. La mayoría de lainformación
esencial asociada con un proceso es un apuntador a instrucción que específica la dirección en
la cual el proceso se está ejecutando. Otra información asociada con un proceso
incluyela
identidad propia del usuario, el programa compilado que se está ejecutando y las localidades
de memoria del área de texto del programa y datos del proceso.
Unproceso difiere deun programaporqueel
concepto deproceso incluye solamente la
ejecución activa deuna computación, no elde códiao. Después de que el código ha sido
cargado en una computadora, el sistema operativo permite que ejecute uno o más procesos.
E n particular,un programa de procesamiento concurrentepermitemúltiples
procesos para
ejecutarel mismo pedazode código "almismotiempo".
Cada proceso esprocesado a su
propia velocidad, y cada uno puede empezar o finalizar en un tiempoordinario. Como cada
uno tiene un apuntador a instrucción se ejecutará en seguida, por lo que no habrá confusión
alguna.
Por supuesto, en una arquitectura monoprocesador, la C P U simple, ejecuta un proceso en
cada instante de tiempo. El sistema operativo hace que la computadora parezcacomo si
permitiera más de un procesamiento a la vez, por medio de la conmutación de la C P U entre
todos los procesosen ejecución rápidamente. Dehecho, unproceso es procesadoenun
tiempo corto, entonces otro proceso se procesa en un
lapso
corto de tiempo y así
sucesivamente. Seusa
el
término
ejecución
concurrente
para captar la idea. Significa
"ejecución aparentemente simultánea".
Figura 3. El software del servidor debe ser programado explícitamente para manejar
solicitudes concurrentes porque los múltiples clientes. contactan a un servidor usandosu
puerto de protocolo.
Programasconfraprocesos.
E n un sistema de procesamiento concurrente, un
programa de aplicación convencional es meramente un caso especial; consiste de una pieza
de código que es ejecutada por exactamente unproceso a la vez. La noción de procesos
169
Capítulo 5
o
difiere de la noción convencional de programa devarias formas. Por ejemplo, la mayoría de los
programadores de aplicación piensan en el conjunto de
variables definidas en el programa
como
asociadas
con
el código. Con todo, si más de un proceso ejecuta el
código
concurrentemente esesencial que cada proceso tengasu propia copia de variables.
Para entender por qué, considérese el siguiente segmento de código en
los enteros del 1 al I O :
for (i = O; I
"C" que imprime
< 10; i++)
printf("%d\ n", i);
La interacción usauna variable índice, i. Enunprogramaconvencional,
el programador
piensa que la variable i está situada junto con el código. Pero, si dos o más procesos ejecutan
el segmento decódigoconcurrentemente,unode
ellos puede estar en la sexta iteración
cuando el otro índice va en la primera iteración. Cada uno debe de tener un diferente valor de
i. Así cada proceso debe tener supropia copia de la variable i o resultará una confusión.
I
Llamadas a procedimiento. En un lenguaje orientado a procedimiento, como Pascal o
C, el código
ejecutado
puede
contener
llamadas
subprogramas
a
(procedimientos
o
funciones). Los subprogramas
aceptan
argumentos,
calculan un resultado, y entonces
regresan junto al punto de llamada. Si un códigoejecuta múltiples procesos concurrentemente,
cada uno puede estar en un punto diferente en las secuencias de llamadas a procedimiento.
Un proceso A, puede empezarsu ejecución, llamar a un procedimiento, y entonces llamar a un
procedimientodesegundo
nivel antesque otro proceso B, empiece. El proceso B puede
regresar desde el proceso de la llamada a proceso de primer nivel justo cuando el proceso A
regresa de una llamada de segundo
nivel.
El sistema
en
tiempo
de
ejecución para
lenguajes
de
programación
orientados
a
procedimiento usan un mecanismo de pilas para manejar las llamadas a procedimiento. Los
sistemas en tiempo de ejecución colocanun registro de activación a procedimiento. Sobre la
pila cadaque se haceunallamadaa
procedimiento. Entre otras cosas los registros de
activación almacenan información acerca de la localización en el código en el cual ocurre la
llamada a procedimiento. Cuando el procedimiento finaliza su ejecución, el sistema en tiempo
deejecuciónsaca el registro de activación del topede la pila, yregresa al procedimiento
desdeel cual ocurrió la llamada. Enanalogíacon la regla para variables, los sistemasde
procesamiento concurrente proporcionan una separaciónentre llamadas a procedimiento enla
ejecución
de
procesos:
Cuando
un pedazo
de
código
ejecuta múltiples procesos
concurrentemente, cada uno tiene su propia pila de tiempo de ejecución de los registros de
I
activación de procedimiento.
Conmutacíóndecontexto
y díseiiode software deprotocolos. Aunque las
facilidades de procesamiento concurrente que los sistemas operativos proporcionan hacen los
programas más poderosos y fáciles de entender, nohacen
lo mismo con los costos
computacionales. Para asegurar que todos los procesos sean procesados concurrentemente,
el sistema operativo usa conmutación rápida de CPU entre procesos para que parezcan al
usuario como procesos quese ejecutan simultáneamente.
I
170
Implementación
de
*_._~... ..
~
m.,-.",-*
un shell remoto
-."
Modelo cliente-servidor y concurrencia
Cuando un sistema operativo detiene temporalmente la ejecución de un proceso y conmuta
a otro, ha ocurrido una conmutación de contexto. La conmutación de contexto de procesos
requiere el uso de la CPU, y mientras la CPU está ocupada en la conmutación, ninguno de los
procesos de aplicación recibe algún servicio.Así,seve
que la. conmutación de contexto
necesita soportar procesamiento concurrente.
Para evitar gastos innecesarios, el software del protocolo debería ser diseñado para
minimizar la conmutación de contexto. En particular, los programadores deberían ser siempre
cuidadosos para asegurar que los beneficios introducidos por la concurrencia en el servidor
sobrepasen el costo de la conmutación de contexto entre los procesos concurrentes.
,
Concurrencia y entradakalida (Us)asíncrona. Además del soporte proporcionado
poreluso
concurrente de la CPU, algunossistemas operativos permiten programas de
aplicación sencillos que controlan las operaciones de E/S concurrentes. En UNIX, la llamada al
sistema select, proporciona una operación fund mental alrededor de la cual los
?
programadores pueden construirprogramas
que manejen E/S concurrente. En principio,
select, es fácil de entender: permite a un programa preguntar al sistema operativo cual
dispositivo de E/S está listo para usar.
Como ejemplo, imagínese un programa deaplicación
que lee caracteres desde una
conexiónTCP y los escribe a la pantalla. El programa debería también permitir al usuario
teclear comandos en el teclado para controlar como son desplegados los datos. Como un
usuario rara vez (o nunca) teclea comandos, el programa no puede esperar la entrada desde
el teclado (debería continuar la lectura y desplegar texto desde la conexión TCP). Sir1
embargo, si el programa trata de leer desde la conexión TCP y los datos no están disponibles,
el programa se bloqueará. El usuario debe teclear un comando mientras el programa
bloqueado espera entradas de la conexión TCP. El problema es que la aplicación no puede
saber si la entrada llegará desde la entrada o desde la conexión TCP primero. Para resolver el
dilema, un programa UNIXllama a select. De hecho le pregunta al sistema operativo si le
permite saber cual fuente deentrada llegará a estar disponible primero. La llamada regresa tan
pronto como la fuente está lista, y el programa lee de esa fuente.
INTERNETWORKING WITH TCP/IP
CLIENT-SERVER PROGRAMMINGAND APPLICATIONS
Prentice-Hall. Vol. 3. [1993]
Douglas E. Comer
Págs. 9-18, 21-26, 31-32.
Universidad Autónoma Metropblitana. Unidad lztapalapa
171
CAPÍTULO 6
ENTRE PROCESOS
COMUNICACIóN ENTRE PROCESOS
[TOMADO Y ADAPTADO DE Goscinski]'
En un entorno distribuido, la comunicación entre procesos cooperantes se hace por medio
del paso del mensajes. La comunicaciónentre procesos en diferentes computadoras se puede
dar, usando el mismo formato'que el de la comunicación entre procesos en una computadora
simple.
Para que un sistema distribuido proporcione acceso a los recursos distribuidos de una red,
de manera uniforme e independiente del lenguaje, de la localización de la red, y en algunos
casosdesistemas
operativos anfitriones, la comunicación entre procesosdebe
ofrecer
políticas y mecanismos para efectuar las comunicaciones locales y remotas entre procesos
autorizados y entre procesos y recursos.
El alto rendimientode la comunicación es la facilidad más crítica quedebe ofrecer un
sistema de comunicación distribuido. El rendimiento de tales sistemas depende de la rapidez
de la comunicación entre procesos, la cual dependea suvez dedosaspectos:de
las
primitivas de la comunicación entre procesos y del protocolo de transporte que soporta esas
primitivas.
Ya que las computadoras
en
un
sistema distribuido no
comparten
memoria,
la
comunicación vía memoriacompartida,no
es aplicable. La comunicación entre procesos
puede ser llevada a cabo solamente mediante el
intercambio de mensajes.
Pueden ser usados diferentes conjuntos de primitivas en la comunicación entre procesos.
Sin embargo, los tres más comunes están basadosen:
1. Paso de mensajes.
2. Llamadas a procedimientos remotos(RPC).,
3. Transacciones.
Están ordenados de acuerdo a un orden creciente de nivel de abstracción; cada conjunto
puede ser construido basándoseen su predecesor.
El paso de mensajesentre procesos remotosestá asociado con el modelocliente-servidor y
es una extensión de la comunicación entre procesos para sistemas centralizados. El flujo de
información es unidireccional desde el cliente hastael servidor: sin embargopuede ser
bidireccional como en el caso rendezvous (encuentro).
CaDítulo 6
Liskov' sugirió que la comunicación entre procesos remota deberíaestar basada en el paso
guardianes. Los
demensajesde
un mismo tipo entre módulosdeprogramasllamados
guardianes
están
destinados
a
ser las unidades
de
distribución en
un
sistema
multicomputadora y pueden y pueden
ser vistos como servidores autónomos.
El términogeneralllamadaaprocedimientosremotos
(RPC) implica un mecanismo que
verifica ypermitea un lenguajededeterminado nivel llamar aunacomputadorapara
ser
dirigida automáticamentea otra computadoraencorrespondenciaaunallamadadedicho
lenguaje. Este mecanismo requiere un protocolo de transporte que soporte la transmisión de
sus argumentos y resultados. Es importante notar que el término llamada a procedimientos
remotos es usado algunas veces para describir un protocolo de transferencias de bajo nivel.
Las RPCs ofrecen un flujo bidireccional de información.
Las transacciones fueron desarrolladas orjginalmente para los sistemas de administración
de bases de datos, para auxiliar en el mantenimiento deconsistencia forzada de aplicaciones
dependientes arbitrarias en el almacenamiento de datos. El enfoque y los mecanismos de las
transacciones simplifican la construcción desi$temas confiables. Dichossistemasdeben
proporcionar soporte uniforme para la invocación y sincronización de operaciones en objetos
de datos compartidos, asegurar la variación de transacciones, y el comportamiento atómico y
la recuperación en presencia de la red. Es deseable, desde el punto de vista del usuario y del
programa, que las transacciones sean completamentetransparentes.
El paso de mensajes y las llamadas a procedimientos remotos están en amplio uso hoy en
día, pero los sistemas operativos distribuidos soportan las transacciones aunque aún no sean
ampliamente reconocidas.
I
COMUNlCAClÓN ORIENTADA A MENSAJES.
La comunicación orientada a mensajes está definida como una forma de comunicación en
la cual el usuario es consciente explícitamente del mensaje usado enla comunicación y de los
mecanismos usados para entregar
y recibir mensajes.
Mensajes. Un mensajeesuna
colección de objetos dedatosde
un tipo específico
formada por un tamaño de cabecera fijo y una longitud de cuerpo variable (algunas veces
constante), la cual puedeser manejada porun proceso, y entregada asu destino.
Un tipo asociado con un mensaje proporciona información estructural sobre como debería
ser identificable el mensaje. Un mensaje puede ser de cualquier tamaño y puede contener ya
sea datos, o apuntadores a datos fuera de la porción contigua del mensaje. El contenido del
*Liskov B. H. and Scheifler R. (1982). Guardians and Actions: Linguistic Support for Robust,
Distributed Programs.ACM Transactions on Programming Languages andSystem, 5(3), 381-404.
176
Implementación
de
un shell remoto
__
"
"
-.
"
-
."
Comunicación entre
'
.~.. .
.procesos
. .. - ..
I I I W I W J ~ esle clelerltlltledo por. el proceso emsor. Et1 C ~ I I ~ ~ctlyutlas
I O ,
p a l e s de la ( X I ~
contienen información relacionada conel sistema que puede ser suministrada porel mismo.
J ~ L ~ I ~
Se ilustran dos ejemplos de formatos de mensajes simples en la Figura 1. La parte (a) de
esta figura muestraunacabecerade
mensajesimple condatosmientrasque
la parte (b)
presenta una cabecera de mensajesimple con un apuntador.
Uno de los problemas más importantes asociados con mensajes, es que estructura, si hay
alguna, debería ser usada.
Puerto fuente
Puerto destino
ldentificador del mensaje
Tipo
Número de elementos
a)
Puerto fuente
Puerto destino
ldentificador del mensaje
Tipo de puntero
Número de elementos
Apuntador
Datos
Datos
Figura 1. Formatos de mensajes simples:(a)sin
datos.
b)
I
apuntador a datos, (b) con apuntador a
Losmensajespueden
ser estructurados o no estructurados. Elusodemensajes
no
estructurados, lo cual hacenecesario la interpretación por los procesosdel usuario, tiene
problemas. Los mensajes estructurados son favorecidos además por razones de eficiencia y
bajo costo.
Primifivas de paso de mensajes bdsicas. La comunicación orientada a mensajes está
en estrecha relación con el modelo cliente-servidor, donde un proceso, un cliente (o emisor)
envia un mensaje(una solicitud) a otro procesollamado servidor (o receptor), y entonces
espera una respuesta o continúa corriendo. ,
En el área de paso de mensajes
la comunicación se basa en dosaspectos:
1. Cual es el conjunto de primitivas de comunicación.
2. Cual es su semántica.
En la Figura 2 se muestra un mensaje que es enviado y recibido mediante la ejecución de
primitivas
La forma más simple de primitivas de comunicación: envía y recibe dadas en la Figura 2, y
el comportamientode los dos procesos involucrados en la comunicación, se ilustran en la
I
Figura 3.
177
Capítulo 6
I
"
La Figura 3 muestra que:
1. El proceso cliente tiene que especificar la dirección destino (servidor) y el mensaje en la
primitiva envía (servidor, mensaje).
2. El proceso servidor específica desde donde viene el mensaje y proporciona un buffer
para almacenar el mensaje que llega: recibe(idenfificador- roces so-fuente, buffer).
f
envía lisfa-de-expresiones a identificadordesfino
recibe lisfa-de-variables
de idenfificadorfuenfe
,#
Figura 2. Primitivas de paso de mensajesbásicas.
Servidor
Cliente
-
envia
Procesos
.................................................................................
Comunicación virtual
recibe
Conexió
n física
Núcleo y sistema de comunicación
envía
I
I
envía
-
recibe
A
I \
Figura 3. Conexión entre el cliente y el servidor que usan las primitivas envía y recibe para
comunicarse.
No se requiere inicialización ni conexión (por lo tanto, ni desconexión).
Algunas veces, una primitiva permite vigilar y/o seleccionar los mensajes que llegan. La
Figura 4(a) presentauna primitiva recibe, quevigila: permite la recepciónde un mensaje
solamente si B es verdadero.La Figura 4(b) muestrala primitiva recibe selectiva; dicha
selección esnormalmenteno
deterministica aunquepuede ser impuesto un ordenen las
declaraciones dadas en laFigura 4(b).
Seplantea ahora la cuestión: ¿Que semánticas deberían tener las primitivas?. Liskov'
identifica las siguientes primitivas de comunicación:
* Liskov B. (1979). Primitives for Distributed Computing. In Proceedings of the 7th ACM Symposium
on Operating System Principles, Pacific Grove, California, pp. 33-43.
Implementación
de
7 78
~
."
"
"
un shell remoto
"
-
1. El envíoque no espera. El proceso que envía un mensaje solamente hastaque el
mensaje ha sido compuesto.
2. El envío sincronizado. El proceso que envia el mensaje espera hasta que
el mensaje
haya sido recibido por el proceso destino. La comunicación requiere que el emisor y el
receptor se sincronicen para intercambiar mensajes.
3. El envío de invocaci6n remoto. El proceso emisor espera una respuesta de el proceso
receptor que ha ejecutado el comando.
(a) recibe lista-de-variables
desde identificadocfuenfe cuando 8
(b) selección
recibe lista-de-variables desde id-fuente- 7
or recibe lista-de-variables desde 'id-fuente-2
or recibelista-de-variables desde id'fuente-3
fin
Figura 4. Primitiva recibe que vigila (a) y selectiva (b).
Éstas semánticasno explicantodos los detalles y no songenerales.Esto
es porque un
conjunto de primitivas de
paso
de mensajes debe proporcionar facilidades para la
identificación de procesos involucrados en la comunicación, para mover datos entre ellos, para
sincronizar susacciones
y proporcionartrhnsferenciaconfiable
dedatos. Las semánticas
deberían de ser fáciles de entender, eficientes al implementarlas, y no ser propensas a error.
S e consideran en seguida varios conjuntos de primitivas.
Primitivasbloqueantescontra
no bloqueantes. Una de las propiedades más
importantes de las primitivas del paso de mensajes concierne a si su ejecución podría ser
retardada. Se diferencia entre primitivas bloqueantes y no bloqueantes. S e dice que una
primitiva tiene una semántica no bloqueante si su ejecución nunca retarda a su invocador: en
otro casose diceque la primitiva es bloqueante. En elprimer caso el mensaje debe ser
orientado a buffer.
Con una primitiva no bloqueante:
I
1. envía regresa elcontrolalusuariodelprogramatanpronto
como el mensaje ha sido
desencolado para su transmisión subsecuente o tan pronto como una copia sea hecha.
2. Cuando el mensaje ha sido transmitido (o copiado a un
lugar
seguro para una
subsiguiente transmisión), el programa es interrumpido para informar que el buffer puede
ser
,
3. La correspondiente primitiva recibe, señala su disponibilidad para recibirel mensaje y
proporciona un buffer en el cual puede ser colocado el mensaje.
4. Cuando llega un mensaje el programa es informado mediante una interrupcion.
179
Capítulo 6
La ventaja de las primitivas nobloqueantesesqueproporcionanmáxima
Además, éstas primitivas son útiles para aplicaciones en tiempo real.
flexibilidad.
Las desventajas delas primitivas no bloqueantes son queellas:
1. Pueden requerir deunbufferpara
prevenir elacceso o cambiodelcontenido
mensaje antes o durante la transmisión, o mientras.se está esperando la recepción.
del
2. Hacen la programación artificiosa y difícil (no reproducible, los programas dependientes
del tiempo son arduos deescribir y horribles de depurar).
Las primitivas bloqueantes proporcionan una forma simple para combinar la transferencia
de datos con la función de sincronización. Si la primitiva envía tiene semántica de bloqueo, el
emisor es bloqueadohastaque elreceptor, recibe el mensaje.Encambio, el receptor es
también suspendido hasta que el emisor ha ejecutado la solicitud de envía. Esto resulta en la
sincronización de los procesos emisor y receptor.
Con las primitivas bloqueantes:
I
1. Paraunbloqueono
confiable, envíano regresa el control al usuario hastaque el
mensaje ha sido enviado; el programa puedemodificar el buffer.
2. Para un envío confiable envía no regresar el control al usuario hasta que el mensaje ha
sido enviado y la recepción reconocida; el programa puedemodificar el buffer.
3. recibe no regresa el control hasta que un mensaje ha sido colocado en el buffer.
4. Las primitivas bloqueantes y no bloqueantes no causanconflicto.
Hay tres formas para la primitiva recibe. El recibe bloqueante es el más común, ya que el
procesono tiene algo quehacer antes o mientqas aguarda la recepción del mensaje. Hay
también una primitiva recibe no bloqueante y una primitiva para verificar si un mensaje esta
disponible para recibirse. Como resultado, un procesopuede recibir todos los mensajes y
entoncesseleccionaunode
los procesos.En la Figura 5 se ilustran las primitivas envía y
recibe con semántica bloqueante.
Elproblemacon
las primitivas bloqueantes esque inhiben el paralelismo (un proceso
bloqueadoen recibe o envía nopuedehacer un trabajo útil) yno habilitan a un proceso
bloqueado para que esperamás de un tipo de evento.
Primifivas con buffer contra primitivas sin buffer (encuentros local y remoto).
En algunos sistemas de comunicación basados enmensajes los mensajes usan buffers entre
el tiempo que son enviadosy recibidos. Se tienen tres casos: 1
1. Sistema con buffer de tamaño finito: En este caso el envia se puede retardar hasta
que exista espacio suficiente en el buffer, o envía envía un código de retorno al emisor,
indicando que el mensaje no puedeser enviado. La situación para un recibees similar.
2. Sistema con buffer ilimitado. El procesonunca se retardará cuando se ejecute un
envía. Este sistema se llama asíncsono. La característica más importante delos sistemas
asíncronos es que permite al emisor adelantarse arbitrariamente al receptor.
180
Implementsción
de
un shell remoto
3. Sistema sin buffer. E n este caso la ejecución de envía siempre se retarda hasta que se
ejecuta su recibe correspondiente. E n este tipo desistema, los procesosdeben ser
sincronizadosparaquese
transfierael mensaje;aesta.sincronización
se lellama
rendezvous (encuentro).
E n general los sistemas con buffer son más complicados de diseñar y presentan más
problemas de control que los sistemas sin buffer.
Encuentro local (rendezvous local). El encuentro local es usado enuna
comunicación
bidireccional entre dos procesos en el mismo programa ejecutándose en el mismo espacio de
dirección. Un encuentro ocurre como consecuencia de que un proceso invoque una entrada
declaradaenla
interface de
un
segundoproceso,
y el segundoproceso
ejecute una
declaración de aceptación que habilite una llamada a esa entrada.
'
La entrada debe tenerparámetros de entrada1 y de salida. Los parámetros de entrada son
pasados por valor de el emisor a el receptor cuando comienza el encuentro, y los parámetros
de salida son pasados al emisor desde el receptor cuando termina el encuentro.
1
P
O
EMISOR
RECEPTOR
I
envía
recibe
bloqueado
bloqueado
recibe
<
envía
mensaje
respuesta
de
Figura 5. Primitivas envía y recibe con semántica bloqueante.
Encuentro remoto (rendezvous remoto). El encuentro remoto es una extensión uniforme
de un encuentro local. Esta forma de comunicación tahbién proporciona flujo de información
bidireccional. Para invocar un encuentro remoto, un proceso debe tener tanto:
1 . La visibilidad para la interfazde
el proceso remoto. La interfaz es proporcionada
mediante una copia de la definición de la interface de el receptor (proceso destino) en el
texto de cualquier programa que desee invocarlo.
2. El identificador del proceso remoto. El identificador del proceso remoto consta del
identificador de el proceso destino y de la identidad del nodoen el cual se están
ejecutando.
181
CaDítulo 6
El encuentro remoto es invocado exactamente de la misma forma que un encuentro local.
un
La Figura 6 ilustra un protocolo simple de cuatro paquetesusadoparaimplementar
encuentroremoto entre nodos.Proporcionaseguridaden
los servicios de entrega y tiene
buenas características bajo carga.
Primitivas confiablescontra primitivas no confiables. Las primitivas discutidas
hasta ahora se llaman primitivas no confiables porque tienen problemas si se presenta alguna
falla en la red.
La primitiva no confiable envía solamente pone un mensaje en la red. No garantiza que la
entrega sea llevada a cabo efectiva y/o correctamente. En una comunicación confiable, entre
procesos, la primitiva envía maneja los mensajes perdidos usando retransmisiones internas y
reconocimientos basándose enintervalos de tiempo.
Surge la cuestión de si la confiabilidad debería ser tratada en las capas de alto nivel. Una
solución llamada argumento de extremo a extremo, afirma que sí, aunque exista un poco de
redundancia.
1
EMISOR
bRBplica
RECEPTOR
l
(parhmetr
Y
I
Reconocimient
’
O
Figura 6. Protocolo de encuentro remoto.
(a) primitivas no confiables
CLIENTE
”
(b) primitivas confiables
CLIENTE
SERVIDOR
enví
envía
recibe
I FF
recibe
recibe
SERVIDOR
recibe
1
envía
>anvia
.
recibe 4
1
Figura 7. Primitivas confiables y no confiables.
182
Implementación
de
un shell remoto
-.-
Comunicacih entre Drocesos
El recibe confiable o no confiabledifiere
en que el
primero
envía reconocimientos
automáticamenteconfirmando la recepción’de mensajes mientras que el último no. Las dos
formas de comunicación requierenlautilización
deéstas primitivas depasode
mensajes
simples de forma simétrica. Si el cliente solicita algunos datos, el servidor envía una respuesta
usando la primitiva envía. Por ésta razón el cliente tiene un conjunto de primitivas recibe para
recibir cualquier mensaje del servidor. Las primitivas confiables y no confiables se contrastan
en la Figura 7.
Formas estructuradas depaso de mensajes.El rendimiento de la comunicación entre
procesos se puede aumentar imponiendo una estructura a las primitivas. Una forma
estructurada de comunicación que usapaso
de mensajes se logra diferenciando entre
solicitudes y respuestas (más precisamente a través del comportamiento de solicitud-respuesta
de las operaciones) y proporcionando flujo de informaiCión bidireccional. Esto significa que el
cliente envía un mensaje de solicitud y espera una respuesta. El conjunto de las primitivas se
da en la Figura 8.
Direccionamiento simétrico. E n la comunicación directa, cada proceso que quiere enviar o
recibir un mensaje debe nombrar explícitamente al emisor o receptor de la comunicación. E n
este caso, las primitivas envía y recibe son definidas como se muestra en la Figura 9.
I
Esteesquema exhibe un direcc’ionamientosimétrico, es decir tantoel
receptor tienen que nombrar uno a otro para comunicarse.
emisor como el
Direccionamientoasimétrico. Una variantedeeste
esquemaemplea asimetría en el
direccionamiento; solamente elemisornombraal
receptor, mientras que elreceptor
no
requiere nombrar al emisor. E n este caso las primitivas envia y recibe se definen como se
muestra en la Figura I O .
envía
envía solicitudes y obtiene respuestas; combina un envía previo deun
servidor
conun recibe que obtiene de la respuesta delservidor.
cliente al
obten-solicitud
es ejecutada por los receptores (servidores) para adquirir mensajes que contienen
trabajo a realizar.
envía-respuesta
el
receptor
(servidor)
comdetar trabaio.
el
usa esta primitiva para enviar una respuesta después de
Figura 8. Una forma estructurada de primitivas de paso de mensajes.
I
183
CaDítulo 6
La comunicación directa es fácil de implementar y de usar. La desventaja de los esquemas
simétrico y asimétrico es la limitada modularidad de la definición del proceso resultante. La
comunicación directa (nominación) no permite mas que un
cliente y no hace posible enviar un
mensaje a más deun servidor idéntico. La solución es la,comunicación indirecta y está basada
en buzones.
Enlaces. Un enlace se define como un canal de comunicaciónunidireccional (simplex) para
procesos del usuario, procesos del sistema o del núcleo. Un enlace es un objeto protegido y
puede ser usado como un mecanismo de nominación para recursos controlado mediante un
administrador de recursos centralizado. Para usar un enlace como un medio de comunicación
cada proceso tiene una tabla de enlaces asociada conél. Cada entrada deesta tabla contiene
un caminodecomunicación
disponible para el proceso. Así, la tabla identifica todos los
caminos de comunicación conlos cuales el ppceso hace interface con el resto del sistema. Un
proceso
puede
generar
un enlace o destruirlo.
1
envía (PImensaje)
envía un mensaje al procesoP.
recibe (Q,
mensaje)
recibe un mensaje del procesoQ.
Figura 9. Primitivas para comunicacióndirecta.
Los enlaces pueden ser usados eficientemente para soportar la migración de procesos; sin
embargo los enlaces unidireccionales tienen varias deficiencias como "enlaces colgantes"
(generadoscuandomuere un proceso) y gastosde administración de enlaces. Para evitar
estos problemas se crearon los enlaces bidireccionales (dúplex). La Figura 11 y la Figura 12
muestran las primitivas decomunicacióndeenlace
orientadas aenlaces y conenlaces
bidireccionales (envía) respectivamente.
I
envía (PImensaje)
envía un mensaje al proceso P.
recibe (id,mensaje)
recibe un mensaje de cualesquier procesos;id secoloca al nombre de procesos
con el quela comunicaciótl a tomadolugar.
Figura I O . Primitivas con direccionamientoasimétrico.
184
Implementación
un de
shell remoto
Comunicación entre procesos
Puertos. La segunda técnica es conocida como comunicación indirecta y esta basada en
nombres globales a veces llamadas buzones.Un buzónpuedeaparecer
como el destino
clmignado en ctralqtlinr primitivn anvín, y COIIIO In flrnrlto dosigtlndn 011 clr:d(1tri(~r Ijrirllilivrr
recibe. Esto implicaque los mensajes enviados a un buzón dado pueden ser recibidos por
cualquier proceso que ejecute una nominación recibe para ese buzón.
I
el
Por
envía (enlace, buffer)
envia un mensaje desde un buffer a lo largo de la transmisión indicada
enlace.
en
recibe (enlace, buffer)
recibe un mensaje en la transmisión indicada por el enlace y la coloca
buffer.
el
I
Figura 1 1 . Primitivas de comunicación orientadas a enlace.
Un procesopuedecomunicarsecon
otros procesos por medio de puertos diferentes. La
primitiva que permite que un mensaje sea recibido en un puerto, dado se muestra en la Figura
13.
envía (enlace, buffer, enlace-final)
envia a un extremo de un enlace, enlace-final, la transición indicada
por el enlace y la coloca en el buffer
Figura 12. La primitiva send con enlace bidireccional.
recibe (8, mensaje)
recibe un mensaje del puerto B.
Figura 13. La primitiva recibe para comunicarse a través de un puerto.
1
1
envia (A, puerto)
envía puerto al puerto A.
Figura 14. La primitiva envia pasa la propiedad de un puerto.
185
Capítulo 6
La propiedad de un puerto puede ser pasada en un mensaje de un proceso a otro. recibe
accede al puerto que debeser pasado en el mensaje. En este caso la primitiva envía se define
en la Figura 14.
Obtención dedatos de un proceso. Hay alternativas para pasar deun proceso a otro:
1. Los procesos pasan datos porvalor a través del intercambio de mensajes.
2. Los procesos pasan datos porreferencia.
Los sistemas de mensajes por valor requieren que los datos sean copiados físicamente.
Este tipo desistema se usaen los mensajes asíncronos. Ademáscon frecuencia estos
sistemas limitan el tamaño del mensaje.
4
E l paso de datos por referencia requiere memoria compartida. Su principal ventaja es que
es barato; los mensajes largos no necesitan ser copiados más de una vez. Sus desventajas
son que la tarea de programación que implica, es más compleja y requiere una combinación
de administración de memoriavirtual y comunicación entre procesos.
Esquemas de Comunicaciónentreprocesos.
Unesquemacomúndemensajes
basado en la comunicación entre procesos es uno a uno (denotado algunas veces 1:I). Un
procesoemisorsimple
envía un mensajea un proceso receptor simple ' y eventualmente
obtiene una respuesta. Es también posible que el emisor no espere respuestaalguna.
En muchos sistemas distribuidos es necesaria la comunicación uno a muchos o difusión.
(l:n, n>l, n es el número de procesos). Este esquema de comunicación puede ser necesario
para notificar una condición excepcional a todaslas partes. I
Enalgunas aplicaciones se necesita unacomunicaciónde
difusión restringida, la cual
permite a un subconjunto de la red virtual recibir mensajes de el mismo tipo. Ejemplo de tales
aplicaciones sonsistemas que soportanencuentrosremotos y concurrentes, protocolos de
encargo, control y producción de procesos.
Un ejemplo de comunicación muchos a unoes un esquema donde hay un cliente y muchos
servidores idénticos.
I
El último esquema de comunicación considerado esel de muchos a muchos. En la práctica
se implementacomounacomunicaciónmuchosauno
(un cliente y varios servidores
idénticos), viapuertocompartido o de un procesode interface dedicado,seguidodeuna
comunicación uno auno.
Respuestas Multidafagfama. La consideracibn final con respecto al envio de mensajes
es si deben ser de tarnaño fijo o variable.
El envío de mensajes de tamaño fijo tiene las siguientes caracteristicas:
1. La implementaciónfísica es directa.
186
Implementación
de
un shell remoto
Comunicación éntre procesos
2. La tarea de programación es difícil.
Et) 01 otro caso los rrlerlsajos de tarrlailo variable:
1. Requieren de una implementación física más compleja.
2. L a programación es simple.
En un sistema de comunicación con mensajes de tamaño fijo la entrega debe ser confiable.
Los mensajes largos debenser
divididos y enviadoscomo
un mensajemultipaquete
(multidatagrama).
Los mecanismos
de
recuperación en sistemas basados
en
multipaquetes son
mas
complicados que en el caso de
una
solicitud
de
mensaje (sistema basado en un
reconocimiento).
Condiciones de excepción. Supóngase que un mensaje se pierde en el caminodel
emisor al receptor. Hay tres métodos básicos para tratar con este evento y con la revoltura de
mensajes.
I
1. El sistema operativo es responsable de la detección de este evento y del reenvío del
mensaje, si así lo desea.
2. El proceso emisor es responsable de la detección del evento y de la retransmisión del
mensaje, si así lo desea.
3. El sistema operativo es responsable dela detección del evento;entonces notificaal
proceso emisor que el mensaje se ha perdido. El proceso emisor puede proceder si así
lo desea.
LLAMADA A PROCEDIMIENTOS REMOTOS (RPC)
El modelo cliente-servidor para la interacción de procesos requiere del intercambio de dos
un mecanismo dellamada a
mensajes. Este tipo de relación es mejorservidamediante
procedimientos tradicional (un mecanismo para la transferencia de control y datos entreun
programa que corre en una computadora simple), donde la espera del resultado está implícita
en la llamada al servicio. Como el mecanismo de llamada a procedimiento tradicional no está
los sistemas distribuidos,fue desarrollada la llamada aprocedimientos
adaptadopara
remotos (RPC) para proporcionar este tipo de sincronización de alto nivel en la red.
Caracteristicas. La llamada a procedimientos remotos es un enfoque lingüístico basado
en el concepto fundamental conocido como llamada a procedimiento. La idea de las llamadas
a procedimientos remotos es muy simple y está basada en la observación de que en el modelo
un cliente envia una solicitud, y entonces se bloquea hasfa que un servidor remoto envia una
respuesta.
187
Capítulo 6
Así, el objetivo de una llamada a procedimientos remotos es permitir que los programas
distribuidos sean escritos de la misma forma que los programas convencionales para sistemas
de computación centralizados. Una de las principales ventajas de esta forma de comunicación
es que el programador no necesita estar consciente de si la llamada invoca un procedimiento
(o proceso) local o remota(o).
La diferencia entre llamada a procedimientos y llamada a procedimientos remotos es el
hecho de que el cliente y el servidor están en procesos separados, corriendo normalmente en
computadoras separadas. Así:
1. Están expuestos tanto a las fallas de computadoras como a las de los sistemas de
comunicación.
2. No comparten el mismo espacio de direqciones.
3'.Tienen tiempos de vida separados.
El término muy general llamada a procedimientos remotos significa un mecanismo de tipo
verificador que permite a un lenguaje de determinado nivel llamar a una computadora para
convertirse automáticamente en una llamada correspondiente de un lenguaje de ese nivel en
otra computadora. Este mecanismo requiere un protocolo de transporte para soportar la
transmisión de sus argumentos y resultados. La RPC, es responsable de el mapeo de las
llamadas de los lenguajes y de la clasificación del sistema de alto nivel dentro de las
facilidades proporcionadas por la capa de transporte de la red.
Aunque el paso de mensajes y llamadas remotas son análogos, los sistemas basados en
mensajes y los sistemas basados en llamadas a procedimientos remotos difieren en la relación
entre como se comunican los procesos. Los procesos en los sistemas basados en mensajes
sirven de compañeros mientras que en los sistemas basados a llamadas a procedimientos
remotos usan una relación maestro-esclavo.
,
Llamador
(proceso cliente)
-
I
Proceso: llama
(procedimiento)
espera
continúa
<
mensaie resultante (respuesta)
Llamado
(proceso servidor)
Proceso
(recibe)
>
-
ejecuta proc.
regresa
-
COMPUTADORA A
COMPUTADORA B
Figura 15. Una llamada a procedimiento remoto.
I
Hay también otra diferencia. Mientras que enel paso de mensajes todos los valores
requeridos deben ser asignados explícitamente a los campos de un mensaje antes de su
transmisión, la llarrada a procedimientos remotos proporciona un ordenamiento de los
188
-
ImplementaciQn de ur1 shell remoto
Comunicacibn entre procesos
parámetros para la transmisión del m.ensaje, esto es, la lista de parámetros es vista como un
todo por el sistema para formar un mensaje.
L a llamada a procedimientosremotos es enviada porun llamador (proceso cliente) en la
forma de mensaje de llamada (solicitud) a el proceso remoto (//amado).El proceso llamado
(servidor)
ejecuta
el
procedimiento
y envía
un
mensaje de
respuesta.
E n el mensaje
intercambiado en la Figura 15, es obvio que la llamada a procedimientos remotos proporciona
flujo de información bidireccional.
La semántica de llamadas a procedimientos
remotos
procedimiento locales:
es análoga a las llamadas a
1. El llamador se suspende mientras espera un resultado.
2 . El llamador puede pasar argumentos a el procedimiento remoto.
3. El procedimiento llamado puede regresar resultados.
Sin embargo, ya que los procesos llamador y llamado están en computadoras diferentes
(conespaciosde
direccióndiferentes)elprocedimientoremoto
noaccede a los datos y
variables de el ambiente llamador.
RPC está disponible, por ejemplo en la versión UNlX de Sun.
Aspectos principales. Las propiedades y primitivas son los aspectos principales de un
mecanismo de llamada a procedimientos remotos. Una llamada a procedimientoremoto
debería exhibir las siguientes seis propiedades:
1. Semántica de llamada uniforme. Una implementación de llamada a procedimiento remoto
transparente
mantiene
la misma semántica que la que esusada
para llamadas a
procedimientos locales. E n otro caso, los procedimientos local y remoto deben ser
codificados diferentemente.
2. Tipo de verificación. El nivel de tipo de verificación aplicado a las llamadas a
procedimiento local se aplica igualmente a las llamadas a procedimientos remotos. Una
llamada a procedimientoremoto es tratada por elcompilador
exactamente comouna
llamada a procedimiento local.
3. Funcionalidad de parametrización completa. Todos los tipos de datos básicos deberían
ser asignadoscomo
parámetros a la llamada a procedimientos remotos. Los tipos de
primitivas, tipos estructurados y tipos definidos por el usuario deben ser considerados.
de
concurrencia y .manejo
de
excepciones.
Estos
no
son
aspectos
4. Control
fundamentales de
las
llamadas a pyocedimientos remotos, pero el lenguaje de
programación debe proporcionar estos servicios.
5. Conexión distribuida. Un lenguaje de programación que usa RPC debe tener algunos
medios para compilar, conectar y cargar programas distribuidos en la red.
6. Computaciones huérfanas. Este aspecto considera la confiabilidad de un mecanismo de
RPC,en particular la recuperación de una llamada a procedimientos remotos que falla.
Las dos técnicas principales usadas para tratar con huérfanos son:
I
.
189
Capítulo 6
1 . Exterminación: encontrar y abortar las computa'ciones huérfanasque resultan deun
fracaso.
2. Expiración: determinar cuando una computación (candidata a ser.huérfana) ha existido
después de su tiempo de vida esperado. La computación es abortada automáticamente
después del tiempo de expiración.
Primitivas. Cuando se usan llamadas a procedimientos remotos, un cliente interactúa con
un servidor por medio de una declaración a llamada como la mostrada en la Figura 16.
Unallamada remota es ejecutada de la siguiente manera: los argumentosvalor
son
enviadosa al servidor y el proceso que llama se retarda hasta que el servidor ha sido
ha sido regresado y asignadoa
los argumentos
completado y hasta que elresultado
resultantes.
llamada servicio(arg-valor; arg-resultado)
en donde servicio es realmente el nombredeun
canaldecomunicación
definido,
comprende tanto
fuente
el
como el destino designados. Si se usa
comunicación
directa, servicio designa el proceso servidor; si la comunicación
es indirecta, (se
usa
puerto)
un
servicio gebe designar el tipo servicio
de
solicitado.
Figura 16. Declaración llamada.
S e especifican dos enfoques básicos para especificar el lado del servidor en la RPC:
1. El procedimiento remoto es una declaración (como un procedimiento en un lenguaje
secuencial) como el mostrado en la Figura 17.
-~
procedimiento remoto servicio(entrada parihetros-valor; salida parrimefms resultado)
cuerpo
fin
Figura 17. Especificación tipo procedimiento de un servidor RPC.
Este tipo de especificación es implementado como un proceso. Este proceso, el servidor,
proceso que llama, los
recibe el mensaje que contiene los argumentosvalordealgún
asignaa los parámetros valor, ejecutaun cuerpo, y entonces regresa un mensaje de
de
los parámetros resultado. La sincronización
respuesta que contiene los valores
190
remoto
shellImplementación
un
de
I_.-
Comunicación
entre procesos
__
"
"
. -.
-
resultante de los envía y recibe, ocurre aún si no hay parámetros valor o resultado.
2. El procedimiento remoto es una declaración de la figura mostrada en la Figura 18.
Esta declaración puede ser colocada en cualquier lugar en el que cualquier otra pueda ser
colocada. La ejecución deesta declaración retarda al servidor hasta que llega un mensaje
resultante de una llamada al servicio. Entonces Fe ejecuta el cuerpo usando los nombres de
los parámetros valor y cualesquiera otras variables accesibles al alcance de la declaración. AI
terminar se envíaun mensaje de respuesta al llamador, el cual contiene los valoresdelos
parámetros resultado. Cuando acepta es usada para especificar el servidor, el procedimiento
remoto se llama rendezvous (encuentro).
Un modelo simple de RPC. El concepto general de R P C puedeser
caracterizado
basándose en el siguiente modelo simple:
Cuando es invocado un proceso remoto:
1 . El ambiente que hace la llamada es suspendido.
2. Los parámetros son pasados a través de la red al ambiente donde el procedimiento esta
para ejecutarse y son copiados al ambiente del procedimiento.
3. El proceso deseado se ejecuta ahí.
Cuando el procedimiento finaliza y produce resultados:
4. Los resultados son pasados de regreso al ambiente que hace la llamada y asignados a
los argumentos resultado, donde la ejecución continúa como si regresara de una llamada
de computadora simple.
1
acepta servicio(entrada parámetros-valor; salida parámetros-resultado) "+ cuerpo
Figura 18. Especificación tipo rendezvous de un servidor R P C .
y Nelson' (1984) para usar
Una posible estructurade
programa propuesta porBirrell
llamadas a procedimientos remotos se presenta en la Figura 19. '
Esta estructura usa el enfoque de fragmentos. Una característica interesante del enfoque
de fragmentos es que no requiere algún cambio en el compilador del lenguaje en el cual está
escritoel
programa quellama.También
tieneel
efecto lateral dequelas
llamadas a
procedimientos remotos son indistinguibles de las llamadas locales a pesar del hecho de que
tienen semánticas de llamada diferentes.
La Figura 19 muestra la relación entre los siguientes elementos involucrados en la llamada
a procedimiento remoto: el cliente, el fragmento-cliente, el paquete de comunicación RPC
~~
~
~~
Birrel A.D. and Nelson B.J. (1984). Implementing RemoteProcedure Calls. ACM Transactionson
Computer Systems, 2(1),pp. 39-59.
191
Capítulo 6
(llamado tambiénrutina
R P C ) , el fragmento-servidor, y el servidor. Además, esta figura
muestra la relación entre los elementos del programa.
Las interacciones de los elementos del sistema se dan como sigue:
1. Cuando el cliente desea hacer una llamada remota, hace una llamada local normal, la
cual
invoca
un procedimiento correspondiente en1 el
fragmento
del usuario. El
procedimiento fragmentado es ligado en el espacio de dirección del proceso cliente.
2. E n este estado, el fragmento-cliente es responsable de dos tareas importantes:
Colocar una especificación del procedimiento destino y los argumentos en uno a más
mensajes.
II. Preguntar a la rutina R P C (la capa detransporte) para transmitir confiablemente al
llamado.
I.
1
d
Mientras tanto, el proceso que llama se suspende esperando el datagrama-resultado.
3. La rutina R P C en la computadora que llama envia mensajes a la computadora llamada,
la cual también corre una rutina R P C .
COMPUTADORA
LLAMADA
LLAMA COMPUTADORA
QUE
Capa de transporte
Figura 19. Loscomponentes del sistema, y su interacción parauna R P C simple. O p l :
ordenamiento deparámetros,generación
del identificador R P C , preparar el reloj para la
respuesta. Op2: desordenar los parámetros, notar
el
identificador
R P C . Op3: ordenar
resultados, preparar el reloj para reconocimiento de la respuesta. Op4: desordenar resultados,
1
enviar reconocimientos.
4. La rutina R P C en la computadora llamada, recibe esos mensajes y los pasa al fragmento
servidor.
5. El fragmento servidor lleva a cabo dos tareas: desempaca los mensajes recibidos y hace
una llamada normal para invocar al procedimiento llamado en el servidor; los parámetros
son pasados de manera normal.
Implementación
192
de
remoto
’un shell
”,”
“,
.
Comunicxión entre Drocesos
6. Cuando la llamada se completa en el servidor, regresa alfragmentoservidor
y los
resultados se regresan al fragmento suspendido de forma normal.
7. El fragmento servidor es responsable de colocar los resultados en uno o más mensajes y
de preguntar a la rutina R P C para transmitirlosconfiablemente a la computadora que
hizo la llamada.
8. La rutina R P C transmite los mensajes a la computadora que hizo la llamada.
9. L a rutina R P C en la computadora que hizo la llamada recibe esos mensajes y los pasa al
fragmento cliente.
O
I .El fragmento cliente desempaca los resultados y los asigna a los argumentos resultado.
Mientras que elambiente
que hizola
llamada es suspendido, otros procesosen
la
computadora pueden (posiblemente) ejecutarse todavía (dependiendo del paralelismo de ese
ambiente y de la implementación RPC). Los únicos procedimientos que saben que la llamada
es remota son los fragmentos.
La rutina R P C es responsablede
datagramas y de la protección.
las retransmisiones, reconocimientos, enrutamiento de
I
La llamada a procedimientosremotos
puede ser vista como unrefinamiento
de las
primitivas envía, obten-solicitud y envía-respuesta, confiables, bloqueantes y estructuradas.
Esto tiene las siguientes ventajas:
1 . Clarifica y simplifica la semántica (lo que facilita la construcción de computaciones
distribuidas).
2. E s una forma de comunicación entre procesos.
3. E s un enfoque general.
I
Así, el mecanismo RPC puede ser usado para proporcionarfacilidades de comunicación
entre procesos entre un proceso cliente simple y un proceso servidor simple. Tal mecanismo
puede ser extendido a un sistema para muchos clientes y muchos servidores. L a facilidad R P C
puede ser usada ensistemas de computación homogéneos y heterogéneos.
RPC para muchos clientes y muchos servidores. Hay dos posibles extensiones. La
primera es una que soporta un tipo de comunicación R P C entre muchos clientes y muchos
servidores. El segundo soporta concurrencia encada computadoraanfitrión,
que son un
anfitrión cliente y un anfitrión servidor. Como resultado:
1 . Un núcleo de cliente puede proporcionar servicios para más de un proceso haciendo una
llamada a procedimientos remotos al mismo tiempo.
2. Un núcleo de servidor puede servir a muchos clientes a la vez.
Ambas extensiones pueden ser implementadas basándose en la idea de canales de cliente,
los cuales conectan al proceso cliente el proceso, servidor, y son usados para secuencializar
las R P C s de varios procesos clientes. El proceso servidor guarda la información acerca de los
canales del cliente usados por los procesos cliente;el no tiene quesaberacercade
los
procesos en sí mismos. Hay unos pocos canales del cliente en cada computadora cliente. Por
sí. Un procesopuedeusar
un canal si esta libre. Una
eso los procesos compitenentre
193
Capítulo 6
I
cornputadora servidor tiene algunosprocesos servidores. Como resultado puedemanejar
solicitudes RPC de mbs de un cliente a la vez, un ejemplo de comunicaciónRPC extendida se
ilustra en la Figura 20.
I
Cliente
Computadora A
Cliente
Computadora B
Figura 20. Canales del cliente y procesos endistintas computadoras.
Como el manejodeprocesos
servidores enunacomputadora
es limitado, ellos son
multiplexados entre los canales delcliente que usa elservidor. El núcleo del servidor asigna un
proceso servidor a un canal de cliente particular para una serie de llamadas a procedimiento
remoto.
Para alcanzar una alta disponibilidad en un sistema distribuido donde las computadoras
tienen características diferentes fueron introducidos los conceptosde tropa y llamada a
procedimiento replicada. Una tropa es un conjunto de réplicas de un módulo ejecutándose
en varias computadoras. Los miembros individuales de una tropa no se comunican entre sí
porque no están conscientes de
la existencia de los otros. Sin embargo, las tropas pueden
comunicarse cada una con otra. La extensión de la llamada a procedimiento remoto básico
para lo comunicación de tropas es una llamada a procedimientoreplicada.
I
Lallamadaaprocedimiento
replicada proporcionacomunicaciónmuchosamuchos.La
semántica de una llamadaa procedimiento replicada es la ejecución de todos los miembros de
la tropa exactamente una vez, esto es, cuando una tropa cliente hace una llamada a unatropa
servidor, cada
proceso
de
la
tropa servidor lleva a
cabo
el
procedimiento
solicitado
exactamente una vez, y cada proceso en la tropa cliente recibe todos los resultados (Figura
21).
Paraalcanzar
la transparenciaenla
replicación, los miembros dela
tropa deben
comportarse determinísticamente, esto es, dos réplicas en el mismo estado deben ejecutar el
mismo procedimientoen el mismo orden, lo que produce los mismos efectos laterales, y
regresa los mismos resultados.
Implementación
de
194
..
”,‘.
.~
_..
un shell remoto
.I. ” ~ - . ~ ~ - . . - , - ”
-.
Comunicacim entre procesos
I
C
O
m
Computadora B
P
U
roceso servido
t
a
d
O
r
a
A
Figura 21. Llamada a proceso replicada.
Parámefros y resultados enRPCs. Los parámetros pueden ser pasadospor valor o por
referencia. El paso de parámetros por valor en la red e fácil: el fragmento copia parámetros
en un mensaje y lo transmite. El paso de parámetros p r referencia (punteros) sobre una red
es más complicado. Un Únicosistema ancho de punteros se necesita para cada objeto que
pueda ser accedido remotamente.
d
Las llamadas a procedimientos remotos requieren la transferencia de estructuras de datos
de un lenguaje de determinado nivel entre dos computadoras involucradas en la llamada. Esto
es llevado a cabo generalmente empaquetando los datos en un buffer de la red enuna
en
la del otro lado. 'Esta operación se llama
computadora y desempaquetándolos
ordenamiento.
Más precisamente, un ordenamiento es un proceso que lleva a cabo tanto el envio de la
llamada como el envío del resultado, en el cual se pueden distinguir tres acciones:
1. La toma de los parámetros a ser pasados a al procedimiento remoto y de los resultados
de la ejecución del procedimiento.
2. El ensamblaje de estos dos pasos en una forma conveniente para su transmisión entre
las computadoras involucradas en la llamada a procedimiento remoto.
Desarrollarlos a su llegada.
Manejo de excepciones.Los parámetros exportados a un procedimiento remoto podrían
contener errores o ser inconsistentes. Si el proceso llamado (servidor) no puede resolverlqs,
esto deberíaser reportado al llamador (proceso cliente). Así, debeser proporcionado un
servicioimportante. Este servicio es llamado manejo de excepciones. Los mecanismos de
manejo de excepciones son dependientes del lenguaje. Sin embargo, existe la necesidad de
un método que distingaentre llamadas correctas e incorrectas. Así, elllamadortiene
que
195
Capítulo 6
verificar cada valor regresado y, cuando .sereporta una falla, puede requerir más información
acerca de esafalla.
lmplemenfacióndeunprocesollamado
y ,unollamador.
Los dosprocesos
involucrados en la llamada a procedimientos remotos pueden
tener tiempos de vida diferentes.
Hay dos implementaciones conceptualmente diferentes del proceso que ejecuta la llamada
remota.
l.El procesollamado existe antesde la llamaday corre continuamente.Esta es una
implementación típica deun
servidor. Así, este procesoescucha si hayllamadas
(mensajes) de solicitud, ejecuta el procedimiento apropiado y regresa una respuesta. Un
servidor de este tipo puede ser llamado por cualquier número de procesos remotos. Las
llamadas se ejecutan secuencialmente. Podria haber uno
o más servidores.
2. Un proceso que ejecuta un procedimiento remoto es creado por cada cliente o por cada
llamadaa procedimiento. Así, resultan múltiples llamadas enlacreacióndeprocesos
para manejar cada una. Todos los procesos pueden ejecutarse en paralelo. El proceso
se muere después deque se completa el procedimientosolicitado.
Enlace cliente-servidor. Normalmente, una RPC esconde los detalles de la localización
de los servidores a los clientes de los clientes (Ilamadores). Sin embargo, en un sistema con
más de un servidor, porejemplo un servidor de archivo yun servidor de impresión, el
conocimientode la localización de los archivos clientes o deun tipo deimpresora es
importante. Esto implica la necesidad de un mecanismo para enlazar un cliente y un servidor,
en particular, enlazar un fragmento RPC al servidor correcto y alprocedimientoremoto
correcto.
1
Birrel y Nelson identifican dos aspectos deenlace:
l.La forma en la que el cliente especifica que desea ser enlazado al servidor (problema de
nominación).
2. Las formas en las que el solicitante (llamador) determina la dirección de la computadora
del servidor (Ilarnado), y la especificación del procedimiento a ser invocado (problema de
direccionamientc;).
1
El enlace puede set- llevada a cabo dedos formas diferentes:
1. Estáticamente. A través de un tercero como un servidor denombres; los clientes y
servidores son procesos del usuario.
2. Dinámicamente. Este enlace es entre un canal del cliente y un proceso servidor, y es
controlado por elservidor que puede localizar su proceso servidor para activar canales.
Es importante saber cuando toma lugar un enlace. La construcción y uso de una aplicación
distribuida basada en RPC se puede dividir en tres fases: tiempo de compilación, tiempo de
enlace y tiempo dellamada.
Tiempo de compilación.
Implementación
de
196
."
__I
...
.. .. ... -
"
"
-
un shell'remoto
~
I
_
.
I
ComunicaciLn entre procesos
1. Los módulos cliente y servidor se programan como si fueran destinados a ser enlazados
juntos.
2. Se produce ttna dsscripci6n do la intorfnco implomontndn pnrn 01 sorvidor. S o protiltc:otl
dos fragmentos: cliente y servidor. El fragmento cliente, que ve al cliente como un
servidor, es enlazado con el cliente. El fragmento servidor, que ve al servidor como un
cliente, es enlazado con el servidor.
3. El fragmento protegeal cliente y al servidor de los petalles de enlace y transporte.
la definición de la
4. Idealmente los fragmentos se producenmecánicamentedesde
interface, mediante un generador de fragmentos.
Tiempo de enlace.
1. Un servidor haceque su disponibilidad sea conocidapara su propia exportación (o
registro) a través de una rutina RPC que soporta el mecanismo.
2. Un cliente se autoenlaza a un servidor específico mediante una llamada que importa su
mecanismo.
3. Las llamadas pueden tomarlugar, una vez que se ha completado el proceso de enlace.
4. Se espera que el enlace pueda llevarse a cabo menos frecuentemente que las llamadas.
Tiempo de llamada.
1. Losfragmentosempleanalgún
protocolo de capa de transporte subyacentepara
transmitir argumentos y resultados confiables entre clientes y servidores.
2. Pueden usarselos diferentes protocolos de la capa de transporte.
3. Las facilidades RPC deberían incluir alguna información decontrol en cada paquete que
se transporta a la pista de estado de unallamada.
Esquemasdeenvio de mensajes. Se analizarán brevemente las aplicaciones que
requieren mensajes pordifusión o por difusión restringida.
El primer problema en el esquema de comunicación uno a uno que se extiende a difusión,
es conectar
dicho
esquema
con
los puertos
de
difusión. Éstos son proporcionados
extendiendo la versión de puerto local a puerto de red, donde los puertos de redson puntos en
una cola en cada computadora(procesador) para mensajes de difusión.
En segundo lugar, las llamadas a puertos dedifusión pueden ser similares a las llamadas a
puertos locales. La diferencia está en el número de computadoras destino y en el número de
respuestas esperadas, que cambia.la manipulación de los valores de las respuestas y de la
elección de puntos deverificación.
El tercer problema está asociado con las respuestas de difusión. Un puerto de difusión que
especifica un valor de retorno espera una de cada computadora. Por consiguiente, un puerto
de difusión con un valor de retorno de tipo T realmente regresa un arreglo de tipo T como
resultado. El tipo de índice del arreglo es de tipo enumerativo y contiene los nombres de todas
las computadoras(módulos del procesadoren el programa).Esto implica que el valor
regresadopor la computadora i puede ser referenciado usandouna notacijn de arreglo
subscripto con índice i.
197
Capítulo 6
rl
nitlcliwlln
1)totAntIln nhlri nnoc:in(la (:o11
In
nnlt1tillUt!n tln lnttllll\nc:lt5t1 (In ttirtmlcitl
10%
puntos 011 los cualos se puededock que la difuslbn terrrlinason los rnlsrnos quepara las
llamadasapuertos locales. La diferencia es quemuchascomputadoras diferentes pueden
tener que llegar a ésos puntos antes deque terminen.
Los mensajes de difusión restringida comparten problemas similares a los de mensajes de
difusión.
Llamadas
procedimientos
a
remotos
ambientes
heferogbneos.
Hay cinco
componentes de una RPC:
1. Soporte en tiempo de compilación, incluyendo el lenguaje de programación, el lenguaje
de descripción de la interface, elgeneradordefragmentos,y
la estructura de
d
fragmentos.
2. El protocolo de enlace.
3. El protocolo de transporte.
4. El protocolo de control.
5. El protocolo de representación dedatos.
1
Servidor XEROX
(Mensajero RPC, es decir, el protocolo XNS para transporte y los protocolos para
enlace, representación de datosy control).
Servidor VAX
Servidor Sun
(RPCde Sun normalizadacon
TCP:
TCP
(transporte), XDR
(representación de datos), y los
protocolos Sun paraenlacey
control).
(RPC de
Sun
normalizada
y
UDP, es decir, UDP (transporte),
XDR (representación de datos),
y protocolos Sunparaenlace y
control).
Figura 22. Emulación HRPC de facilidades RPC múltiples.
Los últimos tres protocolos son empleadx en tiempo dellamada.
Un ejemplo de una implementación en tres computadoras diferentes de un servidor que,
cuando es llamado, responde con una lista de usuarios conectados a la computadora en la
cual reside, se ilustra en la Figura 22.
198
-
Implementación
de
"
"
un shell remoto
La razón de definir claramente las interfaces procedimentales es que se requirió que un
fragmento HRPC (Llamada a Procedimientos Remotos Heterogbnea) y algún componente
del protocolo de control, del de representación de datos y componentes del protocolode
transporte fueron habilitados para funcionar juntos. La interacción de éstos componentes se
ilustra en la Figura 23. Las direcciones de las flechas indican la dirección de las llamadas
durante la porción de la llamada de una RPC.
Semántica de la llamada a procedimientos remotos. Una llamada a procedimientos
remotos puede no completarse satisfactoriamente, esto es, el mensaje resultado no es
regresado al llamador como una respuesta a su mensaje de llamada, porque pueden ocurrir
cuatro eventos, los cuales son la base del diseño de la semántica RPC:
1 . La llamada al mensaje se pierde.
2. El mensaje de respuesta se pierde.
3. La computadora llamada fracasa y se reinicia.
4. La computadora que llama fracasa y se reinicia.
F’,
Servidor
Llamada
RPC
Llamada
RPC
Regreso
de RPC
Fragmento
servidor
cliente
I
\
Mensaje RPC
Transporte
1
Regreso
de RPC
Control
1
Datos
Figura 23. Interacción entre los componentes en tiempo de llamada HRPC.
S e pueden identificar tres semánticas diferentes y susmecanismossepueden
manera general para resolver los eventos anteriores:
tratar de
1. Semántica de llamada posible. Los intervalos de tiempo son usados para prevenir que
199
Capítulo 6
el llamador espere indefinidamente,un mensaje de
respuesta.
2. Semántica de llamada al menos unavez. El mecanismo normalmenteincluye intervalos
de tiempo y un procedimiento de retransmisión de llamada. El llamador intenta llamar al
procedimiento remoto hasta que obtiene una respuesta
o hasta que no puede decirle
que el proceso llamado hafallado.
3. Semtintica de llamada exactamente una vez. El mecanismo para esta llamada incluye
en adición aaquelusadoen
la semántica dellamadauna vez (esto es intervalo de
tiempo y retransmisiones), identificaciones dellamada y una tabla delprocedimiento
llamadoque tiene las llamadas actuales. Esta tabla es usadaparaalmacenar
las
llamadas recibidas por primera vez y los resultados de la ejecución del procedimiento
para esas llamadas.
Protocolosdecomunicaciónespeciales
para RPCs (llamadassimples
y
llamadas complejas). Birrel y Nelsonproponen dostipos dellamadasaprocedimientos
remotos para sistemas de computación homogbneos (algunos de sus elementos pueden ser
usados por sistemas de computación heterogéneos): llamadas simples
y llamadas complejas.
Las llamadas simples son usadas en una
situación donde:
1. Todos los argumentos y todos los resultados puedan ser guardadosen
sencillo.
2. Las
llamadas
sean
hechas
frecuentemente.
un paquete
I
Lacomunicaciónde
la llamada debería
ser
particularmente eficiente. Lasllamadas
complejas se usan donde las condiciones paralas llamadas simples no son cumplidas.
Llamadas simples. Para hacer una llamada, e! proceso que llama envía un paquete de
llamada que contiene: un identificador de la llarnada, especificación dedatosde
un
procedimiento deseadoy los argumentos.
Cuandounacomputadora
apropiado.
llamada recibe este paquete, se invoca al procedimiento
Cuando un procedimiento regresa, el paquete resultante contiene: el mismo identificador de
llamada y los resultados. Dicho paquetese envía de regreso al llamador.
La computadora que transmite un paquete es responsable de retransmitirlo hasta que sea
recibido un reconocimiento, para compensarlos paquetes perdidos.
Llamadas complejas. Las llamadas complejasse hacen en doscasos:
1. En situaciones donde las llamadas duran mucho o donde hay grandes intervalos entre
I
llamadas.
2. Si los argumentos (y/o) resultados son tan grandes que no caben en un paquete simple
(hay que enviar múltiples paquetes).
200
Implamentación
de
un shell remoto
.,..
.
. ~~.
.
~
E n las situaciones donde hay una larga duración delentre llamadas, hay dos estrategias
para retransmisiones y reconocimientos.
La primera de éstas estrategias sigue los siguientes pasos:
1. El transmisor de un paquete es responsable de retransmitirlo hasta que sea reconocido.
2. Cuando el llamador está satisfecho consusreconocimientos,espera
el proceso
resultante.
3. Mientras espera el llamador envía periódikamenteun
paquetedeindagacióna
computadora llamada, la cual espera reconocer el paquete de indagación.
la
La segunda solución requiere de la división de un bloque grande de datos (respuesta y/o
solicitud) en fragmentos. En este caso el sistema se comporta de la siguiente forma:
'
1 . La respuesta y/o solicitud
(argumentos
y/o resultados) son
enviados
en
múltiples
paquetes pero la Mima solicitud lleva un reconocimiento. Evitar los reconocimientos de
fragmentos individuales mejora el reconocimiento.
2. Para eliminar la duplicación, los fragmentos (los múltiples paquetes de datos en una
llamada) tienen un número de secuencia de llamada relativo.
En el caso de que se pierdan los fragmentos se pueden implementar dos soluciones:
1. Retransmitir el mensaje entero.
2. Retransmitir solamente los mensajes omitidos.
Paso de mensajes contra llamadas
a procedimientos remotos. La sintaxis y la
semántica
de
una
llamada a procedimiento
remoto
están en función
del
lenguaje
de
programación usado. Por el contrario, escoger una sintaxis y una semántica precisas para el
paso demensajes esmás difícil que paralas RPCs porque no hay normalizaciones para
mensajes.
I
Cabe hacer notar que desde el
punto
de
vista
del
proceso cliente, las llamadas a
procedimiento remoto son muysimilaresalencuentroremoto
(rendezvous remoto). Esto es
porque ambos involucran llamadas bloqueantes con
paso
de
parámetros
en ambas
direcciones.
Sin
embargo,
la
diferencia entre estos dos sistemas de comunicación se
manifiesta en la implantación de los mecanismos en la parte superior de la capa de transporte
y en el uso de patrones.
1
Comparandola llamada a procedimientos remotos, con el paso de mensajes, la primera
tiene la importanteventaja de que la interfacede un servicioremoto puede ser fácilmente
y tipos de
documentada como un
conjunto
de
procedimientos
con ciertos
parámetros
resultados. Además,desde
laespecificación
de
la
interface, es posible generar código
automáticamente que esconda todos los detalles de los mensajes al programador. Nótese que
una estructura simplificada que ocultalos mensajes reduce el rango de las opciones de
comunicación disponible a las aplicaciones del programador.
E n el otro caso, un modelo de paso de mensajes, muestra cierta flexibilidad no encontrada
20 1
Capítulo 6
I
en los sistemas de llamadaaprocedimientos remotos. Sin embargo, esta flexibilidad es a
costo de la dificultad de preparar documentaciónprecisa de la interface de paso de mensajes.
El problemaescuandodeben
ser usadasestas facilidades. Cberiton' enfatiza que el
enfoquedepaso
de mensajesaparecede
preferencia si se requiere un manejode la
secuenciaciónde las solicitudes. El enfoque RPC aparecepreferentementecuando
hay
beneficios de rendimiento significativos para el manejo desolicitudes concurrentes.
COMUNICACIÓN POR TRANSACCIONES
EN
Únicamente se indicará en que consisten los fundamentosdelacomunicación
por
transacciones en un sistema operativo distribuido; se mencionará en que consiste un socket
(de manera genérica), y en vez de profundizar en este tipo de comunicación, se analizarán en
detalle los sockets en el sistema UNIX, posteriormente.
Los sistemasdecomputación
distribuidos potencialmentesonmuy
confiables por la
posibilidad deproporcionarrecursosredundantesen
diferentes nodos. Sin embargo, la
distribución de recursos redundantes también genera algunos problemasserios, tales como la
escasez de información de estado global, la posibilidad de fallas parciales y el rendimiento de
muchas
operaciones
en
paralelo. Estos
problemas
implican alguna dificultad en el
mantenimiento dela consistencia de los datos.
Otro aspecto de los sistemas de computación distribuida es que una comunicación simple
no siempre puede ser usada para proporcionar interacción entre dos procesos. La interacción
total puede ser una secuencia de comunicaciones y computaciones. En este caso el concepto
de
una
transacción es una
representación
muy conveniente
de
la
totalidad de la
comunicación y de la computación en los sistemas distribuidos.
El concepto de transacción distribuida se puede definir como la ejecución de transacciones
sobre datos almacenados en múltiples particiones y sobre bases de datos replicadas en varios
nodos de la red. Como el procesamiento de transacción distribuida proporciona aplicaciones
con acceso a datos compartidos que son almacenados con una alta integridad de datos y de
disponibilidad, dicho procesamientodebe ser soportadoporuna facilidad de transacción
distribuida eficiente. Esta facilidad se puede definir como una colección distribuida de
componentes que soportan abstracciones normalestales como procesosy comunicación entre
procesos, y la ejecucióndetransacciones
y la irnplementación de objetos en los cuales
pueden ser llevadas a cabo las operaciones.
Una de las partes más importarltes de la facilidad de transacción distribuida es el sistema
decomunicac#ón.Un
sistema tal, debería sermuy
eficiente, enprimer lugar porque se
necesitan transmisiones frecuentes para mantener muchas réplicas de datos, y en segundo
lugar porque se requieren tiempos de respuesta cortos para la transacción de clientes. Un
Cheriton DR.(1988). The V Distributed System. Cornrnunicalions oflhe ACM, 31(3), 314-33.
202
Implerventación de un shell remoto
sistemadecomunicacióndebería
estar seguro de proporcionar servicios de comunicación
convencional tales como datagramas, transferencia de archivos y flujo de datos. Además, las
aplicaciones conacceso a datos almacenadosen varios nodos requieren más facilidades
inusuales para soportar la replicación de datos, cometidos atómicos, una noción de
sistema
ancho coherente de tiempo y protección auténticas de acceso a datos.
Primitivas de comunicación básica para transacciones. E n el área de ciencias de
la computación, en particular en la literatura de bases de datos, la definición de transacciones
es la siguiente: una transacción es una colección abitraria de operaciones delimitadas por dos
marcadores:EmpiezaTransacción y TerminaTransacción y tiene las siguientes propiedades
especiales: atomicidadde fallas,permanencia,secuenciación y una transacción incompleta
que no puede revelar los resultados de otras transacciones.
'
E n los sistemas operativosdistribuidosladefiniciónde
transacción es muysimilar: una
transacción es una interacción, consistente una
en
solicitud (equivalente a
EmpiezaTransacción) y una respuesta (equivalente a TerminaTransacción), tal que un proceso
solicitante requiere un proceso que responda para llevar a cabo una función dada y reportarla
al solicitante. Esto se ilustra en la Figura 24.
Solicitante
Contestante
Envía una solicitud
de transacción
Ejecuta la solicitud
I
Envía
respuesta
a
transacción
una
la
Figura 24. Transacción (ID = ldentificador de la transacción).
Las siguientes primitivassoportan la transacción basadas en un modelo de comunicación
que puede ser usado en un sistema operativo distribuido. El mensaje es enviado, recibido, y
los resultados son enviados al proceso solicitantemediante la ejecución de las primitivas
envíaTReq, obténTReq, y respT respectivamente. (Ver Figura 25).
La transacción debe ser llevada a cabo en presencia de varias situaciones inherentes, por
ejemplo:
203
I
Capítulo 6
l.La solicitud de transacción (Treq) se pierde en la red.
2. La respuesta de transacción (Tresp) se pierde o retrasa en su tránsito.
I
Deben ser activados diferentes mecanismos de recuperación, como intervalos de tiempo y
mecanismos de retransmisión automática para enfrentar estos problemas: el identificador de
transacción ID se usa para prevenir que solicitudes duplicadas sean pasadas al respondiente
de la transacción.
Hay semánticas de protocolos detransacción que aseguran la ejecuciónde la transacción:
1. Una vez exactamente. Se usa si la solicitud no es idempotente; podría ocurrir un daño
serio si se repite la ejecución de lasolicitud.
P
envíaTReq(cabecera,args-valor; args-resultado)
cabecera designa los nombres de unemisor, un receptor, el tipo de servicio
solicitado, el identificador de la transacción, la estructura del mensaje, etc.;
args-valor son los argumentos por valor del emisor; ags-resultado son los
argumentos resultado.
obténTReq(fuente-designada, lista-de-variables)
fuente-designada le dice al programador de donde viene el mensaje. La
srgs-valor y
rista-de-variables.
recepción de un mensaje causala
algunos
de
cabecera
mensaje
el en
asignación de los valores de
a las variables en
1
respT(cabecera, resultados)
cabecera designa los nombres de unemisor, un receptor, el identificador de la
transacción, y otra información relevante para la solicitud. Los resultados
resultados son asignados a los argumentos args-resultado.
Figura 25. Primitivas que soportan transacciones basadas en comunicación.
2. AI menos una vez. Se usa si la solicitud es esencialmente idempotente, por ejemplo, la
ejecución repetida de unasolicitud es la misma que cuando se ejecuta una vez.
Sockets. En los sistemas distribuidos basados en un modelo detransacción, los mensajes
son intercambiados entresockets (fuentes y destinos de mensajes).
Los socketsson
entidades direccionables en los nodosde
una red, identificadospor
204
""
. I".-. .-
""
~
_
_
I
I
"
X
.
"""-
&.
I
números desocket, los cuales podrían ser únicos en unnodo dado.Esto implica que un
identificador no ambiguo para cualquier socket en una red simple puede ser proporcionado por
el número de socket concatenado con el nodo identificador. Si un sistema distribuido consta de
un determinado número de redes de árealocal, entonces la dirección intered de un socket
consta del número de socket, el identificador del nodo (del nodo en el cual está localizado el
socket) y del número de red (de la red en la cual está localizado el nodo).
Los socketsson admitidos por clientes#de sockets (procesos o funciones típicamente
implementados en elsoftware de un nodo). Esto
se ilustra en la Figura 26. Los clientesde
sockets proporcionan código del que se puede decir que pone los sockets a la escucha (el
código que recibe mensajes direccionados al socket). Un socket a la escucha debe ser
registrado; la información acerca de éI se mantiene en una estructura de datos llamada tabla
vistos como puertos en los modelos de llamada a
de socket. Los socketspuedenser
procedimiento y de paso de mensajes.
Hay dos tipos de socket:
Nodo
Cliente de
socket
I
Cliente de
socket
Cliente de
socket
f
Socket
1
Figura 26. Sockets y clientes de sockets.
1. Socketsbienconocidosreservadospara
el uso declientesde
sockets bien conocidos
(por ejemplo, un servidor de archivo solicita a un socket receptor, un nombre de socket
de servicio).
2. Socketsasignados dinámicamente: sonasignados dinámicamente por un sistema en
una llamada a un cliente.
Esto implica que debería haber primitivas para abrirtanto un socket bien conocido como
para uno creado dinámicamente y para cerrar dichos sockets. Además, el socket a la escucha
debería proporcionar un mecanismo parael envío y la transmisión de mensajes.
Ahora se pasarán a estudiar los sockets en el sistema UNIX, para complementar y finalizar
el tema de la comunicación orientada a transacción en los sistemas distribuidos.
205
Capítulo 6
~~~
~
~
THE LOGICAL DESIGN
Addison-Wesley Publishing Company [1991]
Andrej Goscinski
Págs. 133-1 93.
206
_
"
_
"
"
.
I
-"-
CAPITULO 7
I
LOS SOCKETS,
LOS SOCKETS
~
~
~-
[TOMADO Y ADAPTADO DE Rifflet]’
Una de las mayores contribuciones de lasdistribucionesBerkeley
al sistema UNlX es
definitivamente el interfaz de comunicación que hasido desarrollado. Ofrece un mecanismo de
comunicación generalentre dos procesos cualesquieraque pertenezcan a un mismo sistema o
a dos sistemasdiferentes.
La manera más simple deaprender esta noción esla
dehacer el paralelo con la
comunicación de individuos por correo o por teléfono. Cada una de las entidades implicadas
en una comunicación debe disponer de un, punto de contacto: se puede tratar de un buzón o
de un receptor telefónico. Un socket no es otra cosa que el equivalente en el sistema a uno de
estos objetos: se trata de un punto de comunicación por el cual un proceso podrá recibir o
emitir información. La naturaleza de ésta última depende del tipo de punto de comunicación:
de un buzón se extraen mensajes completos, mientras que el teléfono permite el envío de
flujos de información que notienen una estructura claramente definida (su definición se deja a
la interpretación de los interlocutores). Esta dualidad se encuentra en los sockets a nivel de
sus tipos. Otra característica importante de los puntos de comunicación concierne al conjunto
de otros puntos que permiteacceder. Un receptor telefónico interior a una empresa no permite
los otros interiores de la empresa, mientras que un teléfono
la comunicación más que con
exterior permite salir del marco local. De la misma forma, es recomendable dejar en correos los
objetos de los buzones correspondientes a sudestino.La
noción de dominio de un socket
I podrá establecer una comunicación
permite definir el conjunto de sockets con los cuales se
por medio deél.
Aquí se va ha estudiar la interface ofrecida por este mecanismo entre las aplicaciones y los
niveles inferiores a saber; un nivel de protocolo (por ejemplo TCP, UDP o IP) y un nivel de
“pilotos” que permita elcontrol de interfaces físicas con la red.
Antes de entrar en los detalles, cabe indicar que se conservará el término ‘Socket”en vez
de una traducción, tal como toma o punto de comunicación.
CARACTERíSTICAS DE UN SOCKET
Un socket es unpuntodecomunicaciónpor
el cual un procesopuede emitir o recibir
información. En el interior de un proceso, un socket se identificará por un descrlptor de la
misma naturaleza que los que identifican a los archivos (es decir, en el mismo conjunto). Esta
propiedad es esencial, puesto quepermite, por ejemplo, la redirección de los archivos de
entradakalida estándar (descriptores O, 1 y 2) a los sockets y, por tanto, la utilizaciónde
aplicaciones estándar sobre la red. Esto significa también que todo nuevo procesocreado (por
fork) hereda los descriptores de socket de su padre.
La creación de un socket se realizará por medio del comando socket cuyo valor de vuelta
es un descriptor sobre el cual es posible realizar operaciones de lectura y escritura. Un socket
permite la comunicaciónen los dos sentidos contrariamente a la unidireccionalidad de un
cause (pipe).
I
Una diferenciaesencialcon
los archivos es que el “nombrado” de los sockets es ‘una
operación distinta a la de su creación (apertura y creación van a la par como en los cauces,
pero después es posible fijar una dirección de su dominio al objeto creado por medio de el
comando bind).
A cada una de las características deun socket de las que se habla en los párrafos
siguientes le corresponde una constante simb.ólica predefinida en el archivo <sys/socket.h>.
EL DOMINIO DE UN SOCKET
Especifica elformatode
las direcciones quese podrán dar al socket y los diferentes
protocolos soportados por las comunicaciones vía los sockets de este dominio. La estructura
genérica
struct sockaddr {
u short
char
1;
sa family; / * familia de dirección * /
sa7data[l4];/*14
octetosdedirección(máximo)*/
-
se utilizará para describir diferentes comandos.
.
Parauna aplicación particular, esta estructura se deberáreemplazar
correspondiente del dominio de comunicación utilizado:
por la estructura
I
1 . Para el dominio UNlX (AF-UNIX), los sockets son locales al sistema dondehan sido
definidos. Permiten la comunicación interna de procesos. Su designación se realiza por
medio de una referencia UNIX. La estructura de una direccion en este dominio está
predefinida en <sys/un.h>:
struct sockaddr un {
short
sun
family;
char
sun-data[l08];
dirección*/
1;
/*Dominio UN1X:AF U N I X * /
referencia
/*
de
I
l . Para eldominio Internet (AF-INET), las direcciones de los sockets tienen la estructura
sockaddr-in:
210
Los sockets
s t r u c ti na ddr
{
u-l o n g
1;
S -a d d r ;
s t r u c ts o c k a d d ri n
{
short
sl’n f a m i l y ;
u s h osr itn p o r t ;
s t r u c ti na d
addr;
-d r s i n
s i n-zero-[ 8 1 ;
char
/ * La f a m i l i a d e l a d i r e c c i ó n
/ * e l número d e p u e r t o * /
/ * l a d i r e c c i ó nI n t e r n e t * /
/*
un campo d e 8 ceros
AF I N E T /
-
*/
1;
1. Puede existir otro cierto número de dominios:
AF-NS
AF-CCITT
AF-SNA
AF-DECnet
AF-APPLETALK
I* protocolos XEROX NS */
/* protocolos CCITT, protocolos X25, etc. */
/* IBM SNA */
/* DECnet */
/* Apple Talk */
I
EL TIPO DE UN SOCKET
Las propiedadesdeunacomunicación.
El tipo de un socket define un tipode
propiedades de las comunicaciones enlas cuales está implicado.
1
a) La fiabilidad de la transmisión. Ningún datotransmitido se pierde.
b) La conservación del orden de los datos. Los datos llegan en el orden en el que han
sido emitidos.
c) La no duplicación de datos.Sólo llega al destino un ejemplar de cada datoemitido.
d) La comunicación en modo conectado. Se establece una conexión entre dos puntos
antes del principio de la comunicación. A partir de entonces, una emisión desdeun extremo
está explícitamente destinada al otro extremo conectado.
e) La conservación de los límites de los mensajes. Los límites de los mensajes emitidos
se pueden encontrar enel destino.
f) El envío de mensajes “urgentes”. Corresponde a la posibilidad de enviar datos fuera
del flujo normal y en consecuencia accesibles inmediatamente (se habla de datos fuera de
flujo u out of band).
Los tiposdisponibles. Son los siguientes, aunque los dos tipos de socketmás
utilizados, son los dos primeros.
a) El tipo SOCK-DGRAM. Correspondea los sockets destinadosa la comunicaciónen
modo no conectado para el envío de datagramas de tamaño limitado. Las comunicaciones
correspondientes tienen la propiedad e. En el dominio Internet, el protocolo subyacente es
el protocolo UDP.
21 1
Capítulo 7
b) El tipo SOCK-STREAM. Los sockets de este tipo permiten comunicaciones fiables en
modo conectado (propiedades a, b, c y d) y eventualmente autorizan (según el protocolo
aplicado) los mensajes fuera da banda (propiedad f), El protocolo subyacorlto on 01 dorrlilrio
Internet es TCP.
c) El tipo SOCK-RAW. Permite el acceso a los protocolos de más bajo nivel (por ejemplo,
el protocolo IP en el dominio Internet). Su uso está reservado al superusuario. Permite
implantar nuevos protocolos.
las comunicacionesqueposeen
las
d) El tipo SOCK-SEQPAQUET. Correspondea
propiedades a, b, c, d y e. Estas comunicaciones
se encuentran en el dominio XEROX NS.
LA CREACIóN DE UN SOCKET
El comando socket permite la creación de un socket, es decir, la creación e inicialización de
entradas en las diferentes tablas del sistema de gestión de archivos: tabla de descriptores de
procesos, tabla de archivos y estructuras de datos conteniendo las características del socket
(teniendo un papel análogo al de los i-nodos para los archivos). Entre estas características se
encuentran:
1. El tipo, eleldominio
y
protocolo.
I
2. El estado del socket (conectado o no, enlazado, en estado derecibir o emitir).
3. La dirección del socket conectado (si hay alguna): en efecto, al socket se le asocian un
tampón de emisión y uno derecepción.
4. Punteros a los datos (en emisión y en recepción).
5. Un grupo de procesos parala gestión de mecanismos asíncronos.
La forma general del comando que permite
utilizarlo es:
crear un socket y obtener un descriptor Para
i n t socket ( d o m i n i o ,t i p o ,p r o t o c o l o )
/*
i n t dominio;
i n t tipo;
int p r o t o c o l o ;
-UNIX, . . . *
A F I N E T , AF
/ * SOCK DGRAM, SOCK
/*-O:
STREAM,
...
p r o t o c o l op o rd e f e c t o
*/
*/
EN CASO DE FALLO DELCOMANDO SE DEVUELVE EL VALOR -1, EL
TERCER PARÁMETRO ES GENERALMENTE O; EL SISTEMA ELIGE
ENTONCES UN PROTOCOLO POR DEFECTO AL TIPO Y AL DOMINIO DEL
SOCKET CREADO.
LA SUPRESIóN DE UN SOCKET
Un socket es suprimido cuando ya no hay ningún proceso que posea un descriptor para
accederlo. Estasupresión
implica la liberación deentradasen
las diferentes tablas y
212
.. "
.
. . ..
._"
.
.
..-
-
. ..
".~
-.-_--.--_.-,"-."...
I
-
- .".
Los sockets - ..
..^.I".-.
~
-.__
_.
trrlrlporlos' rusorvados por 01ststoma rotaciollados C O I I OI socket. Por tutlto, esta suproslolI es
el resultado de al menos una llamadaal comando close.
ENLAZAMIENTO DE UN SOCKET A UNA DIRECCIóN
Después de su creación, un socket no es accesible más que por los procesos que conocen
su descriptor. Enconsecuencia, sin un mecanismo suplementariode designación, sólo los
procesos que hayan heredadotal descriptor en su creación (mediante el comandofork) podrán
utilizar el socket. El comando bind permite con una sola operación dar un nombre a unsocket:
int bind (sock, p -direccion, lg)
sock;
int
struct
sockaddr
dirección * /
int lg;
* p-direccion;
/ * socket
descriptor
del
/ * puntero
de
memoria
a
*/
.La
/ * longitud de la dirección * /
Parauna utilización enun dominio particular, el puntero p-direccion apunta a una zona
cuya estructura es la de una dirección en ese dominio (sockaddcun para el dominio AF-UNIX
y sockaddr-in para el dominioAF-INET).
El socketnombradodespués derealizarse el comando (valor de retorno O), puede ser
identificado por cualquier proceso por medio de la dirección que se le ha dado sin necesidad
de poseer un descriptor (lo que es a priori imposible si el proceso no pertenece al sistema del
socket). Un cierto número de comandosespecíficos permiten explotar estas direcciones.
N dominio UN/X. Los sockets de estedominio
no se destinan más que a una
comunicación local. Por tanto, les corresponden direcciones locales que son referencias UNIX
idénticas a las de los archivos.
Un socket del dominio UNlX aparecerá despu6s del nombrado en los resultados producidos
por la orden Is con el tipo s. La supresión de una referencia de este tipo es por medio de la
orden rm o del comando unlink.
€I dominio Internet. La conexión a una dirección Internet de un socket de este dominio
necesita la preparación de un objeto que tenga la estructura sockaddr-in. Esto supone en
particular:
1. El conocimiento de la dirección de la máquina local (obtenida por medio de el comando
gethostname' y de la función gethostbyname) o la elección del valor INADDR-ANY.
2. La elección de un número de puerto. Puede tratarse de un puerto que corresponda a un
servicio existente (función getservbyname) con la condición de tener los derechos para
utilizarlo, de cualquier númerode puerto (7= IPPORT-RESERVERD) elegido por el
usuario o dejado a la elección del sistema (basta con dar el valor O al campo sin-port).
Colas.
gethostent en HP-UX.
I
213
En ciertas circunstancias, un procesopuededisponerde
un descriptor deunsocket
conectado o enlazado a una dirección pero sin saber cuSl es (si la conexión ha sido realizada
por otro proceso y el proceso ha heredado el descriptor o si la conexión ha sido realizada sin
especificar el número de puerto).
El comando
int getsockname (sock, p-adr, p-lg)
int sock,
structsockaddr
dirección*/
int *p-lg;
/ * descriptor
socket
del
*p-adr;/*puntero
de
*/
memoriaalazona
/ * puntero de memoria
a
dirección
de
la longitud de la
*/
permite recuperarla dirección relacionada conel socket de descriptor sock.
Cuando se llama a este comando,el
resultado:
tercer parámetrp se utiliza comodato
y como
1. En la llamada, *p-lg tiene como valor el tamaño de la zona reservada a la dirección
p-adr para recuperar la dirección del socket.
2. En el retorno de la llamada, *p-lg tiene como valor el tamaño efectivo de la dirección.
El valor de retorno de elcomandoes O ó -1 según si la llamadaa tenido éxito o no
respectivamente. Entonesla utilización de el comando tiene la forma siguiente:
m
m
struct sockaddr in adr;
int lg, rep, sock;
m
m
lg
sizeof(struct
=
sockaddr
-in);
m
m
rep
=
getsockname ( s o c k , &adr, &lg);
m
m
LA COMUNICACIóN POR DATAGRAMAS
Esta sección está dedicada al estudio de los mecanismos relativos a la comunicación de
procesos por medio de sockets del tipo SOCK-DGRAM (cualquiera que sea su dominio de
definición).
214
Implementación
de
un shell remoto
Los sockets
S e recordarán las principales características de estas comunicaciones:
1 . Cuando se envía un mensaje desde un socket con destino a otro socket, el que lo expide
no obtiene ninguna información sobre la llegada de su mensaje al destino.
2. Los límites de los mensajes son preservados.
La falta de seguridad debido a la primera característica no es más que relativa. Aplicaciones
esenciales (tales como el sistema de archivas
distribuidos
NFS) utilizan este modo de
comunicación (apoyándose en el protocolo UDP dentro del dominio Internet). Las situaciones
de abrazo mortal, de pérdidas de mensajes y de la no recepción de mensajes, necesitanel uso
del mecanismo de temporización (fimeouf).
PRINCIPIO GENERAL
El intercambio de datagramas debe ser realizado por medio de sockets del tipo
SOCK-DGRAM. Un proceso que desee emitir un mensaje con destino a otro debe, por una
parte, disponer de un punto de comunicación local(descriptor del socket sobre el sistema
local) y por otra parte, conoceruna dirección del sistema al cual pertenezca su interlocutor
(esperandoque
este interlocutor disponga de un socket conectado o enlazado a esta
dirección ... este tipo de comunicación no permite estar seguro de ello).
Los sockets de este tipo se utilizan en modo no conectado: en principiotodapeticiónde
envío de un mensaje debe incluir la dirección del socket de destino.
Sin embargo, se verá que es posible establecer una pseudoconexión”entre dos sockets de
tipo SOCK-DGRAM haciendo implícita la dirección del pocket para una emisión.
LAS OPERACIONES DE ENVíO Y RECEPCIóN
El comando sendto.
int sendto(sock, msg, lg, opcion,
int sock;
char *msg;
int lg;
int opcion;
pdest,
lgdest)
/ * descriptor del socketde emisión ” /
/ * dirección del mensaje a enviar
*/
/ * longitud del mensaje * /
/ * = O para el tipo SOCK-DGRAM * /
215
Capítulo 7
struct sockaddr *p
-dest;
i rI i- 1 ~
.
/ * puntero a la dirección del socket
destino * /
/ * l o n q i , t : ~ ~dc?l
d
I n dirí?ccihrl r i e l
J ~t- P
;S
d e s tino
*/
3or:l~:~~l
El valor de retorno de el comando es, en caso de éxito, el número de caracteres enviadosy
-1 encasode fallo. Se insiste en el hechode ‘que los únicos errores detectadosson los
locales. Asi, no hay detección alguna de queun socket esté enlazado a la dirección dada. Esto
significa en particular que si un mensaje se emite con destino a una máquina existente sobre
un puerto no asociado a un socket, el mensaje se perderá y el emisor no será avisado.
Por el contrario, la validez del descriptor sock o de la dirección del mensaje se comprueban.
Incluso, indica un error si el tamaño del mensaje a emitir, debido al protocolo subyacente, es
incompatible con la atomicidad de la emisión (de este modo, para el protocolo UDP utilizado
para este tipo de envío en el dominio Internet,’ un mensaje debe de ser en general de longitud
e2 Kb.).
Es práctico utilizar elcomando sendmsg en el caso que un procesodeba realizar una
sucesión de envíos de mensajes. Elinterés de utilizar este comando es que se realiza el envio
de varios mensajes con una sola llamada al sistema lo, que mejora su rendimiento.
La forma de el comandoes:
int sendmsg (sock, msg, opcion)
int
sock;
struct msghdr msg[ I
int opcion;
;
/ * descriptor
del
socket
emisión
de
*/
/ * tabla de los envíos a efectuar * /
La estructura msghdr está predefinida en -%ys/socket>:
struct msghdr {
caddr-t
msg name;
/ * direcciónopcional * /
msg-namelen;
/ * tamaño de la dirección * /
int
struct iovec
*msg iov; / * tabla de mensajes * /
int
msg iovlenf
/ * número de elementosenmsgiov
caddr-t
msg-accrights; / * l o s sockets no la utilizan-*/
/ * los socketsnolautilizan
int
msg-accrightslen;
1;
*/
*/
La estructura iovec está predefinida en <sys/uio.h>:
struct iovec {
caddr-t iov base;
iov-Ten;
int
1;
/ * dirección del mensaje* /
/ * longitud del mensaje* /
Nota: no es necesario que un socket esté nombrado para que pueda
216
-
Implementación
de
un :$hell remoto
-
ser utilizado para
Los sockets
el IVlkIl u 1 1 Il1t3l I t i t l J t j COI1 el colllkllldo sendlo. Ll
durante el primer envio.
SIStt3l~\kilecillza
autolllállctllIlerllu
S l l CoIleXIDI I
El comando recvfrom.
i n t recvfrom( s o c k , m s g , l g , o p c i o n ,
isnotc k ;
c h a r *msg;
/*
i n lt g ;
/*
i n to p c i o n ;
/*
s t r u c t sockaddr
*/
/ * d e s c r i p t o r d e l socket d e r e c e p c i ó n * /
d i r e c c i ó nd er e c u p e r a c i ó nd e m
l ensaje
recibido * /
t a m a ñdoeels p a c iroe s e r v a d o
a l a d i r e c c i ó n msg * /
O ó MSG PEEK * /
* pe-x p ; p p a r ar e c u p e r a r
l a dirección de expedici6n
/*
i n t *p lgexp;
rleosnugl it tauddod e l
p -e x p , p - l g e x p )
t a m aedñseopl a rcei o
servado
*/
a
p-exp
Y
Este comando permite a un proceso extraer un mhsaje de un socket del cual posea un
descriptor. Para que haya un mensaje, naturalmente es preciso que este socket haya sido
enlazado o conectado a una dirección (o pseudoconectado en su creación con el comando
socketpair, como se verá posteriormente) y que un proceso haya enviado un mensajedespués
de que hayatenido lugar este enlace.
El papel del parámetro /g es el de dar el tamaño del espacio reservado para memorizar el
mensajequeserá extraído. Es preciso no perder de vistaquese
extraerá delsocket un
la información enviadaenuna
sola
mensajecompleto,quecorrespondeexactamentea
operación sendto. La información recibida provendrá de un sólo mensaje y los caracteres del
mensaje se perderán si el parámetro /g es menorque la longitud del mensaje recibido. El
comando devuelve el número de caracteres recibidos (-1 en caso deerror).
En el caso que el puntero p-expsea distinto de NULL, a la vuelta, la zona de dirección
p-exp contiene la dirección del socketemisor. Es esencial en el caso enque la llamada
*p-lgexp contiene el tamaño de la zona reservada a la dirección p-exp; a la vuelta *p-exp
tiene el valor de la longitud efectiva de la dirección. El proceso receptor tiene entonces la
posibilidad deresponder, sihay necesidad de ello, al mensaje recibido pormediode
el
comando sendto (recuérdese que los sockets permiten la comunicación enlos dos sentidos).
Esto queda esquemáticamente en el
dominio Internet:
O
O
s t r u c t s o c k a d d r i-n
adr;
i n t s o c k , n ,l g ,l g r e p ;
c h a r msg [lo241 , r e p [ 1 0 2 4 J ;
O
O
lg = s i z e o f ( s t r u c t s o c k a d d r i-n ) ;
msg,
1 0 2 4 , O , & a d r ,& l g ) ;
n = recvfrom(sock,
O
I
217
Capítulo 7
O
sendto(sock, rep, lgrep, O ,
& a d r , lg);
a
O
La opción MSG-PEEK permite consultar el socket: se lee un mensaje, pero no se extrae
comocaso
es el
sin esta opción.
I
El comando recvmsg permite realizar una serie de recepciones de mensajes:
i n t recvmsg ( s o c k , msg, o p c i o n )
i n t sock;
s t r u c t m s g h d r msg [ I ;
i n to p c i o n ;
/*
/*
e l s o c k e t de r e c e p c i ó n * /
l a s e r i e de o p e r a c i o n e s * /
LAS “PSEUDOCONEXIONES”
Este mecanismo permite simplemente alegar laescritura de aplicaciones en el caso de que
un socket de tipo SOCK-DGRAM no se utilice más que para comunicar sólo con el otro. Sin
embargo, es necesario tener en cuenta que una pseudocomunicación de
este tipo no modifica
en algo las características generales del modo de comunicación (en particular en lo que se
refiere a su fiabilidad).
N comando connect. Utilizada con sockets del tipo SQCK-DGRAM, permite asociar un
socket de dirección a un socket local (dado por su descriptor). Se verá que tiene un papel
diferente con los sockets SOCK-STREAM.
El comando connect tiene como formageneral:
i n t connect(sock, p-a d r , l g a r d )
i n t sock;
s t r u c t s o c k a d d r *p-a d r ;
i n t lgadr;
’ / * descriptor d e l socket l o c a l * /
/* puntero a l a d i r e c c i ó n d e l socket
/*
asociado * /
l o n g i t u d de l a d i r e c c i ó n
*/
Después de la pseudoconexión”de un socket a otro, todas las emisiones de mensajes, vía
el primero, tendrán como destino el segundo, que no podrá recibir más que los mensajes que
provengan del otro. Es importante notar que esta pseudoconexión es local; no tiene incidencia
alguna sobre el socket del cual se ha dado la dirección (la dirección del socket remoto está
memorizada en la estructura asociada al socketlocol). Un segundo parámetro igual a NULL en
una llamada a el comandoconnect suprime una asociaciónanterior.
218
Implementación
de
un shell remoto
Los sockets
N comando socketpair. Permite crear dos sockets y asociarlos.
socketpair (dominio,
int
int
int
int
dominio;
tipo;
protocolo;
*p- sock;
tipo,
/*
protocolo,
-sock)
p
AF U N I X * /
/ * SOCK DGRAM, SOCK STREAM
-
-
/ * o */-
*/
/ * tabla de dos enteros * /
I
Las operaciones. Como la dirección de destino o de origen es implícita, es posible utilizar
los comandosdeentradalsalidausuales
read y write. Además existen doscomandos
específicos del interfaz socket: recv y send:
int send (sock, msg, lg, opcion)
/ * descriptor del socket local* /
/ * dirección de memoria del mensaje * /
/ * longitud del mensaje * /
/* = o */
int sock;
char *msg;
int lg;
int opcion;
y también
int recv (sock, msg, lg, opcion)
int sock;
char *msg;
int lg;
int opcion;
/ * dirección de memoria para guardar el mensaje* /
/ * longitud de la zona reservada a la dirección msg * /
/ * = O ó MSG-PEEK * /
Los parámetros son idénticos a los cuatro primeros de los comandos sendto y recvfrom.
LA COMUNICACIóN EN MODO CONECTADO
Es el modo utilizado por las aplicaciones estándar de la familia Internet tales como teinet,
ftp, o aplicaciones UNIX como rlogin. Aporta la fiabilidad a intercambios de información con el
precio de un incremento de su volumen.
PRINCIPIO GENERAL
Como indica el nombre de este modo de comunicación, es necesario para utilizarlo realizar
219
Capítulo 7
unaconexión (establecer un bircuito virtual') entre dos puntos. Mientrasqueelmodode
comunicación sin conexión que se ha estudiado previamente presentaun aspecto simétrico en
la medida en que el 'Jniciadot'del diálogo puede ser cualquiera de los dos que intervienen, el
establecimiento deunaconexiónen
el modo conectado aclara la asimetría entre los dos
procesos implicados. Uno de los dos procesos (en posición de cliente) pregunta al otro (en
posición de servidor) si acepta esta comunicación. Se encuentra aquí la analogía que se ha
hecho al principio conlacomunicaciónpor
correo y por teléfono. Conelprimer
tipo de
comunicación, cuando se ha franqueado una carta, el que la envía no tiene control sobre lo
que pasa, a lo más puede esperar que le llegue una respuesta después de un cierto lapso de
tiempo.
Las características importantes de la comunicación eneste modo son:
1. La fiabilidad.
2.El aspectocontinuode
la información (flujo'): el receptor no tiene la posibilidad de
encontrar (salvo información y protocolo particular establecido entre los dos procesos) la
estructura de la información enviada.
Para traducir el aspecto asimétrico inicial que
se
ha
mencionado,
se presentará
sucesivamente el punto de vista del servidor y el del cliente en la fase inicial, además de los
mecanismos
generales
utilizables por los dos
procesos
en
la fase
de
comunicación
propiamente dicha, donde reaparece la simetría.
I
EL PUNTO DE VISTA DEL SERVIDOR
Su papel es pasivo en el establecimiento de la comunicación: después de haber avisadoal
sistema al que pertenece que está preparado para responder a las peticiones de servicio, el
servidor se pone a la espera de peticiones de conexión que provengan de clientes. Para ello
dispone de un socket de escucha, enlazado al puerto TCP correspondiente al servicio, sobre
el que espera las peticiones de conexión. Cuando llega al sistema una petición de es tipo, se
despierta al proceso servidor y se crea un nuevo socket;es este último, al que se llamará
socket de servicio, el que se conecta al cliente. Entonces el servidor podrá, por una parte
delegar el trabajo necesario para la realización del servicio a un nuevo proceso (creado por
fork) que utilizará entonces efectivamente la conexión y, por otra parte, retomará su Vigilia"
sobre al socket de escucha.
El esquema general de funcionamiento deun servicio se presenta en la Figura 1.
No se volverá sobre la primera etapa cuyo objetivo es si
punto de comunicacióndireccionable desde el exterior.
plemente dotar al servidor de un
I
El comando listen. Este comando permite a un servidor señalar a un sistema que acepta
las peticiones de conexión.
I
220
Implementación de unshell remoto
Los sockets
I '¿lid Iltllllal COI I 6Xlh.l tl el COllltll Id0 I1S)ell ((101 kllll0, COI1 VkilOl dt3 It5101 I IO O), t!l IJl01;eSll
debe disponer de un descriptor de socket del tipo SOCK-STREAM. Si el socket no está
previamente enlazado a un puerto, el sistema procede a este enlace. E n este caso, será
necesario hacer una llamada a el comando getsockname para conocer el número del puerto
atribuido. El comando tiene la forma siguiente:
int listen (sock,
nb)
int sock;
/ * descriptor del socketde escucha * /
int nb; / * número máximo de peticiones de conexión p e n d i e n t e s * /
Creación y enlace del socket de escucha
socket/bind
Apertura del servicio
I
listen
V
Espera de demanda de conexión
accept
V
Creación de yn subproceso
fork
PADRE
HIJO
V
I Tratamiento de la demanda 1
Figura 1 . Funcionamiento general del proceso servidor.
I
El segundo parámetrodefineeltamatiode
un archivo en el cual se memorizan las
conexiones de petición formuladas, preparadas (desde el punto de vista de los clientes están
establecidas) pero todavía no notificadas al servidor. El tamaño del archivo está limitado a un
cierto valor por el sistema (en general 5; en HP-UX20).
N comando accept. Este comando permite extraer una conexión pendiente en el archivo
asociado aun socket para el cual se ha realizado una llamada, a listen. De esta manera, el
sistema toma conocimiento de un enlace realizado. Como se ha dicho, el enlace con el socket
22 1
Capítulo 7
del cliente se realiza con un nuevo socket cuyo descriptor se envia como resultado de la
función:
i n t a c c e p t ( s o c k , p -a d r , p - l g a d r )
i n t sock;
structsockaddr*p
i n t * p-l g a d r ;
-a d r ;
/* descriptor d e l socket */
/ * d i r e c c i ó n d e l s o c k e tc o n e c t a d o * /
/ * p u n t e r o a l tamaño d e l a z o n a reservada a
p-adr * /
El socket de servicio creado se enlaza a un nuevo puerto (tomado del conjunto de puertos
no reservados).
A la vuelta, también se recupera en memoria, en la zona apuntada por p-adr, la dirección
del socket del cliente con el cual se. ha establecido la conexión. El valor de *p-lgadr se
modifica: si en la llamada era el tamaño de la zona reservada para guardar la dirección, en el
retorno da el tamaño efectivo de la dirección.
I
E n el caso en el que no exista ninguna conexión pendiente en el archivo, el procesose
bloquea hasta que exista una (io hasta que llegue una señal!) a menos que el socket esté en
modo no bloqueante. E n este último caso, el comando devuelve el valor -1.
N subfrafamiento del servicio. Despuésde
laaceptaciónde
servidor tiene dos posibilidades:
la
comunicación, el
1 . Hacerse cargo de ella: lo que significa eventualmente que otras conexiones pendientes
no serán efectivamente aceptadas hasta que el servicio demandado haya sido satisfecho
(a menos que se utilice
un
mecanismo
asincrono,
de los cuales se hablará
posteriormente).
2. Subtratar la gestión de la conexión y la realización del servicio mediante un proceso hijo.
EL PUNTODE VISTA DEL CLIENTE
Un cliente es la entidad activa en el establecimientode una conexión: es el que toma la
iniciativa de la demanda de conexión a un servidor.
Esta demanda se realiza por medio de el comando connect de la que ya se ha hablado
para el establecimiento depseudoconexionesde
sockets del tipo SOCK-DGRAM. Sin
embargo, aquí la
semántica
de
el comando es completamente diferente:
solicita
el
establecimiento de una conexión que será conocida por los extremos. Además, el cliente está
informado del éxito o del fracaso de la conexión.
La organización general de un cliente se presenta en la Figura 2.
El comando connect. Toda conexión entre dos sockets del tipo SOCK-STREAM, en un
dominiodistinto del UNIX, es el resultado de una llamada con éxito a este comando (en el
Implementación
de
222
"."h.._"."
remoto
un shell
I
Los sockets
dominio UNIX, una llamada a socketpair crea un par de sockets conectados). Así, se crea un
los dosprocesoscuyos extremos son los sockets. Este circuitopermite
circuitovirtualentre
cambios bidireccionales.
La forma de el comandoes idéntica a la que se ha dadopara
sockets dedicados al intercambio de datagramas.
la pseudoconexión de
Creación (y eventualmente enlace de un socket)
socket/blnd
I Construcción de la dirección del servidor
. _ _ . . _ _.._. ._
. . ._ _ _ .
I
....
Fallo....’.
L.
Figura 2. Organización general de un cliente.
I
i n t connect ( s o c k , p-adr,
s o c ikn; t
s t r u c ts o c k a d d r* p - a d r ;
l ignatd r ;
lgadr)
/* descriptor d e l socket local */
/ * d i r e c c i ó nd e ls o c k e tr e m o t o
*/
/ * l o n g i t u d d e l a d i r e c cr ieómno t a
*/
El socket correspondiente aldescriptor sock será conectado o enlazado a una dirección
local, en el caso de que no lo estuviera ya previamente.
La conexión puede establecerse (y el comando connect devuelve el valor O) si se cumplen
las siguientes condiciones:
1 . Los parámetros son localmente correctos.
2. La dirección *p-adr se asocia a un socket del tipo SOCK-STREAM en el mismo dominio
que el socket local de descriptor sock y un proceso (servidor) tiene solicitado escuchar
sobre este socket (por una llamada a listen).
223
Capítulo 7
3. La dirección "p-adr no está utilizada por otra conexión.
4. El archivo de conexiones pendientesdel socket distante o remoto no está lleno.
En caso de éxito (valor de retorno O de el comando connect), el socket local sock está
conectadoa un nuevosocket y la conexión está pendientehastaque
el servidor tenga
conocimiento de ella a través de el comando accept. Sin embargo, el cliente puede comenzar
a escribir o a leer del socket.
En el caso de que no se cumpla alguna de las condiciones 1, 2 ó 3, el valor devuelto por el
fallo.
comando es -1 y la variable errnu permite conocer la razón del
El comportamiento de el comandoes particular si no se cumple la condición4:
1. Si el socket es de modo bloqueante, elproceso se bloquea. La petición de conexión se
repite durante un cierto tiempo; si al cabo de ese lapso de tiempo la conexión no se ha
podido establecer, el proceso es despertado (valor devuelto -1 y errno = ETIMEDOUT).
2. Si el socket es de modo no bloqueante,la vuelta es inmediata (ermno = EINPROGRESS).
Sin embargo, la petición de conexión no se abandona en seguida (se repite durante el
mismo lapso de tiempo). El proceso debe,saber si la conexión se ha establecido por
select, el descriptor del socketforma parte de los descriptores
mediodelcomando
comprobados en escritura. Finalmente, en caso de que se realice una nueva solicitud de
conexióndelmismosocket
(por unallamadaa
connect) antesdeque
se haya
abandonado la petición anterior, la vuela de el comando es igualmente inmediata con
errno = EALREADY.
EL DIALOGOCLIENTEISERVIDOR
1
Una vez establecida la conexión entre un servidor y un cliente a través de dos sockets, los
dos procesos pueden intercambiar flujos de información. A diferencia de lo que pasa en la
comunicaciónpordatagramas,
el corte en diferentes mensajesno está preservado en el
socket destino. Esto significa que el resultado de una operación de lectura puede provenir de
la información resultado de varias operaciones deescritura. Además, en el caso delos sockets
del dominio Internet, una petición de escritura deunacadenade
caracteres larga, puede
provocar el partido de esta cadena, siendo accesibles los diferentes fcagmentos por el socket
destino. En este caso, laúnica garantia queproporcionael
protocolo TCPesque
los
fragmentos son accesibles en el orden
correcto. Esto implica que la sincronización de una
recepción y unaemisiónenunaconexiónde
un mismo númerodeelementosno
está
asegurada por este mecanismo.
La emisión. La escritura sobre un socket conectado es directamente realizable por medio
de el comando estándarwrite:
224
1
Implementación
de
un shell remoto
Los sockets
int wrife(sock, msg, l g )
int sock;
char *msg;
int lg;
/ * descriptor
del
socket
local
*/
/ * dirección de memoria del mensaje a envjar * /
/ * longitud delmensaje * /
Sin embargo, una operación de este tipo no perm’te utilizar plenamente los mecanismos
ofertados por los protocolos particulares (por ejemplo, ara el protocolo TCP, la posibilidad de
enviar informaciones urgentes). E n el casoen que desee explotar estas posibilidades, es
necesario utilizar el comando send:
b
int send (sock, msg, lg, opcion)
int sock;
char *msg;
int lg;
int opcion;
/ * dirección de memoria del mensaje a enviar
*/
/ * longitud del mensaje* /
/ * O ó MSG-OOB * /
El uso de este comando con elvalor O para el parámetro opcion es equivalenteal de el
comando write (el uso de la opción MSG-OOB se verá más adelante).
L a escritura en un socket bloquea el proceso que la realiza en el caso de que se dé alguna
de las dos condiciones siguientes:
1. El tampón de recepción del socket destino está lleno.
2. El tampón de emisión del socket está lleno.
Sin embargo, un socket puede convertirse en no bloqueante mediante una llamada a una
de los comandos iocti ó fcntl. El valordevuelto es elnúmero de caracteres emitidos (-1 en
caso de error).
La recepción. Igual que para laemisión sobre un socket, es posible utilizarel comando
estándar de lectura:
int read (sock, mag,lg)
int sock;
char *msg;
int lg;
/ * dirección de memoria para grabar el mensaje* /
/ * longitud de la zona reservada a la dirección
msg * /
y el comandorecvque
permite,
por
una parte, la extracción de información
urgente
(MSG-OOB) y, por otra parte, la consulta sin extracción (MSG-PEEK):
int recv (sock, mag, l g , opcion)
int sock;
char *msg;
int lg;
int opcion;
1
/ * dirección de memoria para grabarel mensaje * /
/ * longitud de la zona reservadaa la dirección msq * /
/* O
-
ó MSG-PEEK ó MSG OOB
*/
225
Capitulo 7
Estos diferentes comandossonbloqueantes, salvo solicitud contraria: si no llega algún
carácter al socket (y la conexión todavía está establecida), el proceso lector está bloqueado.
Es necesario insistir en el hecho de que el proceso será despertado cuando llegue por lo
menos un carácter al socket. El parámetro /g especifica el número máximo de caracteres a
leer
(se trata, de hecho, del tamaño dela zona reservada ala direcci6n rnsg).
I
N corte de /a conexión. Las cosas son un poco más complicadas por el hecho de que el
protocolo subyacente (TCP en el dominio Internet) se supone que garantiza la fiabilidad de la
transferencia. En estas condiciones, una llamada a el comando close con un descriptor de
socketnopuede
suprimir demodo brutal el socketcorrespondiente y liberar el espacio
reservado para los datos cuya emisión ha sido solicitada, pero que todavía no se ha realizado
(es decir, todavíaestánalmacenadosen
los buffers locales). Estasupresión tiene lugar
U
posteriormente.
I
Además, si la conexión se ha cortado en la lectura en el otro extremo, una tentativa de
escritura provocará la recepción de laseñal SIGPIPE.
El comando
i n t shutdown (desc, sens)
i n t desc;
i n t sens;
/ * descriptor de socket * /
/* o , 1 6 2 */
permite a un proceso especificar que ya no se desea recibir (sens = O), emitir (sens = 1) o ni
recibir ni emitir (sens = 2) sobre un socket conectado dedescriptor desc.
LA SEÑAL SIGIO
Es posible utilizar laseñal
SlGlO para avisar a un (o varios) proceso(s)que
llega
información a un socket determinado. A cada socket se le asocia un pseudodispositivo capaz
los procesosde un grupodado.Lasetapasa
seguir para
de emitir esta señalatodos
desencadenar este mecanismo son:
I
l . Definir un gestor (handler) para la señal SIGIO.
2. Solicitar el envío de la señal SlGlO en cada llegada de caracteres (llamada a el comando
fcntl con la orden FASYNC).
3. Atribuir un grupo propietario alsocket(llamadaaelcomando
ioctl conlaorden
226
Implementación
de
un shell remoto
Los sockets
SIOCSPGRP) o a el comando fcntl con la orden F-SETOWN.
El conjunto de operaciones corresponde al siguiente esquema:
,
#include <signal.h>
#include <fcntl.h>
#include <sys/sockio.h>
#include <sys/filio.h>
int sock;
/ * gestor de la señal S I G I O * /
hand- io
() ;
I
O
m
I
main ( )
t
int on = 1 ;
signal ( S I G I O , hand-io) ;
m
m
fcntl (sock, F-SETOWN, getpid ( )
ioctl (sock, FIOASYNC, &on) ;
) ;
V
LA TOMA EN CUENTA DE MFNSAJES
URGENTES
Los caracteres enviados con destino a un socket conectado constituyen un flujo continuo.
Un carácter no puede ser leído más que cuando todos los que le preceden ya lo han sido. En
un cierto número de operaciones (por ejemplo en
un
login remoto), este modo de
funcionamiento
no
es totalmente satisfactorio, ya que n o , permite tener en cuenta
227
Capítulo 7
inmediatamente ciertos caracteres. Así,. si en una conexión se utiliza una sesión de .trabajo
remota correspondiente a la Figura 3 y se ha enviado el flujo de caracteres bouc <CR> corn
<CR>, la lectura por el proceso remoto de la secuencia corn <CR>no tiene lugar hasta el fin
del proceso que ejecuta la orden bouc. En el caso de que este proceso entre en un bucle, es
necesario poder interrumpirlo y, por tanto, disponer de un mecanismo que permita el transporte
decaracterescuya llegada se notifique al proceso destino paraque los tengaencuenta
inmediatamente. El protocolo TCP prevé la posibilidad de transmitir (al menos) un carácter con
esta propiedad. Su realización en UNlX corresponde a la noción de datosOOB (out of band) y
el asincronismo se obtiene por medio de una señal particular (SIGURG) que acompaña a la
llegada de tales caracteres.
E/ aspecfo de /a emisión. Se realiza sobre un socket del tipo SOCK-STREAM del
el
dominio Internet (apoyándose,pues,enel
protocolo TCP) conectadopormediode
comando send y de la opción MSG-OOB.
En la implantación UNlX sólo se ha conservado un carácter urgente; como consecuencia, si
en el curso de un send se envían n caracteres con la opción MSG-OOB, sólo el último será
considerado como tal, los n-1 primeros serán accesibles en el flujo normal. Así, con la llamada
send (S, %bcd’i4), los caracteres a, b y c son ordinarios y el carácter d es considerado como
urgente y, por tanto, accesible en el otro extremo de la conexiónfuera del flujo normal.
-
1
P
Sesión
remota
shell
.
socket conectado
Aplicación
local
4-
-
Terminal
I
Figura 3. Mensajes urgentes.
E/ aspecfo de /a recepción. El sistema puede memorizar un carácter 0OB”para cada
socket. En principio, este carácter sememoriza fuera de los tampones utilizados para los
caracteres ordinarios. Sin embargo, es posible forzar al sistema para introducir estos
caracteres en el flujo normal. Así, a la llegada de un carácter OOB, el carácter precedente que
tuviera esta característica no se pierde: solamente pierde su aspecto urgente y se convierte en
accesible dentro del flujo normal. Además, el sistema localiza gracias a una marca la posición
lógica (en el flujo) del carácter urgente. A continuación, se describen los comandosque
permiten la manipulación desdeel punto de vista del receptor de los caracteres OOB.
La lectura. La lectura de un carácter OOB no puede realizarse más que por el comando
recv (o recvfrom) utilizando la opción MSG-OOB. Es necesario hacerciertas observaciones:
I
1. No es necesario estar sobre la marca que indica el carácter urgente para poder leerlo.
Además, los caracteres que le preceden nose pierden.
Una lectura sin la opción MSG-OOB tropieza contra la marca; así, si el flujo contiene a b c
d e f g h, y el carácter e está indicado (como carácter OOB), después de la llamadarecv(sock,
ch, 6) la cadena tendrá comovalor “a b cd”.
Implementación
de
228
-...
_L
”“-.“”m.-
un shell remoto
-.
Los sockets
I
La búsqueda de la marca. Es posible comprobar mediante el comando ioctl y la operación
SIOCATMARK si la posición actual en el flujo de caracteres corresponde a un carácter OOB.
/ * #+include<sys/ioctl.h> para
BSD * /
/ * #include<sockio.h> para SYSTEM V * /
O
O
int
marca;
O
O
ioctl (sock, SIOCATMARK, &marca);
/ * marca
=
1 e marca esperada * /
O
O
I
El vaciadode todos los caracteres que precedena la marca (quecorresponde
operación de vaciado del tampón de lectura) se realiza por medio de una funcion.
a una
Toma en cuenta del asincronismo. La función a la que se ha hecho alusión en el párrafo
anterior se supone que se llama sólo cuando hay un carácter urgente para leer en el socket de
descriptor dado. De hecho constituye el gestor correspondiente a la señal SIGURG (aparte de
la recuperación del carácter OOB que debe realizarse en memoria en zona estática y no como
resultado de la función). E n efecto, es posible solicitar la emisión de esta señal por el sistema
cada vez que llega un carácter urgente a un socket. Para convertir el mecanismo en activo, es
preciso:
1 . Definir un manejador para la señal SIGURG.
2. Definir el conjunto de procesos relacionados.
El esquema general correspondiente es el siguiente:
#include<signal.h>
#include<fcntl.h>
#include<sys/sockio.h>
#include<sys/filio.h>
I
int sock;
/ * gestor de laseñal SIGURG * /
hand-urg ( ) ;
I
O
O
1
229
Capítulo 7
I
main ( )
I
int on = 1;
Signal (SIGURG, hand-io);
o
6
fcntl (sock, F SETOWN, getpid ( ).) ;
o
O
1
LA PARAMETRIZACIÓN DE SOCKETS
En la mayoría de los mecanismos relacionados con el asincronismo de los que ya se ha
hablado(operaciones no bloqueantesy relaciones con las señales SlGlO y SIGURG), los
comandos getsockopt y setsockopt permiten obtener información general sobre un socket o
modificar el comportamiento.
El comando
int getsockopt (desc,
desc;
int
intnivel;
int
opcion;
char *p arg;
int *lg;
nivel,
/*
/*
/*
/*
opcion,-arg,'
p lg)
/ * descriptor
socket
del
*/
niveldeaplicacióndelaopción
*/
opción
a
aplicar
*/
puntero para recuperar el valor * /
a la entrada: tamaño reservado
a la vuelta: longitud del resultado* /
permite consultar el valor de una opción del socket descriptor desc. En general, las opciones
se manipulan en el nivel del interfaz con los sockets. Entonces el valor del parámetro opcion
es SOL-SOCKET (sin embargo, es posible darle a este parámetro el número de un protocolo
obtenido por medio de
la función getprotobyname para que la toma en cuenta
sea a otro
nivel).
La modificación del valor de una opciónse realiza por el comando
int setsockopt (desc, nivel, opcion,p--arg, lg)
int desc;
int nivel;
int opcion;
char
*p
arg;
int *lg;
/*
/*
/*
/*
Implementación
de
230
.
".
._._I
/ * descriptnr del socket* /
nivel de aplicación de la opción * /
opción a aplic-ar * /
puntero al argumentode la opción * /
longitud del argumento* /
I
.
L
I
I
x
-I_.
,"."
un shell remoto
"
Los sockets
I
Consúltese el apéndice de llamadas a
opciones.
sockets para ver información sobre las diferentes
LOS PROBLEMAS DE SEGURIDAD
Independientementedequeseanejecutados
todos ala vez o únicamentecuando son
un propietario (para los demoniosejecutadospor
“lntetd’:
útiles, los demoniosposeen
precisadosenel
archivo inetd.conf y‘para otros, es el usuario que los haya lanzado). A
menudo se trata del usuario roof (de identificación O). Esta característica se imponepor
evidentes razones de seguridad de modo que
un usuario que llama a un servicio peligroso (por
ejemplo que realice escrituras sobre el disco) se identifique sobre el sistema donde se ejecuta
el servidor correspondiente.
Esta identificación puede ser implícita (por ejemplo rth ó rcp) o explícita (por ejemplo ftp).
Cuando existe esta identificación, el proceso servidor (o más exactamente el subproceso
que trata la petición) debe modificar la identidad de su propietario (y eventualmente de su
grupo de propietario) por medio delos comandos siguientes.
System V.
int setuid (uid)
/ * identificacióndelnuevopropietario
intuid;
*/
int setid (gid)
int gid; / * identificación del nuevo grupo propietario
*/
I
BSD.
setreuid ( ruid,
euid
)
int ruid;
int euid;
/ * identificación del nuevo propietario real * /
/ * identificación del nuevo propietario efectivo
*/
231
Capítulo 7
I
setregid (rgid,
egid)
/ * identificación del nuevo grupo propietario real* /
/ * identificacióndelnuevogrupopropietario
int rgid;
int egid;
efectivo * /
Si el propietario del proceso es el superusuario, los valores de los ‘parámetros pueden ser
cualquiera. E n caso contrario, el comando setreuid permite no cambiar más que uno de los dos
propietarios dándole el mismo valor que el otro, y el comando setregid hace lo mismo a nivel
de grupos propietarios.
McGraw-Hill [1992]
J,ean-Marie Rifflet
Págs. 233-238,
240-245, 251
259-263,
267-272,
-256,
274-276.
remoto
un
de
232
.
._“
~
“
1
1
”
_
-“
l
.
CAPÍTULO'8
UN
SHELL
REMOTO
a
c
UN SHELL REMOTO
[Cruz, Méndez]'
Este capítulo es el fruto de todo el trabajo efectuado en el proyecto. En primer lugar se da
una breve introducción a la cuestión ¿qué es un shell remoto?. -Posteriormente se identifican
los problemas teóricos que implicados en el desarrollo de un shell remoto y se hace una crítica
de los alcances obtenidos; esto corresponde al trabajo de información e investigación, y al
. desarrollo de la presente documentación.
En seguida seinserta el código fuente de los programas cliente y del servidor, para analizar
y evaluar los logros obtenidosen esta segunda parte del proyecto, y se finaliza con las
conclusiones del mismo.
$UÉ
ES UN SHELL REMOTO?
Un shell remoto es un programa que permite la ejecución de comandos remotos;esto es, si
un usuario está en la computadora A, al ejecutarse el programa cliente en dicha máquina,
puede por ejemplo, teclear Ir, pero este comando desplegará en la pantalla de A, la lista de
archivos y subdirectorios de un directorio de'la computadora B, o de cualquier otra a la que se
tengapermisodeacceder
(en B se debe estar ejecutandoelprograma servidor como un
demonio UNIX). En el caso del shell remoto desarrollado en este proyecto, también se podrán
ejecutar comandos locales anteponiendo alos mismos el carácter I (como en FTP).
I
Capitulo 8
l a SEMESTRE. IDENTlFlCAClÓN DE PROBLEMAS
TE~RICOS
El desarrollo de un shell remoto implica el conocimiento, al menos fundamental, de varias
áreas correspondientes al Brea de Comunicaciones dentro del campo de las Ciencias de la
Computación.Se trata por lo tanto, de un campo muy extenso, siendo esta la principal
dificultad que se tiene que salvar para implementarel shell remoto.
Los temas se abarcan de manera genérica, en el presente trabajo, siendo, como se puede
confirmar en el índice:
1. Protocolos de comunicación.
2..Redes de computadoras.
I
3. El sistema operativo UNIX. .
4. Sistemas operativos distribuidos.
En el caso de la UAM-I, los dos primeros temasse tocan de manera introductoria en el
cursoTransmisiónde
datos': Los dos últimos seven de manera muy breveen el curso
se
vean,
comoen
,nuestro caso. Estas
Sistemas operativos': o es posible queno
circunstancias hicieron que investigáramos y profundizáramos sobrelos temas de protocolos y
redes, y aprendiéramos los fundamentos de UNIX y de los sistemas operativos distribuidos.
Con este panorama general, se procedió a identificar de una manera más concreta, cuáles
serían las herramientasque servirían paraimplementar el shell remotopropiamente.Se
decidió usar sockets, que son en sí un mecanismo de comunicación entre procesos, ofrecido
por el sistema UNIX.
Entonces se investigó sobretemas específicos que auxiliaran en la comprensiónde los
sockets y que proporcionaran un marco de referencia adecuado; estos temas (que son parte
de los mencionados anteriormente) son los siguientes:
Modelo cliente-servidor.
Comunicación entre procesos.
Los sockets.
Un último problema teórico, es el delaprogramación concurrente. Los socketsusanel
modelo cliente-servidor, yenuncaso'real,
si un shell remotono se implantadeforma
concurrente (es decir, si se implanta de formasecuencial), es de muy poca utilidad.
9
236
I
Implementación
de
un shell remoto
Un shell remoto
CRíTICA DE LOS ALCANCES OBTENIDOS
1-1 lrlrrlerlul de strlolnos dlslrIbuldos, protocolos de colllullicuclh, lodes do corllprlrrdorus,
redes de computadoras y sistema operativo UNIX, se encuentra a nivel introductorio en
escasos libros, correspondientes a los cursos de licenciatura. Realmente hay que indagar en
libros para cursos de postgrado, los cuales como es de esperarse se encuentran disponibles
sólo en inglés.
Creemos que el material bibliográfico reunido, es representativo del proyecto que se realizó,
y proporciona un panorama adecuado para abordarlo. La bibliografía se encuentra al final del
trabajo.
h
De manera particular, fueron muy útiles los manuales originales disponibles, para llevar a
cabo el trabajo de codificación en C, y aplicar los conceptos de sockets en el sistema HP-UX;
como este es el sistema operativo al que se tiene acceso en nuestro lugar de trabajo (cubículo
H-I 1 I ) , es el que se utilizó.
Esperamos con esto, ofrecer al lector de esta documentación, bases sólidas para
implementar programas de comunicación en UNIX utilizando sockets.
Agregamos al final del trabajo, apéndices, uno de los cuáles describe, todas las llamadas al
sistema que usan los sockets; otro contiene un resumen de llamadas al sistema que no son
propias de sockets, pero que pueden ser de utilidad al desarrollar programas de comunicación
en el ambiente UNIX. Los apéndices corresponden a la versión 9.0de HP-UX.
Por último, queremos aclarar que se hizo este trabajo de adaptación y traducción, buscando
lograr con ello, tener un material lo más completo, (a nivel introductorio), y coherente posible,
pero sobre todo, que garantice la calidad de la información que proporciona; no fue simple, ya
quesetuvo
que leer, analizar y decidir cuidadosamente, para poder cumplir con éstos
objetivos; si se logra aumentar la velocidad y eficiencia de asimilación por parte de los lectores,
nuestra labor se verá ampliamente compensada.
EL CóDIGO DEL PROGRAMA SERVIDOR
Consta de dos archivos: el de cabecera (Servidor.h'J que contiene las macros y variables
usadas por el programa, el cual se encuentra en el archivo 3ervidor.c:' El programa ejecutable
se llama "servidor".
I
237
I
'
Capitulo 8
I* servid0r.h *I
#include <fcntl.h>
#include <stdio.h>
#include <sys/socket.h>
#include cnetdb.h>
#include <signal.h>
#include <errno.h>
#include <unistd.h>
#define TAM-COM 81
#define PUERTO 4500
#define
CS
100
#defineTAMBUFF512
I* Tamaño máximo del comando recibido del cliente
I* Número de puerto local a utilizar (de escucha)
/* Tamaño de las cadenas que contienenlos nombres
de los hosts cliente y servidor
I* Tamaño del buffer que recibe informacióndel
archivo cliente
int long-dir = sizeof(struct sockaddr-in);
int num-serv = O;
I* Número de servicios proporcionados
FILE *ar;
popen()
por/*usado
Archivo
I* Info. del socket remoto
struct sockaddr-in dir-socket-remoto;
struct sockaddr-in dir-socket-escucha; I* Info. del socket de escucha
char prog-servidor[CS];
I* Nombre del programa servidor
I* Información del host cliente
struct hostent *inf-clien;
I* Informacicin del host servidor
struct hostent *info-serv;
host-serv[CS];
char
/* Nombre del host servidor
char host-clien[CS];
I* Nombre del hosts cliente
/* Hora regresada
por
time()
long hora-fecha;
I* Fecha y hora
devuelta
por
ctime()
char *hora-fecha-inicio;
/* Direqción-red
formato
a
Internet
char *¡net-ntoa();
int des-socket-de-servicio;
int des-socket-de-escucha;
char *ctime();
I* Descriptor del socket de servicio
de
escucha
. I* Descriptor del socket
I* Devuelve un puntero a una cadena
que
contiene
fecha
la
y hora
I* La función setsockopt() varía en las versiones
de la 7.0a la 9.0 de
/* HP-UX. Se utiliza compilación condicional en la función servicio() para
I* ajustarse a las diferentes versiones. Se
debe
compilar
como
sigue:
I* cc -o nombre-ejecutable -D(VER70 I VER80 I VERSO) nombre-fuente
I* Ejemplos:
I
Implementación
238de
un shell remoto
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
*I
Un shell remoto
I*
I*
I*
cc -o servidor -DVER?'O servid0r.c
cc -o servidor DVER80 ser.c
cc -o serv -DVERSO serv.c
*I
*I
*I
ARCHIVO DE CbDlGO SERVIDOR
#include "servidor.h"
/* .....................
programa principal............................
*
* Coloca SIGCLD aSIG-IGN para prevenir la acumulación de zombies, cada que *
* termina un proceso hijo.
*
* Permite extraer una conexión pendiente en elarchivo asociado a un socket,
*
* de esta manera el sistema
se
entera
de
que se ha llevado cabo
a una
* conexión (accept()).
* Se obtiene
información
del
cliente (gethostbyaddro).
*
* La primitiva fork() se usaparahacer el programa concurrente, regresa -1
*
* si huboalgún error; O esregresadoporel
proceso hijo, por lo que se
*
* cierra elsocketdeescucha
y después seejecuta el servicio solicitado;
*
* default indica la presencia del proceso padre. .........................
*I
*
main (argc, argv)
int argc;
I
char *argv[];
{
memset((char *)&dir-socket-escucha, O, long-dir);
memset((char *)&dir-socket-remoto, O ,long-dir);
memset(host-serv, O, CS);
memset(host-clien, O, CS);
strcpy(prog-servidor, argv[O]);.
crea-socket();
if ( gethostname(host-ser, CS) == -1 ){
perror("gethostname()");
exit(1);
1
des-info-ini();
signal(SIGCLD, SIG-IGN);
239
Capitulo 8
for(;;)
{
des-socket_de_servicio=accept(des_socket-de-escucha,
&dir-socket-remoto, &long-dir);
if (des-socket-de-servicio == -I){
perror("accept()");
fprintf(stderr,"No se puede aceptar conexion\n");
exit(1);
1
inf-clien=gethostbyaddr((char *)&dir-socket-remoto.sin_addr,
sizeof(struct in-addr),
dir-socket-remoto.sin-family);
if (inf-clien==NULL)
);
strcpy( host-clien, inet-ntoa(dir-socket-rernoto.sin-addr)
else
strcpy(host-clien, inf-clien->h-narne);
switch (fork()){
case -1 : perror("fork()");
exit(1);
case O: close(des-socket-de-escucha);
servicio();
des-info-fin();
default: close(des-socket-de-servicio);
I
1
} /* for */
1 /* main()*/
........................
crea-socket()
...........................
Seusa AF-INET para el
dominio Internet, y INADDR-ANY
para
*
recibir
conexionesde cualquier máquina. socket() crea el socket de escucha, bind()
lo enlazaauna dirección y listen()lo ponea la escucha. SOCK-STREAM
indica un socket en modo conectado y O en socket() el protocolo por
de la colade escucha.
defecto(tcp). El 5 en listen() indica el tamaño
*
*
*
*
*/
crea-socket()
{
dir-socket-escucha.sin-family=AF-INET;
dir-socket-escucha.sin-addr.s-addr=lNADDR-ANY;
dir-socket-escucha.sin-port=htons(PUERTO);
if ( (des-socket-de-escucha=socket(AF-INET, SOCK-STREAM,
O)) == -I){
perror("socket()");
fprintf(stderr,"No se puede crear el socket de escucha %s\n",
prog-servidor);
exit(1);
1
f
Implernentación de un shell remoto
240
..
I
- ..
."
,_
"
..
I
Un shell remoto
if ( bind(des-socket-de-escucha, &dir-socket-escucha, long-dir)
== -I){
perror("bind()");
fprintf(stderr, "Error al enlazar %S con la direccion\n", prog-servidor);
exit(1);
1
if (listen(des-socket-de-escucha, 5) == -I){
perror("listen()");
fprintf(stderr, "Fallo al poner el socket %S a la escucha\n",prog-servidor);
exit(1);
1
} I* crea-socket() *I
I* ********** Desplegar información al iniciar el programa ************** */
des-info-ini()
time(&hora-fecha);
hora-fecha-inicio = ctime(&hora-fecha);
printf("%s espera aceptar conexion en elpuerto %y: %s...\n",
host-sew, ntohs(dir-socket-escucha.sin_port), hora-fecha-inicio);
} I* des-info-ini() *I
/* ........................
servicio()
............................
* Servicio proporcionado: ejecución de comandos remotos.
* Si se hace una llamada aclose(), y el sockettiene datos por enviar, el
* socket no se cierra, hasta que se transmitan dichos datos al cliente
* (setsockopt): ésta función se compila segúnla versión de HP-UX presente.
* Se recibe el comando del cliente; si rec-com=O, el cliente finaliza; si
* no popen() ejecuta el comando, Finalmente se envía la salida del comando
* ejecutado, al cliente.
* Se cierra el archivo que usa popen()y se contabiliza el número de
* servicios proporcionados por elservidor si no hubo error.**************
servicio()
{
int rec-com;
char comando[TAM-COM];
*
*
*
*
*
*
*
*
*
*I
I* Recibe el comando del cliente */
#ifdef VER70
long linger = 1;
if (setsockopt(des-socket-de-sewicio, SOL-SOCKET, SO-LINGER,
(char *)&linger, sizeof(1ong)) == -I){
perror("setsockopt()");
fprintf(stderr, "Conexion con %S abortada\n", host-clien);
exit(1);
1
#endif
241
Capítulo 8
#ifdef VER80
#include <arpa/inet.h>
static struct linger param={l ,I};
if (setsockopt(des_socket-de-servicio, SOL-SOCKET, SO-LINGER, &param,
sizeof(struct linger)) == -I){
exit(1);
1
#endif
#ifdef VER90
static struct linger linger={l ,I};
if (setsockopt(des-socket-de-sewicio,
I
SOL-SOCKET, SO-LINGER, &linger,
. sizeof(1inger)) == -I){
exit(1);
'
1
#endif
while(1) {
memset(comando, O, TAM-COM);
if ( (rec-com = recibe-comando(coman'do)) == O ) return;
if ( ( ar = popen(comand0, ' Y ) ) == NULL ){
perror("popen()");
exit(1);
1
envia-salida();
if ( pclose(ar) == (-1 11 127) ) {
perror("pclose()");
fprintf(stderr, "Intente otra vez\n");
1
else ++num-serv;
1
1
} /* servicio() */
/* ************** Desplegar información final de sesión *************** *I
des-info-fin() {
printf("lnicio: %s\n", hora-fecha-inicio);
printf("Servidor: %S %S; puerto %u\n", host-sew,
inet-ntoa(dir-socket-escucha.sin-addr),
ntohs(dir-socket-escucha.sin-port));
printf("Cliente: %S %S; puerto %u\n", host-clien,
inet-ntoa(dir-socket-remoto.sin-addr),
ntohs(dir-socket-remoto.sin-port));
printf("Numero de servicios efectuados: O%d\n",num-sew);
time(&hora-fecha);
printf("Finalización: %s\n", ctime(&hora-fecha));
} /* des-info-fin() */
242
Implementación
de
un shell remoto
I
Un shell remoto
/* ........................
recibe-comando() ...........................
* El comando se recibe carácter a carácter.
* recv() regresa O si recibe un fin de archivo, lo que significa que la
* transmisión concluye; regresa l ' s i recibe un carácter válido o un fin de
* cadena; obviamente -1 significa la presencia de unerror ***************
int recibe-comando(comand)
char cornand[];
{
int Irecv;
int ¡=O;
while (1) {
Irecv=recv(des-socket-de-servicio,&comand[i],
switch (Irecv) {
case -1: perror(llrecv()l*);
fprintf(stderr, "Error\n");
exit(1);
case O: return(0);
case 1: if (cornand[¡] == 70') return(1);
i++;
break;
} /* switch *I
*
*I
1 O);
1
} /* recibe-comando() */
/* .....................
envia-salida()
...............................
* Envia la salida en un buffer de tamañoTAMBUFF.
* ferror() verifica si hubo error en fread(). fflush() debe usarse con
* popen()cuando se programademanera concurrente. ......................
envia-salida()
{
int I = TAMBUFF; /* Se usa para comparar el valor de salida de */
char buf[TAMBUFF+l]; /* Buffer de salida */
*
*
*I
while ( I = fread(buf, sizeof(char), TAMBUFF, ar) )
if (write(des-socket-de-servicio, buf, I) == -I){
perror("write()");
exit(1);
1
if (fflush(ar) != O) {
perror("fflush()");
exit(1);
1
if (ferror(ar)) {
perror("fread()");
exit(1);
1
} I* envia-salida() *I
I
243
CaDítulo 8
EL PROGRAMA CLIENTE
Consta de dos archivos: el de cabecera (%liente.h7 que contiene las macros y variables
usadas por el programa, el cual se encuentra en el archivo t1iente.c:' El programa ejecutable
se llama "cliente".
ARCHIVO DE CABECERA
/* c1iente.h *I
#include <stdio.h>
#include <netdb.h>
#include <sys/socket.h>
#include <errno.h>
I
#define PUERTO-MAX 60000
#define TAM-COM
81
#define CAD-FINAL "adios"
#define
PUERTO
4500
#define CAD-AYUDA "?"
#define NUM-COMANDOS 6
#define
CS
1O0
#define TAMBUFF
512I*
I* Número de puerto máximo válido'
I* Tamaño de la cadena que contendrá los comandos
I* Cadena
para
finalizar el programa
I* Número de puerto "de escucha" (del servidor)
I* Contiene la cadena
que
despliega
la ayuda
I* Número de comandos que se pueden ejecutar
/* Tamaño de las cadenas que guardanlos nombres
de los hosts cliente y servidor
Tamaño del buffer que recibe la información del
programa servidor
int long-dir = sizeof(struct sockaddr-in);
int num-serv-loc = O;
/* Núm. de servicios locales
int num-serv-rem = O;
/* Núm.
servicios
se
remotos
Implementación
de
*I
*I
*I
*I
int desc-socket-cliente;
I* socket cliente = socket local
*/
struct sockaddr-in dir-socket-local;
I* Info. del socket cliente
struct sockaddr-in
dir-socket-servidor;
I* Info. del socket servidor
*I
struct hostent *info-serv;
/* Info. del host servidor
struct hostent *info-clien;
I* Info. del host cliente
char host-clien[CS];
/* Nombre del host cliente
*I
char host-serv[CS];
I* Nombre del host servidor
char prog-cliente[CS];
I* Nombre del programa cliente
*I
long hora-fech;
/* Hora regresada
por
time()
*I
char *hora-fech-inicio;
I* Hora y fecha
devueltas
por
ctime()
char comando[TAM-COM];
I* Comando
enviado
al servidor
*I
char *ctime();
/* Devuelve un puntero a cadens
una
*I
que contiene la fecha y hora
int num-puerto;
/* Número de puerto usado
por
el
cliente */
244
*I
*/
*I
*I
*/
*I
*I
*I
*I
*I
*I
un shell remoto
I
~
."
Un shell remoto
CÓDIGO DEL CLIENTE
/* clier1te.c */
#include "c1iente.h"
/* *****************
Función principal. main()
......................
* Despuésdeque
se inicializan unas variables
se
y
guarda
el
primer
* argumento del programa, se obtiene el nombre del host cliente por medio de
la función gethostento. Ya en el switch, si el número deargumentos
* proporcionados por el usuario es tres,se convierte el número de puerto de
* cadena a entero y se valida su rango: en seguida se obtiene el nombre del
* host servidor (remoto)ysesale del switch. Si el número de argumentos es
* diferente el código es obvio. Finalmente se llaman tres funciones(). *****
*
*
*
*
*
*
*
*/
main (argc, argv)
int argc;
char *argv[];
{
memset((char *)&dit--socket-local, O, long-dir);
memset((char *)&dir-socket-servidor, O, long-dir);
memset(host-clien, O, CS);
memset(host-serv, O, CS);
strcpy(prog-cliente, argv[O]);
I
if ( gethostname(host-ser, CS) == -1 ){
perror("gethostname()");
exit(1);
1
switch (argc) {
case 3: if ( (num-puerto = atoi(argv[2]) ) == O 11
num-puerto < IPPORT-RESERVED 11 num-puerto > PUERTO-MAX) {
fprintf(stderr, "%u: puerto invalid0 o fuera de rango\n", num-puerto);
exit(1);
}
case 2: if ( (info-sew = gethostbyname(argv[l])) == NULL )
strcpy(host-serv, argvtl]);
else strcpy(host-sew, info-serv->h-name);
break;
case 1: printf("Uso: %S host-servidor [num-puerto]\n", prog-cliente);
printf("%u num-puerto <= %u \n",IPPORT-RESERVED,PUERTO-MAX);
exit(0);
I
1
245
CaDítulo 8
default: fprintf(stderr, "Numerode parametros invalido\n");
exit(1);
} /* switch */
t
prepara-socket(argc);
desp-info();
comunicacion();
} /* main() */
/* .........................
*
*
*
*
*
prepara-socket() ...........................
S e crea el socket cliente (socket());si el usuario especificó un número
de puerto (argc=3) &te se enlaza al socket oreado, de lo contrario el
sistema asigna un puerto a la dirección del socket creado (bind()).
Después se prepara la dirección del socket servidor para hacer la
conexión con el socket cliente (connect()). .............................
prepara-socket(argc1)
int argcl;
{
if ( (desc-socket_cliente=socket(AF-lNET, SOCK-STREAM, O)) == -1 ) {
perror("socket()");
fprintf(stderr, "No se puede crear el socket %s\n",prog-cliente);
exit(1);
I
I
if (argcl == 3) {
dir-socket-local.sin-port = htons((u-short)num-puerto);
dir-socket-local.sin-family = AF-INET;
dir-socket-local.sin-addr.s-addr = INADDR-ANY;
if ( bind(desc-socket-cliente, &dir-socket-local,long-dir)
I
I
perror("bind()");
fprintf(stderr,"No se puede asociar la direccion a
exit(1);
== -1 ) {
1
%s\n", prog-cliente);
dir-socket-servidor.sin-port=htons(PUERTO);
dir-socket-servidor.sin-family=AF-lNET;
dir-socket-servidor.sin-addr.s-addr=
((struct in-addr *)(info-serv->h-addr))->s_addr;
if ( connect(desc-socket-cliente, &dir-socket-servidor, long-dir) == -1 ) {
perror("connect()");
fprintf(stderr,"O/OS no se puede conectar a %s\n",prog-cliente, host-serv);
exit(1);
I
/* prepara-socket() */
246
un shell
".
Un shell remoto
dQGPI,,f"()
/* . . . . . . . . . . . . . . . . . . . . . . . .
*
...........................
' Se obtierle Illlortnacir5rl del socket local paradesplegarseen
parllalla
* (getsockname()). Además del número de puerto de conexión se despliegan los
* nombresde.loshosts cliente y servidor,así como la horade inicio *****
desp-info() {
if ( getsockname(desc-socket-cliente, ¿idir-socket-local, I
A
*
*/
&long-dir)== -1 ) {
perror("getsockname()");
fprintf(stderr, "No se puede leer informacion del socket local %s\n",
prog-cliente);
exit(1);
1
time(&hora-fech);
hora-fech-inicio=ctime(&hora-fech);
printf("%s conectado a %S en el puerto %u: %s\n", host-clien,
host-sew, ntohs(dir-socket-local.sin-port), hora-fech-inicio);
} /* desp-inf-inicio() */
/* . . . . . . . . . . . . . . . . . . . . . . . . .
1
Tabla-de-comandos .........................
*/
int existe-com(x-comando)
char x-comando[];
{
static char *tab-com[NUM-COMANDOS]= { "ls","pwd", "who", "cp","cat" };
int i;
for (¡=O;i<NUM-COMANDOS; i++)
if (strcmp (tab-corn[¡], x-comando) == O)
return(¡);
return(-I);
} /* existe-comando() */
/* ..............................
ayuda0
.............................
*/
aYudaO{
printf(Vs> [argumentos] listar directorio remoto\n");
printf("<!ls> [argumentos] listar directorio local\n");
printf("<pwd>
ver directorio actual remoto\n");
printf("<!pwd>
ver directorio actual local\n");
printf("<who> [argumentos] ver usuarios en la red del servidor\n");
printf("'c!who> [arguentos] ver usuarios en la red del clienteh");
printf("<cp> [argumentos] copiar archivos remotos\n");
printf("<!cp> [argumentos] copiar archivos locales\n");
printf("<cat> <nom-arch>visualizar
un archivo remoto\n");
printf("<!cat> <nom-arch> visualizar un archivo local\n");
printf("<%s>
terminar sesion\n",
CAD-FINAL);
} /* ayuda() *I
247
Capitulo 8
"
/* . . . . . . . . . . . . . . . . . . . . . . . . .
comunicacion() . . . . . . . . . . . . . . . . . . . . . . . . . . .
*
* Después
de
leer comando
el
por
medio
de
gets() existen cuatro
* posibilidades: band=l, se pidió finalizar el programa;
band=2 se pidió
* ayuda;band=3 se teclea un posible comando local; band=4 se teclea un
* posible
remoto.
comando
*I
comunicacion()
{
char com-aux[TAM-COM];
I* Cadena auxiliar que guarda el comando *I
int i,j;
I* Contadores *I
int band = O;
I* bandera *I
printf("Ayuda: %s\n", CAD-AYUDA);
printf("Finalizar: %s\n\n\n", CAD-FINAL);
while (band != 1) {
memset(comando, O, TAM-COM);
memset(com-aux, O, TAM-COM);
printf("%s>> host-sew);
gets(comand0);
if ( strcmp(comando, CAD-FINAL) == O )
band = 1;
else
band = 2;
if ( strcmp(comando, CAD-AYUDA) == O )
else
if ( comando[O]=='!' ) band = 3; else band = 4;
switch (band) {
case 2: ayuda();
default:
case 1: break;
case 3: ¡=O;j=1;
do {
com-aux[i] = comando[j];
++i; ++j;
} while (comando[j]!='\O' && j<= TAM-COM && comando[j]!='
if ( existe-com(com-aux) != -1 ) {
comando[O] = I ;
if ( system(comando) != -1 ) num-sew-loc++j
else perror("system()");
I);
1
else fprintf(stderr, "Comando Invalido.Teclear %s\n", CAD-AYUDA);
break;
case 4: ¡=O;
do {
com-aux[i] = comando[¡];
.
++i;
} while (comando[i]!='\O' && i<= TAM-COM && comando[¡]!=
t
I);
248
.
__
Implementación
de
~ _ " ^ I _
un shell remoto
*
*
*
"
Un shell remoto
if ( existe-com(com-aux) I= -1 ) {
envia-comando();
recibe wlidn();
I\~IIII"V-IL)I11~
I
I
;
1
else fprintf(stderr, "Comando Invalido.Teclear %s\n", CAD-AYUDA);
break;
} /* switch */
} /* while */
finaliza();
} /* comunicacion */
/* .......................
finaliza() {
char *¡net-ntoa();
finaliza()
.............................
*/
/* Dirección de una máquina a formato Internet */
if ( shutdown(desc-socket-cliente, 2) == -1 ) {
perror("shutdown()");
fprintf(stderr, "No se puede cerrar el socket %s\n", prog-cliente);
exit(1);
1
close(desc-socket-cliente);
printf("lnicio: o/os\n", hora-fech-inicio);
printf("C1iente: %S %S; puerto %u\n", host-clien,
inet-ntoa(dir-socket-Iocal.sin-addr),
ntohs(dir-socket-local.$in-port));
printf("Servidor: %S %S; puerto %u\n", host-sew,
inet_ntoa(dir-socket-sewidor.sin-addr),
ntohs(dir-socket-sewidor.sin-port));
printf("Servicios locales: %d\n", num-sew-loc);
printf("Sewicios remotos: %d\n", num-sew-rem);
time(&hora-fech);
printf("Finalizo: %s\n", ctime(&hora-fech));
} /* finaliza() */
/* .........................
envia-comando()
*
**t******************,*****
* Envía el comando al servidor carácter a carácter .......................
*I
envia-comando() {
int i;
int I;
I = strlen(cornand0);
249
Capitulo U
I
for (¡=O; ¡<=I; i++)
{
if ( (send(desc-socket-cliente, &comando[i], 1, O)) != 1 ){
perror("send()");
exit(1);
I
} /* for */
} /* envia-comando() */
/* .......................
recibe-salida()
..........................
*I
recibe-salida( ){
int I;
char buf[TAMBUFF+I]; /* Buffer que recibe la salida del socket servidor */
do {
memset(buf, O, TAMBUFF+I);
if ( (I = read(desc-socket-cliente, buf, TAMBUFF)) == - I ) {
perror("read()");
exit(1);
1
printf("%s", buf);
}while (I >= TAMBUFF);
} /* recibe-salida() *I
250
Implementación
un de
shell remoto
~~
Un shell remoto
2’ TRIMESTRE. CONCLUSIONES
S e presentaenestasección
medio de conclusiones.
un análisis y evaluación del proyecto en su totalidad,por
l . Los sockets utilizan el protocolo TCP, por considerarse más adecuado para
unprimer
trabajo de programación para comunicaciones, debido a su confiabilidad.
2. El servidor tiene las siguientes características:
a) Es orientado a estado, ya que unavezestablecida la conexión con el cliente, se
pueden ejecutar los comandos remotos, sin necesidad de enviar información adicional
al servidor.
b) El servidor puede ser visto a su vez como un cliente, ya que pide un servicio (la fecha
y hora) al sistema en un momento dado.
c) L a autorización puede controlarse al usar la llamada al sistema socket(), cuando se
llena la información del socket de escucha mediante la estructura struct sockaddr-in.
E n este casose
usó la macro INADDR-ANY.(Ver código fuente del programa
servidor).
d) Está hechodemanera
concurrente, ya quede manera secuencia1 sería de poca
utilidad.
e)Comentamos que se pueden mejorar los aspectos de seguridad porun lado, y el
control del programa cuando falla la llamada al sistema popen(). (Vercapítulo 5).
3. El cliente tiene las siguientes características:
a) Proporciona un servicio no estándar.
b) Es completamenteparametrizado (esdecir, sepuedeespecificarun
númerode
puertoarbitrario para llevar a cabo el servicio). (Ver el capítulo 5 para obtener una
descripción de estos conceptos)
c) Sugerimos la mejora del sistema validando el ciclo que contiene la llamada al sistema
system().
4. La conexión entre cliente y servidor se lleva a cabo en forma bloqueante. (Ver cap. 6).
5. L a transmisión
de
mensajes entre
cliente
estructurada. (Ver capítulo 6)“
y servidor es bloqueante,síncrona
y
I
6. No se trabajó únicamente en el cubículo H-I 1 1 , por.lo que nos vimos precisados a usar
diferentes versiones de HP-UX (7.0, 8.0 y 9.0). Decidimos entonces usar directivasde
compilación condicional. S e usan sólo en el código del servidor (ya que es el que cambia
ligeramente). La forma de compilar de describe con ejemplos en el archivo “servidor.h”.
7. Seha
desarrollado una herramientade
comunicación entre procesos,que
ejecuta
comandos locales y remotos, a la cual se el pueden agrega; más comandos con relativa
facilidad; se puede asimilar su estructura para implementar
un
programa de
251
I
Capítulo 8
comunicaciones que ofrezca unservicio de cualquiertipo;finalmente se pueder, hacer
los cambios necesarios en el mismo, y adiciones y/o mejoras como las sugeridas en los
puntos 2 y 3.
1
8. Este conjunto de programas también puede verse
comunicaciones, el cual puede ser validado como tal.
como
un
protocolo
de
9. Finalmente, esperamos que al integrar la documentación y los códigos del cliente y del
servidor desarrollados, se ofrezca allectorun
panoramabásico pero completo y con
calidad de los mecanismosde comunicación entre procesos en el sistema UNIX, aún
cuando se trabaje con otraimplementación o con versiones posteriores de HP-UX, ya
que según nuestra experiencia, las variaciones en ambos casos son pocas.
Benito Cruz Mendoza
José Luis Méndez Montes
8
2 52
Implementación
un de remoto
shell
I
___
__(.".
I
1
APÉNDICES
Y BIBLIOGRAFÍA
I
APÉNDICE
11"
I
LLAMADAS AL SISTEMA PROPIAS DE SOCKETS
~
~~
accept
I
uso
retcodigo = accept(socket, dir, longdir);
DESCRIPCI~N
Los servidoresusan la función accept para aceptar la siguiente conexión dellamada enun socket pasivo
despuesdehaberllamadoa
socket para crear un socket,a bind paraespecificarunadirecci6n
IP local y un
númerode puerto deprotocolo, y a listen para hacer el socket pasivo y establecer la longitud de lacola de
conexión. accept elimina la siguiente solicitud de conexi6n de la cola (o espera hasta que llegue una conexión),
crea un nuevo :ocket para la solicitud, y regresa el descriptor del nuevo socket. accept solamente se aplica a
sockets de flujo (por ejemplo los que usan TCP).
ARGUMENTOS
Argumento
socket
dir
int
&sockaddr
longdir
&int
Significado
Un descriptor de socket creado
por
la función socket.
Un puntero
una
a
estructura de dirección. accept llena la
estructura con la dirección IP y el númerodepuertode
protocolo de la máquina remota.
puntero
Un a
un entero que inicialmente especificatamaño
el
del
argumento
sockaddr y, cuando retorna la llamada,
especifica el número de bytes almacenados en el argumento
dir.
CóDIGO DE RETORNO
accept regresa un descriptor de socket no negativo si no hay problemas y -1 indica que ha
ocurrido un error. Cuando ocurre un error, la variable global errno contieneunode
los
siguientes valores:
Valor en errno
Causa del error
EBADF
ENOTSOCK
EOPNOTSUPP
EFAULT
EWOULDBLOCK
EMFILE
ENFILE
ENOBUFS
El primer argumento no especifica un descriptor valido.
El primer argumento no especifica un descriptor de socket.
El socket no esde tipo SOCK-STREAM.
El puntero del argumento 2 es invalido.
El socket esta marcado como no bloqueante y las conexiones no estan esperando ser aceptadas.
El número maximo de descriptores de archivo para este proceso ya esta abierto.
La tabla del sistema esta llena y no se pueden aceptar mas accept() enese momento.
No hay espacio de buffer disponible.
EINVAL
EAGAIN
EINTR
E/S no bloqueante usada con O-NONBLOCK.
stream sockets
256
El socket referenciado por el descriptor del socket no esta a la escucha, o se ha ejecutado un shutdown().
La llamada fue interrumpida por un signal()antes de la conexi6n.
APÉNDICE I’
RESUMEN DE LLAMADAS AL SISTEMA PROPIAS
DE SOCKETS
I
DESCRIPCI~N
LLAMADAS AL SISTEMA
socket()
bind()
~
listen()
connect()
I
~~
Crea un socket, o punto de comunicación para el proceso que
hace la llamada. Asigna una dirección desocketal
socket
especificado por el proceso que hacela llamada.
Asigna una dirección de socket al socket especificado por el
Droceso aue hace lallamada.
Establece unacola para las solicitudes desconexión que llegan.
(Solamente paralos stream sockets’ ).
Para stream sockets, solicita y creaunaconexión
entre el
socket remoto (especificado mediante una dirección) y el socket
del procesoquehace
la llamada (especificado mediante un
descriptor).
Para sockets dedatagramas,
especifica elsocketremoto
corresoondiente.
Acepta una conexiónentre el socket local del proceso que hace
accept()
la llamada y el socket especificado en la llamada asociada con
la conexión. (Solamente para streamsockets).
send(), sendto(), sendmsg() Envían datos desdeel socket especificado.
Reciben datos desdeel socket especificado.
recv(), recvfromo,
Desconecta el sock& especificado.
shutdown()
Obtiene la dirección del socket especificado.
getsockname0
getsockopt(), setsockopt0 Obtienen, o colocan las opciones asociadas conun socket.
Obtiene el nombre del socket pareja” (remoto) conectado al
getpeername0
I socket especificado.
I
~
~~
”
“stream sockets”= “socketsde flujo”
I
bind
uso
retcodigo = bind(socket, localaddr, addrlen);
DESCRlPCldN
blnd especifica una dirección local y un número de puerto de protocolo para un socket. blnd
es usada principalmente por los servidores, lo cual implica que se debe especificar un puerto
de protocolo bien conocido.
ARGUMENTOS
'
I
Argumento
socket
localaddr
int
dsockaddr
addrlen
int
Significado
Un descriptorsocket
decreado
llamada
la
por
socket.
La dirección de
una
estructura que especifica una
dirección IP y un número de puerto deprotocolo.
El tamaño de la estructura de dirección en octetos (bytes).
En el tema de sockets enla segunda parte se describe la estructura sockaddr.
CóDIGO DE RETORNO
bind regresa O si no hubo problemas y -1 para indicar que ocurrió un error. Cuando ocurre
f especifica la causa de el error. Los
un error, la variable global errno contiene un código que
posibles errores son:
Valor en errno
Causa del error
EBADF
El argumento socket no especifica un descriptor válido.
El argumento socket no especifica un socket válido.
ENOTSOCK
EADDRNOTAVAIL La dirección especificada es inválida (por ejemplo, una dirección IP no es
compatible con unainterface local).
La dirección especificada está en uso.
EADDRINUSE
El socket ya tiene una dirección asociada.
EINVAL
familia de direcciones del
EAFNOSUPPORT La dirección solicitada noconcuerdaconla
socket.
El programa
de
aplicación no tiene permiso de
usar
la dirección
EACCESS
especificada.
El puntero al argumentolocaladdr es inválido.
EFAULT
El tipo de descriptor de socket no soportala dirección de enlace.
EOPNOTSUPP
No hay espacio debuffer disponible.
ENOBUFS
El protocolo X.25 de nivel 2 está dado de baja.
ENETUNREACH
El segundo parámetro(de dirección) no fue especificado.
EDESTADDREQ
El nombre de campox25ifname especifica una interface no existente.
ENODEV
El nombre
decampo
x25ifname especifica una interface que fue
ENETDOWN
funciona
el enlace del
desconectada,
nunca
fue inicializada, o no
protocolo de nivel 2.
~
I
257
connect
uso
retcodigo = connect(socket, addr, addrlen);
DESCRIPCI~N
Una vez que el proceso servidor est6 a la escucha de solicitudes de conexibn, el proceso cliente puede solicitar
una conexión con la llamada connect. connect inicia una conexión y la bloquea si dicha conexión no está lista, a
menos que se esté usando entradahatida no bloqueante. Cuando la conexión está lista, el proceso cliente completa
su llamada connect y el proceso servidor puede completar su llamada accept.
ARGUMENTOS
Argumento
socket
addr
addrlen
int
&sockaddr_in
int
Significado
Descriptor de un socket.
Puntero a ladirección de la máquina remota.
Longitud del segundo argumento.
CóDIGO DE RETORNO
connect regresa O si no hubo problemas y -1 indica que ocurrió un error. Cuando ocurre un
error, la variable global errno contiene uno delos siguientes valores:
Valor en errno
EBADF
ENOTSOCK
EAFNOSUPPORT
EADDRNOTAVAIL
EISCONN
ETIMEDOUT
ECONNREFUSED
ENETUNREACH
EADDRINUSE
EINPROGRESS
EALREADY
EINVAL
EFAULT
ENODEV
ENOSPC
ENETDOWN
ENOBUFS
EINTR
EOPNOTSUPP
258
Causa del error
El primer
argumento
especifica
no
descriptor
un
válido.
El primer argumento no especifica un descriptor de socket,
La familia de dirección especificada en el sobket remoto no puede ser usada con
este tipo de socket.
La dirección del socket remoto especificada no es válida.
El socket ya está conectado.
(Solamente TCP) El protocolo alcanzó un intervalo de tiempo dado sin establecer
una conexión satisfactoriamente.
(Solamente TCP) La conexión fue rechazada por la máquina remota.
(Solamente TCP) La red no está actualmente disponible.
La dirección especificada ya está en uso.
y un intento de conexión podría
(SolamenteTCP) El socket es no bloqueante
bloquearlo.
y lallamadapodríaesperaruna
(SolamenteTCP) El socketesnobloqueante
conexión previa que l a intente completar.
El socket ya ha sido desconectado o tiene un listen() activo.
El segundo argumento no es un puntero válido.'
El campo x25ifname se refiere a una interface existente.
Todos los circuitos virtuales disponibles están en uso.
Lainterface x25ifname especificadaenelsegundoparámetrofueencontrada
pero no inicializada.
No hay espacio de buffer disponible.
de
La
conexión
fue
interrumpida
intencionalmente
por
u11a señal
antes
completarse
Se hizo un intento de connect() en un socket que no soporta esta llamada.
1
sa errno
getpeernamv
uso
retcodigo = getpeername(socket, remaddr,addrlen);
,
DESCRIPCI~N
.
Una aplicación usa getpeername para obtener la dirección remota (de un socket) para un
socket conectado. Normalmente, un cliente conoce la dirección del socket remoto porque lo
llama con connect para establecer la conexión. Sin embargo, un servidor que usa accept para
obtenerunaconexión
podría necesitar preguntaralsocketcorrespondientesu
dirección
remota.
ARGUMENTOS
Argumento
Significado
socket
Un
int
descriptor de socket creado
por
la función socket.
remaddr
&sockaddrUnpunteroa
la estructura sockaddrquecontendrá
la dirección
remota.
addrlen
&int
Un
puntero
a
un entero
que
contiene
la longitud del
segundo
argumento inicialmente, y la longitud actual de la dirección
remota al final.
CóDIGO DE RETORNO
getpeername regresa O si no hubo problemasy -1 para indicar que ocurrió un error. Cuando
ocurre un error, la variable global errno contiene uno delos siguientes valores:
en
Valor
EBADF
ENOTSOCK
ENOTCONN
ENOBUFS
EFAULT
EINVAL
EOPNOTSUPP
del error
El primer
argumento
no
especifica un descriptor válido.
El primerargumentono especifica un descriptor de socket.
El socket
no está conectado.
El sistema tiene recursos insvficientes para llevar acabola operación.
El puntero al argumento remaddres inválido.
El socket ha sido desconectado.
Operación no soportadaporsockets AF-UNIX.
259
getsockname
uso
retcodigo = getsockname(socket, name, namelen);
DESCRIPCI~N
getsockname obtiene la dirección del socket especificado.
ARGUMENTOS
Argumento
socket
name
namelen
+
Tipo
int
&char
&int
Significado
Descriptor de socket creado por la función socket.
Un puntero a una cadena.
El número de posiciones de la cadena name; regresa la longitud de
la dirección.
CóDIGO DE RETORNO
getsockname regresa O si no hay problemas y -1 indica que ocurrió un error. Cuando ocurre
un error, la variable global errno contiene uno de los siguientes valores:
en
Valor
errno
EBADF
ENOTSOCK
EBOBUFS
EFAULT
EINVAL
EOPNOTSUPP
Causa del prror
El primer
argumento
no especifica un descriptor válido.
El primerargumento no especifica undescriptor desocket.
No hay espacio de
buffer
suficiente
disponible
en el sistema.
La dirección de name o namelen es incorrecta.
El socket ha sido desconectado.
Operación no soportada por sockets AF-UNIX.
260
.In""L
getsockopt
uso
retcodigo = getsockopt(socket, level, opt, optval, optlen);
DESCRIPCI6N
getsockopt permite a una aplicación obtener el valor de un parámetro (opción) de un socket
o de un protocolo que usa el socket.
I
ARGUMENTOS
’
Argumento
socket
level
opt
optval
optlen
Tipo
int
int
int
&char
&int
Significado
El descriptor de un socket.
Un entero que identificanivel
un
de
protocolo.
Un entero que identifica una opción.
La dirección de un buffer en la cual se regresa un valor.
Tamaño del buffer; regresa la longitud del valor regresado.
Las opciones del nivel de socket que se aplican a todos los sockets incluyen:
SO-DEBUG
SO-REUSEADDR
SO-KEEPALIVE
SO-DONTROUTE
SO-LINGER
SO-BROADCAST
SO-USELOOPBACK
SO-SNDBUF
SO-RCVBUF
SO-ERROR
Estado de la información de depuración.
¿Permite reutilizar una dirección local?
Estado de la conexión “keep-alive”.
¿Se permite la desviación para mensajes de salida?
¿Cómo se debe cerrar el socket si hay datos por enviar?
¿Hay permiso para obtener mensajes de difusión?
Opción booleana, no funcional: incluida por compatibilidad.
Tamaño del buffer de salida.
Tamaño del buffer de entrada.
Obtener y limpiar el ultimo error del socket.
I
CóDIGO DE RETORNO
getsockopt regresa O si no hubo errores y -1 indica que ocurrió un error. Cuando ocurre un
error, la variable global errno contiene uno de los siguientes valores:
Valor en errno
EBADF
ENOTSOCK
ENOPROTOOPT
EFAULT
La
EOPNOTSUPP
ENOBUFS
EINVAL
La
Causa del error
El primer
argumento
no
especifica descriptor
un
válido.
El primer
argumento
no
especifica un
descriptor de
socket.
El argumento opt es incorrecto.
dirección de optval o de optlen es incorrecta.
La opciónno es soportada por el protocolo usado por el socket.
Espacio de buffer no disponible.
o el socket ha sido
opción es desconocida en nivel
el
de
socket,
desconectado.
261
uso
retcodigo = listen(socket, queuelen);
DESCRIPCI~N
Los servidores usan listen para hacer un socket pasivo (es decir, prepararlo para aceptar las
solicitudes que llegan). listen tambiénestablece el númerode solicitudes deconexiónde
llegada que el protocolo encola para un socket dado mientrap el servidor maneja otra solicitud.
listen solamente se aplica a sockets usados conTCP.
ARGUMENTOS
Argumento
socket
queuelen
Tipo
int
int
Significado
Un descriptor creadopor la llamada socket.
El tamañode la cola de las
solicitudes deconexiónque
llegan.
I
CóDIGO DE RETORNO
listen regresa O si nohayproblema y -1 para indicar que ha ocurrido un error. Cuando
en
errno
Valor
EBADF
ENOTSOCK
EOPNOTSUPP
EDESTADRREQ
ENOBUFS
EINVAL
Causa del error
El primer
argumento no especifica un descriptor válido.
El primerargumentono especifica un descriptor de socket.
El tipo desocketnosoporta listen.
La dirección deenlaceno fue establecida.
(Series 300/400 solamente). No hay
espacio
de
buffers disponible
El socket ha sido desconectado o ya
está
conectado.
1
262
sa errno
I
recv
uso
retcodigo = recv(socket, buffer, length, flags);
DESCRIPCI~N
recv obtiene el siguiente mensaje de llegada de un socket.
.
ARGUMENTOS
Argumento
socket
buffer
length
flags
I
int
&char
int
int
Significado
Un descriptor de socket creado porla función socket.
La dirección de un buffer que guarda el,mensaje.
La longitud del buffer.
Bits de control que especifican si se reciben datos urgentes.
CóDIGO DE RETORNO
recv regresa el número de bytes en el mensaje si no hay problema y -1 para indicar que ha
los
ocurrido un error. Cuando ocurre un error, la variable global e r n 0 contieneunode
siguientes valores:
S
en
Valor
EBADF
ENOTSOCK
EWOULDBLOCK
EINTR
EFAULT
EMSGSIZE
ETIMEOUT
ENOTCONN
EINVAL
EOPNOTSUPP
ENOBUFS
ECONNRESET
del error
El primer argumento
no
El primer argumento noespecifica un descriptor de socket.
El socket notiene datos, pero ha sido especificada E/S' bloqueante.
Una señal llega antes que la operación de lectura pudiera entregar los
datos.
El argumento bufferes incorrecto.
Una longitud en la estructura msghdr es inválida.
La conexión fue establecida fuera de tiempo.
Recibe en un SOCK-STREAM qVe aún no se conecta.
La longitud de lenght en la estructura msghdr es inválida.
Verificar las banderas con eltipo de socket.
Recursos insuficientes en el sistema.
Una conexiónfue forzada a cerrar por sucorresponsal.
I
E/S = entradakalida.
263
recvfrom
uso
retcodigo = recvfrom(socket, buffer, buflen, flags, from, fromlen);
DESCRIPCI~N
recvfrom extrae el siguiente mensaje que llega al socket y registra la dirección del emisor.
ARGUMENTOS
Argumento
socket
buffer
buflen
flags
from
&char
id
int
&sockaddr
fromlen
&inf
int
Significado
Un descriptor de socket creado porla función socket.
La dirección de un buffer que almacena el mensaje.
La longitud del buffer.
Bits de control para especificar mensajes urgentes.
La dirección de una estructura que almacena la dirección del
emisor.
La longitud del buffer h m , regresa el tamaño
de
la longitud de
la dirección del emisor.
CóDIGO DE RETORNO
recvfrom regresa el número de bytes en el mensaje si no hubo problemas y -1 para indicar
que ocurrió un error. Cuando ocurre un error, la variable global errno contieneunode los
siguientes valores:
en
Valor
errno
EBADF
ENOTSOCK
EWOULDBLOCK
EINTR
El primer argumento noespecifica un descriptor válido.
El socket no tiene datos, pero ha sido especificada E/S' no bloqueante.
Una señal llegó antes de que la operación de lectura pudiera entregar los
EFAULT
EMSGSIZE
ETIMEOUT
ENOTCONN
EINVAL
EOPNOTSUPP
ENOBUFS
ECONNRESET
datos.
El argumento buffer es incorrecto.
Recibe en un SOCK-STREAM que aún no se conecta.
La longitud de lenght en la estructura msghdr es inválida.
Verificar las banderas con el tipo de socvet.
Una conexión fue forzada cerrar
a
por su corresponsal.
Causa del error
E/S = entrada/salida.
264
sa errno
recvmsg
uso
retcodigo = recvmsg(socket,msg flags);
I
DESCRIPCI~N
recvrnsg
regresa el siguiente mensaje que llega a un socket. Coloca el mensaje en una
estructura que incluye una cabecera conlos datos.
ARGUMENTOS
Argumento
socket
msg
flags
int
&struct rnsghdr
int
Significado
Descriptor de socket creadopor la función socket.
Dirección de la estructura de
un mensaje.
Bits de control para especificar mensajes urgentes.
El formato de la estructura rnsghdrse encuentra enel tema correspondiente asockets.
CóDIGO DE RETORNO
recvmsg regresa el número de bytes enel mensaje si no hay problemay -1 para indicar que
ha ocurrido un error. Cuando ocurre un error, la variable global errno contieneunode los
siguientes valores:
en
Valor
EBADF
ENOTSOCK
EWOULDBLOCK
EINTR
EFAULT
EMSGSIZE
ETIMEOUT
ENOTCONN
EINVAL
EOPNOTSUPP
ENOBUFS
ECONNRESET
del error
El primer
argumento
no
El socket no tiene datos, pero ha sido especificada E/S' no bloqueante.
Una señal llegó antes de que la operación de lectura pudiera entregar los
datos.
Recibe en unSOCK-STREAM que aún no seconecta.
La longitud de lenght en la estructura,.msghdr es inválida.
Verificar las banderas con eltipo de socket.
Una conexiónfue forzada a cerrar por su corresponsal.
265
"
I_
send
.
.
"
,
uso
retcodigo = send(socket, msg, msglen,flags);
DESCRIPCI~N
Las aplicaciones llaman a send para transferir un mensaje aotra máquina.
ARGUMENTOS
Argumento
socket
msg
msglen
flags
inf
&char
inf
inf
Significado
Descriptor de socket creadq mediante
la función socket.
Un puntero al mensaje.
La longitud del mensaje en bytes.
Bits de control que especifican datos urgentes.
CóDIGO DE RETORNO
send regresa el número de caracteres enviados y -1 indica que ocurrió un error. Cuando
en
Valor
errno
EBADF
ENOTSOCK
EFAULT
EMSGSIZE
EWOULDBLOCK
Causa del error
El primer argumento noespecifica un descriptor válido.
El argumento bufferes incorrecto.
El mensajees demasiado largo para el socket.
El socketno tiene datos, peroha
sido especificada E/S"
bloqueante.
El sistema tiene insuficientes recursospara llevar acabo la
ENOBUFS
operación.
El proceso haceun broadcast yel socket no lo soporta.
EACCES
La operación fue interrumpida por una señal antes de que los
EINTR
datos fueran enviados.
En un send() un socket no dstá conectado, no se completa la
ENOTCONN
secuencia de conexión, o no está conectado con su pareja.
EPIPE and SlGPlPE (signals) Se intentó hacer un send() en un socket que fue conectado
pero que ya no lo es.
E/S = entradahalida.
Tipo
.
"I
sendmsg
uso
retcodigo = sendmsg(socket, msg, flags);
DESCRIPCI~N
sendmsg envía un mensaje, extrayéndolo de unaestructura rnsghdr.
ARGUMENTOS
.
Argumento
socket
msg
flags
inf
&stmct msghdr
inf
Significado
Descriptor de socket creado mediante la
función socket.
Un
puntero
a
la estructura del
mensaje.
Bits de control para especificar datos urgentes,
El formato de laestructura rnsghdr se encuentra en el tema correspondiente sockets.
a
CóDIGO DE RETORNO
sendmsg regresa el número de bytes enviados si no hubo problema y -1 indica que ocurrió
un error. Cuandoocurre un error, la variable global errno contieneunode los siguientes
valores:
errno
en
Valor
EBADF
ENOTSOCK
EFAULT
EMSGSIZE
EWOULDBLOCK
ENOBUFS
EAFNOSUPOORT
El0
ENETDOWN
EOPNOTSUPP
ENETUNREACH
ECONRESET
del Causa
error
El primer argumento
no
El mensaje es demasiado largo para el socket.
El socketno tiene datos, peroha sido especificada E/S'
bloqueante.
El sistemafiene insuficientes recursospara llevar acabo la
operación.
Dirección solicitada incompatible con la familia de dirección del
socket.
Ocurrió un tiempo fuera.
La interface usada para la, dirección especificada está dada de
baja, o no se encontró, o el nivel X.25 está dado de baja.
MSG-OOB no es soportada por socketsAF-UNIX.
(LAN) Todas las encapsulaciones hansido cortadas.
Una conexiónfue cerrada por su pareja.
1
267
ausa errno
I
I
1
Sendto
uso
retcodigo = sendto(socket, msg, msglen,flags, to, tolen);
sendto envía un mensaje tomando la dirección destino de una estructura.
ARGUMENTOS
Argumento
socket
msg
msglen
flags
to
tolen
Significado
Descriptor de socket creado mediantela función socket.
Un puntero al mensaje.
La longitud del mensaje en bytes.
Bits de control que especifican datos urgentes.
Un puntero a laestructura dq la dirección.
La longitud de la dirección en bytes.
int
&char
int
int
&sockaddr
int
CóDIGO DE RETORNO
sendto regresa el númerode bytes enviados si nohayproblema y -1 para indicar que
ocurrió un error. Cuando ocurre un error, la variable global errno contiene uno delos siguientes
valores:
en
Valor
EBADF
ENOTSOCK
EFAULT
EMSGSIZE
EWOULDBLOCK
ENOBUFS
EACCES
EINTR
EISCONN
EINVAL
EDESTADDREQ
del error
El primer argumento
no
El mensaje es demasiado largo para el socket.
El socketno
tiene datos, peroha
sido especificada E/S'
bloqueante.
El sistema tiene insuficientes recursospara llevar acabo la
operación.
El proceso haceun broadcast y el socket no lo soporta.
La operación fue interrumpida por una señal antes de que los
datos fueran enviados.
Fue especificada unaconexiónpor
un to paraunsocket
SOCK-DGRAM el cual ya está conectado. (sendtoo).
La longitud de los últimos dos parámetros de sendto(), o una
longitud en la estructura msghdr es inválida.
El parámetro to en sendto() necesita especificar una dirección
de destino para el mensaje.
E/S = entradalsalida.
268
1
"
"
S
setsockopt
uso
retcodigo = setsockopt(socket, level, opt, optval, optlen);
DESCRIPCI~N
setsockopt permite a una aplicación cambiar el valor de un parámetro (opción) asociado con
un socket o de un protocolo que usa el socket.
ARGUMENTOS
’
Argumento
socket
level
opt
optval
int
int
int
&char
Tipo
optlen
&int
’
Significado
El descriptor de un socket.
Un entero que identifica un protocolo (por ejemploTCP).
Un entero que identifica una opción.
La dirección de
un
buffer
que contiene un
valor
(normalmente
habilitar una opción o O para deshabilitarla).
La longitud
optval.
de
1 para
Las opciones del nivel de socket que se aplican a todos los sockets incluyen:
SO-DEBUG
SO-REUSEADDR
SO-KEEPALIVE
SO-DONTROUTE
SO-LINGER
SO-BROADCAST
SO-USELOOPBACK
SO-SNDBUF
SO-RCVBUF
SO-ERROR
Estado de la informabión de depuración.
¿Permite reutilizar una dirección local?
Estado de la conexión “keep-alive”.
¿Se permite la desviación para mensajes desalida?
¿Cómo se debe cerrar el socket si hay datos por enviar?
¿Hay permiso para obtener mensajes de difusión?
Opción booleana, no funcional: incluida por compatibilidad.
Tamaño del buffer de salida.
Tamaño del buffer de entrada.
Obtener y limpiar el último error del socket.
CóDIGO DE RETORNO
I
setsockopt regresa O si no hubo errores y -1 indica que ocurrió un error.
error, la variable global errno contiene uno de los siguientes valores:
en
Valor
errno
EBADF
ENOTSOCK
ENOPROTOOPT
EFAULT
EOPNOTSUPP
ENOBUFS
EINVAL
Cuando ocurre un
Causa del error
El primer
argumento
no
especifica descriptor
un
válido.
El primer
argumento no especifica
un descriptor de
socket.
El argumento opt es incorrecto.
.
La dirección de optval o de optlen es incorrecta.
La opción no es soportada por el protocolo usado por el socket.
Espaciobuffer
de
no disponible.
La opción es desconocida
en
nivel
el
de
socket,
o el socket ha sido
desconectado.
269
uso
retcodigo = shutdown(socket, directuion);
DESCRIPCI~N
La función shutdown se aplica a
conexión.
los sockets full-dútplex y se usa para cerrar parcialmente la
ARGUMENTOS
"
Araumento
socket
TiDo
int
int
direction
Significado
Un descriptor de socket creado mediante la llamada socket.
La dirección en la cual
se
desea cortar la conexión: O significa
terminar las entradas posteriores, 1 significa terminar lassalidas
posteriores, y dos significa terminartanto las entradas como las
salidas.
CóDIGO DE RETORNO
La llamada shutdown regresa O si la operación es correcta y -1 para indicar que ocurrió un
error. Cuando ocurre un error, la variableglobal errno contiene un código que especifica la
causa del error. Los posibles errores son:
en
Valor
errno
EBADF
ENOTSOCK
EINVAL
Causa del error
El primer
argumento
no especifica un
descriptor
El primerargumentono
especifica undescriptor
El socket especificado no está conectado.
I
válido.
desocket.
socket
uso
retcodigo = socket(family, type, protocol);
I
DESCRIPCI~N
La función socket crea un socket usado por la red decomunicaciones,
y regresa un
. descriptor entero para ese socket.
ARGUMENTOS
Argumentos
Tipo
family
tY Pe
int
int
protocol
int
Protocolo o familia
de
Significado
dirección (por ejemplo AF-INET).
Tipo servicio
de
(SOCK-STREAM para TCP o SOCK-DGRAM para
UDP)
Número de protocolo usar
a
o O para solicitar por defecto
para
una
familia y tipo dados.
CóDIGO DE RETORNO
La llamada socket regresa undescriptor o -1 para indicar que ocurrióunerror.
Cuando
ocurre un error, la variable global errno contiene un código que especifica la causa del error.
Los posibles errores son:
en
Valor
errno
EPROTONOSUPPORT
EMFILE
ENFILE
ENOBUFS
EHOSTDOWN
EAFNOSUPPORT
ESOCKNOSUPPORT
EPROTOTYPE
ETIMEDOUT
EINVAL
Causa del error
Error en los argumentos:elserviciorequerido
o elprotocolo
especificado es inválido.
El descriptor de la tabla de aplicación está lleno.
La tabla de archivos del sistema interno está llena.
El sistema no tiene espacio disponible en el buffer
No está activa la red.
La familiade la dirección especificada no es soportada esesa
versión'del sistema.
El tipo de socket especificado no es soportado en esta familia de
direcciones.
El tipo de socket y de protocolo no coinciden.
Conexión fuera de tiempo.
SOCK-DGRAM no es soportado por la familia AF-UNIX.
271
APÉNDICE 111”’
RESUMEN DE LLAMADAS AL SISTEMA ÚTILES CUANDO SE USAN
SOCKETS
LLAMADA AL
SISTEMA
DESCRIPCI~N
?cad()
Puede usarse para leer datos de sockets de flujo o de datagramas de la
misma forma que recv o recvfrop, sin el beneficio de las banderas de
recv. read ofrece independencia de implementación; el descriptor puede
ser para un archivo, un socket o cualquier otro objeto.
write()
Puede usarse para escribir datos de sockets de flujo (y de sockets de
datagramas si sedeclara una dirección pordefectoparael
socket
remoto) dela mismaforma que send. write ofreceindependencia de
implementación; el descriptor puede ser un archivo, un socket o
cualquier otro objeto.
close()
Deshabilita los descriptores de sockets. El último close puede usarse
para destruir un socket. dose desconecta deuna manera ‘Suave’ o
“brusca” dependiendo de la opción LINGER.
select()
Puede usarse para mejorar la eficiencia de un proceso que accede a
múltiples sockets u otros dispositivos de E/S simultáneamente.
¡octo
Puede usarse
para
encontrar
el
número
de
bytes
recibidos con
FIONREAD y para establecer una E/S como no bloqueantecon la
bandera FIOSBNBIO. También puede usarse para que un socket reciba
señales asíncronas con FIOASYNC.
fcntl()
Puede usarse para duplicar un descriptbr de socket y para establecer las
banderas O-NDELAY o O-NONBLOCK.
fork()
Aunque no está relacionadadirectamente
conla
comunicación de
sockets, fork es esencial porque los servidores lo usanpara crea1
procesos concurrentes. fork crea un nuevo proceso ejecutando el mismc
procesos
comparten
todos
los
código que
el
original. Los dos
descriptores de archivo y de socket que están abiertos cuando ocurre I E
llamada fork. Los dosprocesos
tienen diferentes identificadores de
procesos y diferentes identificadores de procesos padres.
272
”.
..
APÉNDICE
IV~V
I
RESUMEN DE LLAMADAS DE LIBRERIA ÚTILES CUANDO SE UTILIZAN
SOCKETS
LIBRERIA
htonl
htons
ntohl
ntohs
DESCRIPCION
convierten valores de la red a un host y viceversa
¡net-addr
¡net-lnaof
¡net-makeaddr
¡net-netof
¡net-network
rutinas de manipulación dedirecciones Internet
setservent
endservent
getservbyname
getservbyport
getservent
obtienen o colocan entradas deservicio
setprotoend
mdprotoend
aetprotobyname
getprotobynumber
getprotoent
obtienen o colocan la entrada de un protocolo
setnetent
mdnetent
Jetnetbyname
getnetbyaddr
aetnetent
obtienen o colocan entradas de lared
sethostend
endhostent
gethostbyname
gethostbyaddr
gethostent
obtienen o colocan entradas dehosts
273
BIBLIOGRAFíA
UNlX SISTEMA V. VERSION 4
MANUAL DE REFERENCIA
OSBORNE/McGRAW-HILL
STEPHEN COFFIN
MONOGRAF~A
RICARDO MARCELiN JIMÉNEZ
ORESTES TÉLLEZ ANALCO
RUBÉN VAZQUEZ MEDINA
INTERNETWORKING WITH TCPllP
VOLUMEN I
PRENTICE HALL
DOUGLAS E. COMER
SISTEMAS OPERATIVOS
CONCEPTOS FUNDAMENTALES
ADDISON-WESLEY IBEROAMERICANA
A. SILBERSCHATZ
J. PETERSON
P. GALVIN
THE LOGICAL DESIGN
ADDISON-WESLEY PUBLISHING COMPANY
ANDREJ GOSClNSKl
BERKELEY IPC PROGRAMER‘S GUIDE
EDICION 2
HEWLETT PACKARD
McGRAW-HILL
JEAN-MARIE RIFFLET
I
REDES DE ORDENADORES
PRENTICE HALL HISPANOAMERICANA S.A.
ANDREW S. TANENBAUM
DISTRIBUTED SYSTEMS
CONCEPTS AND DESIGN
ADDISON WESLEY PUBLISHING COMPANY
GEORGE COULOURIS
JEAN DOLLIMORE
TIM KINDBERG
DESIGN AND VALlDATiON
OF COMPUTER PROTOCOL
PRENTICE HALL
GERARD J. HOLZMANN
INTERNETWORKING WITH TCPllP
VOLUMEN 111
PRENTICE HALL
DOUGLAS E. COMER
I
DICCIONARIO DE COMPUTACI~N
INGLÉS-ESPANOL ESPAÑOL-INGLÉS
McGRAW-HILL 119941
ALAN FREEDMAN
GUIDE'S USER (SECCIONES2 Y 3)
HP-UX. VERSIONES 7.0 Y 9.0
HEWLETT PACKARD
i
Tomado de ComerBERKELEY IPC PROGRAMER'S GUIDE (Ver bibliografía)
ii
Tomado deINTERNETWORKING WITHTCP/IP VOLUMEN 111 y actualizado para
'I'
Tomado de ComerBERKELEY IPC PROGRAMER'S GUIDE (Ver bibliografía).
HP-UX 9.0 (bibliografía).
'" Tomado de Comer BERKELEY IPC PROGRAMER'S GUIDE (Ver bibliografla).
275
,
0
INDICE
I
iNDlCE
vii
INTROUUCCI~N
CAPÍTULO I PROTOCOLOS DE COMUNICACI~N.CONCEPTOS BASICOS I
PROTOCOLOS DE COMUNICACIóN. CONCEPTOS BÁSICOS
FUNCIONES
PROTOCOLOS
DE LOS
7
PROTOCOLOS
NORMALIZAC16N DE
Normalización
telecomunicaciones
8
en las
. La I S 0organismos
y otros
de normalización
8
OS1
EL
OS1
l
objetivos
Los
enfoque
del Conceptos
capas
Las
OS1
subsistema
El
de transporte de OS1
riores capas
Las
de OS1
TIPOS
to
ARQ
y espera
repetición
ARQ con
selectiva
no
repetición
ARQ con
selectiva
El
protocolo de alto
nivel de control de
enlace
de
datos
Y VALIDACIóN
DE
DESCRIPCIóN PROTOCOLOS
DE
PROTOCOLOS
Diferencias
entre
el modelo OS1 y TCPllP
Organización de TCP/IP
Presentación
Los
El protocolo IP
nivel
del
protocolos
Los
de
35transporte
El protocolo UDP (Protocolo de Datagama de Usuario)
3
5
10
10
10
12
13
13
16
17
18
(HDLC)
19
25
26
27
29
31
34
35
35
131 protocolo TCP (Protocolo de Control
Transporte)
de
deEsquema general
El
Las
funcionamiento
37
37
37
I .os scrvicios csthwkws
L,os servicios generales
Los servicios UNIX
38
38
39
CAPIP'UIN 2 FUNDAMENTOS DE REDES DE COMPUTADORAS
dl
FUNDAMENTOS DE REDES DE COMPUTADORAS
43
OBJETIVOS DE LAS REDES
APLICACIONES DE LAS REDES
ESTRUCTURAGENERALDEUNARED
CLASIFICACIONES DE REDES
Topología
Cobertura
Redes conmutadas
de y redes
difusión
Velocidad
Tipo de información que cursan
COMUNICACI~N
ESTRATEGIAS DE ENRUTAMIENTO
46
47
48
50
51
1
54
54
55
56
56
56
Estrategias de conexi6n
Conflictos
TECNOLOGíAS DE REDES
TECNOLOGíAS ETHERNET, TOKEN RINGY ATM
Tecnología Ethernet
Token Ring
Modelo de Transferencia Aslncrono (ATM)
57
58
59
63
64
68
70
CAPÍTULO 3 EL SISTEMA OPERATIVO UNIX
75
EL SISTEMA OPERATIVO UNIX
77
tras filosofía
sistema
del
El saber y la controversia que rodean al sistema
UNlX
78
La
78
UNlX
El
UNlX moderno
Historia
La
Temas
79
Requerimientos para rnicrocomputadoras
Ensaml)Iaje de un sistcma unix
Nola sobrc compatililidad USD y XENIX
83
x3
x4
TUTORIAL
Presentación
sistemadelpantallaLa
de ventanas X
Lectura
Listado de ficheros
Visualizaci6n de un fichero
fichero Supresión de un
89
Lectura de correo
89
Envío de correspondencia
Quién
Cambio de contraseña
Despedida
Miscelánea
ARCHIVOS Y ÓRDENES DE UNlX ÚTILES PARA TRABAJAR CON
PROTOCOLOS
archivos
Los
Órdenes de administración
procesos
Los
'
onio
El
demonios Los
de servicios estándares
Las
servicios
órdenes de
97 estándares
de
ordenes
Las
UNlX
de
estructuras
Las
1:I Inanqjo tlc las tlircccioncs
6 1 manejo de puertos y servicios
Los protocolos
ntre comunicación
84
85
86
87
88
91
91
92
92
94
95
96
98
1O0
I-"
100
102
102
La
Los mecanismos de direccionamiento
El Correo
103
104
LOS PROCESOS
EN
106 ELUNlX
SISTEMA
106
Control de procesos
110Administración de procesos
CAPIlULO 4 SISlEMAS OPERATIVOS
DISTRIBUIDOS
1115
117
117
Motivación
Una
definición
y funciones de un
sistema
operativo
distribuido
120
operativos
red
de
Caracteristicas
básicas
de los sistemas
Diferencias entre sistemas operativos de red y sistemas operativos
distribuidos
280
122
123
125 distribuido
Migraciones
sistema en un
Aspectos de
,_
COOriDlNACldN
Ordenación de
Exclusión
Prevenci6n de bloqueos mutuos
Deteccibn
mutuos de bloqueos
Solidez
Acuerdos
Algoritmos de
SISTEMAS DE ARCHIVOS 145
DISTRIBUIDOS
Antecedentes
Nominación y transparencia
Servicios
Memoria
154
Replicación de archivos
diseño
IIIBUIDA
sucesos
elección
127
129
129
,
134
-135
140
141
143
146
147
CAPI7’lJI.O 5 MOI1EI.O CLIENTE-SERVIDOR Y CONCURRENCIA
157
1
MODELO CLIENTE-SERVIDOR Y CONCURRENCIA
159
EL MODELO CLIENTE-SERVIDOR (MOTIVACIóN)
160 Terminologia y conceptos
no contra
estándar
cliente
Software
estándar
CONCURRENCIA EN REDES
servidores
Concurrencia en
168 Terminología y conceptos
159
161
166
168
CAPiTULO 6 COMUNICACIVN
ENTRE
PROCESOS
173
COMUNICACI~NENTRE PROCESOS
179
176
COMUNICACIóN ORIENTADA A MENSAJES
LLAMADA A PROCEDIMIENTOS REMOTOS
187(RPC)
COMUNlCAClÓN POR TRANSACCIONES EN SISTEMAS
OPERATIVOS
IDOS
7
CAPITUI,O
LOS SOCKEII’S
207
209
209
LOS SOCKETS
CARACTERíSTICAS
UN
DE
SOCKET
dominio
210
socket
El
de un
tipo
socket
El
de un
creación
La
de un socket
La supresión de un socket
Enlazamiento
socketun
de
a una dirección
LA COMUNICACIóN POR DATAGRAMAS
Principio general
operaciones
Las
de envio 215
y recepción
doconexiones”
Las
LA COMUNICACIóN
MODO
EN
CONECTADO
Principio
punto
El del
de vista
220 servidor
222
cliente
Eldel
punto de vista
clientelservidor
El diálogo
LA SEÑAL SlGlO
TOMA
LA
EN CUENTA DE MENSAJES URGENTES
LA PARAMETRIZACIÓN DE SOCKETS
LOS PROBLEMAS DE SEGURIDAD
21 1
21
212
213
214
215
2
9
21
226
227
230
231
CAPI’TLJLO8 UN SHELL
233 REMOTO
UN SHELL REMOTO
235
2x I
REMOTO?
SHELL
UN &UÉ
ES
SEMESTRE. IDENTIFICACIONDE PROBLEMAS T E ~ R I C O S
Cl?l"M WE LO§ ALCANCES OBTENIDOS
EL C6)DIGO DEL PROGRAMA SERVIDOR
13
I
235
236
237
237
2 Ití
230
244
244
24FJ
251
253
APÉNDICE I
RESUMEN DE LLAMADAS AL SISTEMA
PROPIAS
DE
SOCKETS
255
257
APÉNDICE II
256
SOCKETS
SISTEMA
LLAMADAS
PROPIAS
DE
AL
256
APÉNDICE 111
272
APÉNDICEIV
273
BIBL~OGELAFÍA
274
ÍNIMCE
2 77
iNDICE
27 9

1 - TESIUAMI

Transcripción

Documentos relacionados

Panel montado socket

Untitled