INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y

ELÉCTRICA UNIDAD CULHUACÁN

Ingeniería en computación

Asignatura:
Sistemas Distribuidos

Profesor:
Verónica Salas Jiménez

Grupo:
8CM22
Alumno:
Rodriguez Bernabé Edwin Alberto Ángel

Unidad I Arquitectura de un Sistema Distribuido

Índice
Índice..................................................................................................................................................2
1.1 Introducción a los sistemas distribuidos.........................................................................3
1.2 Características de un sistema distribuido........................................................................4
1.2.1 Heterogeneidad................................................................................................................4
1.2.2 Extensibilidad...................................................................................................................5
1.2.3 Seguridad..........................................................................................................................6
1.2.4 Escalabilidad....................................................................................................................7
1.2.5 Control de errores...........................................................................................................7
1.2.6 Concurrencia....................................................................................................................8
1.2.7 Transparencia...................................................................................................................8
1.3 Modelos arquitectónicos......................................................................................................9
1.4 Modelo fundamentales........................................................................................................11
1.5 Recursos de comunicación................................................................................................11
1.5.1 Protocolos TCP/IP.............................................................................................................13
1.5.2 Servicios y puertos...........................................................................................................13
1.5.3 Procesos y demonios.......................................................................................................14
Referencias...................................................................................................................................16
1.1 Introducción a los sistemas distribuidos

Un sistema distribuido es aquel en el que los componentes localizados en computadores,

estos conectados a una red, comunican y coordinan sus acciones mediante el paso de
mensajes. Esta definición nos lleva a las siguientes características de los sistemas
distribuidos: concurrencia de los componentes, carencia de un reloj global y fallos
independientes de los componentes.

Tres ejemplos de sistemas distribuidos son: internet, una red gestionada por una
organización y la computación móvil y ubicua.

Compartir los recursos es uno de los motivos principales para construir sistemas
distribuidos. Los recursos pueden ser administrados por servidores y accedidos por los
clientes o pueden ser encapsulados como objetos y accedidos por otros objetos clientes.
Los desafíos que surgen en la construcción de sistemas distribuidos son la
heterogeneidad de sus componentes, su carácter abierto, que permite que se puedan
añadir o reemplazar componentes, la seguridad y la escalabilidad, que es la capacidad
para funcionar bien cuando se incrementa el número de usuarios, el tratamiento de los
fallos, la concurrencia de sus componentes y la transparencia.

Existen redes de computadores en cualquier parte. Una de ellas es internet, como lo son
las muchas redes de las que se compone. Las redes de teléfonos móviles, las redes
corporativas, las de las empresas, los campus, las casas, redes dentro del coche, todas,
tanto separadas como combinadas, comparten las características esenciales que las
hacen elementos importantes para su estudio bajo el título de sistemas distribuidos.
Definiendo un sistema distribuido como aquel en el que los componentes hardware y
software, localizados en computadores unidos mediante red, comunican y coordinan sus
acciones solo mediante paso de mensajes. Esta definición sencilla cubre el rango
completo de sistemas en los que se utilizan normalmente computadores en red. Los
computadores que están conectados mediante red pueden estar separados
especialmente por cualquier distancia. Pueden estar en continentes distintos, en el mismo
edificio o en la misma habitación.

Concurrencia: es una red de computadores, la ejecución de programas concurrentes es la

norma. La capacidad del sistema para manejar recursos compartidos se puede
incrementar añadiendo más recursos a la red.

Inexistencia de reloj global: cuando los programas necesitan cooperar coordinan sus
acciones mediante el intercambio de mensajes. La coordinación estrecha depende a
menudo de una idea compartida del instante en el que ocurren las acciones de los
programas. Pero hay límites a la precisión con lo que los computadores en una red
pueden sincronizar sus relojes, no hay una única noción global del tiempo correcto.

Fallos independientes: todos los sistemas informáticos pueden fallar y los diseñadores de
sistemas tienen la responsabilidad de planificar las consecuencias de posibles fallos. Los
sistemas distribuidos pueden fallar de nuevas formas. Los fallos en la red producen el
aislamiento de los computadores conectados a el, pero no significa que detengan su
ejecución.
1.2 Características de un sistema distribuido

Transparencia: Es una característica de los sistemas distribuidos para ocultar al usuario la

manera en que el sistema funciona o está construido, de tal forma que el usuario tenga la
sensación de que todo el sistema está trabajando en una sola máquina local.

Flexibilidad: Facilita modificaciones al diseño inicial.

Confiabilidad: Permite que, en caso de que una computadora falle, otra la pueda sustituir
en la realización de sus tareas asignadas.

Desempeño: Está en referencia a los tiempos de respuesta de una aplicación.

Escalabilidad: Permite que a la arquitectura actual se le pueda adicionar más poder de

cómputo.

Repartición de la carga: Se debe analizar con qué equipos cuenta el sistema y los
diferentes recursos de cómputo en cada uno de ellos, como capacidad de disco, velocidad
de la red, etc. Los tipos de arquitectura a usar pueden ser:

• Servidores-estación de trabajo.

• Pila de procesadores.

• Multiprocesadores con memoria compartida.

• Multiprocesadores con memoria distribuida.

Mantenimiento de consistencia: Verificar que todos los conceptos involucrados con el

sistema operativo, al operar en un esquema distribuido, sigan realizándose de manera
correcta. Entre los puntos a observar están los siguientes:

• Modificación.

• Caché.

• Falla.

• Replicación.

• Interfaz de usuario.

• Reloj.

Funcionalidad: Implica que el sistema distribuido a implementar funcione de acuerdo con

las metas trazadas y que permita hacer más eficiente el trabajo que antes se hacía
usando un sistema centralizado.
Seguridad: Es importante considerar todos los factores de riesgo a que se expone la
información en un ambiente distribuido, por ello se deben de implementar los mecanismos
de seguridad que permitan proteger esta información.

1.2.1 Heterogeneidad

Internet permite que los usuarios accedan a servicios y ejecuten aplicaciones sobre un
conjunto heterogéneo de redes y computadores. Esta heterogeneidad se aplica a todos
los siguientes elementos:

 Redes

 Hardware de computadores

 Sistemas operativos

 Lenguajes de programación

 Implementaciones de diferentes desarrolladores

A pesar de que internet consta de muchos tipos de redes diferentes sus diferencias se
encuentran enmascaradas dado que todos los computadores conectados a este utilizan
los protocolos de internet para comunicarse una con otra. Los tipos de datos, como los
enteros, pueden representarse de diferentes formas en diferentes clases de hardware, por
ejemplo, hay dos alternativas para ordenar los bytes en el caso de los enteros. Hay que
tratar con estas diferencias de representación si se va a intercambiar mensajes entre
programas que se ejecutan en diferente hardware.

Lenguajes de programación diferentes emplean representaciones diferentes de caracteres

y estructuras de datos como cadenas de caracteres y registros. Hay que tener en cuenta
estas diferencias si queremos que los programas escritos en diferentes lenguajes de
programación sean capaces de comunicarse entre ellos. Los programas escritos por
diferentes programadores no podrán comunicarse entre sí a menos que utilicen
estándares comunes.

 Middleware: este termino de middleware se aplica al estrato software que provee

una abstracción de programación, así como un enmascaramiento de la
heterogeneidad subyacente de las redes, hardware, sistemas operativos y
lenguajes de programación. Además de soslayar los problemas de
heterogeneidad, el middleware proporciona un modelo computacional uniforme al
alcance de los programadores de servidores y aplicaciones distribuidas.

 Heterogeneidad y código móvil: el termino código móvil se emplea para referirse al

código que puede ser enviado desde un computador a otro y ejecutarse en este,
por eso los applets de java son un ejemplo de ello. Dado que el conjunto de
instrucciones de un computador depende del hardware, el código de nivel de
maquina adecuado para correr en un tipo de computador no es adecuado para
ejecutarse en otro tipo.
1.2.2 Extensibilidad

La extensibilidad de un sistema de cómputo es la característica que determina si el

sistema puede ser extendido y reimplementado en diversos aspectos. La extensibilidad de
los sistemas distribuidos se determina en primer lugar por el grado en el cual se pueden
añadir nuevos servicios de compartición de recursos y ponerlos a disposición para el uso
por una variedad de programas cliente. Los diseñadores de protocolos de internet
presentaron una serie de documentos denominados “solicitudes de comentarios”
(Request For Comments), o RFC, cada una de las cuales se conoce por un número.

Los sistemas diseñados de este modo para dar soporte a la compartición de recursos se
etiquetan como sistemas distribuidos abiertos para remarcar el hecho de ser extensibles.
Pueden ser extendidos en el nivel hardware mediante la inclusión de computadores a la
red y en el nivel software por la instrucción de nuevos servicios y la reimplementación de
los antiguos, posibilitando a los programas de aplicación la comparación de recursos. En
resumen:

 Los sistemas distribuidos abiertos se caracterizan porque sus interfaces están

publicadas.

 Los sistemas distribuidos abiertos se basan en la providencia de un mecanismo de

comunicación uniforme e interfaces públicas para acceder a recursos compartidos.

 Los sistemas distribuidos abiertos pueden construirse con hardware y software

heterogéneo, posiblemente de diferentes proveedores. Sin embargo, la
conformidad con el estándar publicado de cada componente debe concentrarse y
verificarse cuidadosamente si se desea que el sistema trabaje correctamente.

1.2.3 Seguridad

Seguridad se refiere en general a un conjunto de medidas de procedimiento, tanto lógicas

como físicas, orientadas a la prevención, detección y corrección de casos de mal uso.
Desde un enfoque informático, la seguridad se refiere a las características que debe de
tener un sistema de cómputo para resistir ataques y mal uso, ya sea este intencional o no.
En los sistemas distribuidos, la seguridad de la información juega un rol muy importante,
ya que se debe de garantizar que los recursos de cómputo y la información estén
protegidos.

Entre los recursos de información que se ofrecen y se mantienen en los sistemas

distribuidos, muchos tienen un alto valor intrínseco para sus usuarios. Por esto su
seguridad es de considerable importancia. La seguridad de los recursos de información
tiene tres componentes: confidencialidad, integridad y disponibilidad.

En un sistema distribuido, los clientes envían peticiones de acceso a datos administrados

por servidores, lo que trae consigo enviar información en los mensajes por la red. Por
ejemplo:

1. Un médico puede solicitar acceso a los datos hospitalarios de un paciente o enviar

modificaciones sobre ellos.
 2. En un comercio electrónico y banca, los usuarios envían su número de tarjeta de
crédito a través de internet.

En ambos casos, el reto se encuentra en enviar información sensible en un mensaje por

la red de forma segura. Pero la seguridad no sólo es cuestión de ocultar los contenidos de
los mensajes, también consiste en conocer con certeza la identidad del usuario u otro
agente en nombre del cual se envía el mensaje.

En el primer ejemplo el servidor necesita conocer que el usuario es realmente un médico

y en el segundo, el usuario necesita estar seguro de la identidad de la tienda o del banco
con el que está tratando. El segundo reto consiste en identificar un usuario remoto u otro
agente correctamente. Ambos desafíos pueden lograrse a través de técnicas de
encriptación desarrolladas al efecto, estas se utilizan ampliamente en internet. Existen dos
desafíos de seguridad que no han sido cumplimentados completamente:

Ataques de denegación de servicio: ocurre cuando un usuario desea obstaculizar un

servicio por alguna razón. Esto se obtiene al bombardear el servicio con un número
suficiente de peticiones inútiles de modo que los usuarios serios sean incapaces de
utilizarlo a esto se le denomina ataque de denegación de servicio (conocido de igual
forma como pings).

Seguridad del código móvil: el código móvil necesita ser tratado con cuidado.
Supongamos que alguien recibe un programa ejecutable (algún gusano o cualquier virus
informático) adherido a un correo electrónico: los posibles efectos al ejecutar dicho
programa son impredecibles; por ejemplo, pudiera parecer que presentan un interesante
dibujo en la pantalla cuando en realidad están interesados en el acceso a los recursos
locales, o quizás pueda ser parte de un ataque de denegación de servicio.

1.2.4 Escalabilidad

Los sistemas distribuidos operan efectiva y eficientemente en muchas escalas diferentes,

desde pequeñas intranets a internet. Se dice que un sistema es escalable su conserva su
efectividad cuando ocurre un incremento significativo en el número de recursos y en el
número de usuarios. Internet proporciona un ejemplo de un sistema distribuido en el que
el número de computadores y servicios experimenta un dramático incremento.

El diseño de los sistemas distribuidos escalables presenta los siguientes retos:

Control del coste de recursos físicos: cuando crece la demanda de un recurso, debería
ser posible extender el sistema, a un coste razonable, para satisfacerla. Por ejemplo, la
frecuencia con la que se accede a los archivos de una intranet que suele crecer con el
incremento del número de usuarios y computadores, debe de ser posible añadir
servidores para evitar el embotellamiento que aparece cuando un solo servidor de
archivos ha de manejar todas las peticiones de acceso a estos.

Control de las pérdidas de prestaciones: consideremos la administración de un conjunto

de datos cuyo tamaño es proporcional al número de usuarios o recursos del sistema, por
ejemplo la tabla con relación de nombres de dominio de computadores y sus direcciones
de red sustentado por el sistema de nombres de dominio (Domain Name System), que se
emplea principalmente para averiguar nombres DNS tales como www.amazon.com. Los
algoritmos que emplean estructuras jerárquicas se comportan mejor frente al crecimiento
de la escala que los algoritmos emplean estructuras lineales.

Prevención de desbordamiento de recursos de software: un ejemplo de perdida de

escalabilidad se muestra en el tipo de numero usado para las direcciones de internet. Es
difícil predecir la demanda que tendrá que soportar un sistema con años de anticipación.
Además, sobredimensionar para prever el crecimiento futuro pudiera ser peor que la
adaptación a un cambio cuando se hace necesario.

Evitación de cuellos de botella de prestaciones: en general para evitar los cuellos de

botella en prestaciones, los algoritmos deberían de ser descentralizados.

1.2.5 Control de errores

Los sistemas computacionales a veces fallan, cuando aparecen fallos en el hardware o en

el software los programas pueden producir resultados incorrectos o pudieran parar antes
de haber completado el cálculo pedido. Los fallos en un sistema distribuidos son
parciales; es decir, algunos componentes fallan mientras otros siguen funcionando. El
tratamiento de fallos es particularmente difícil.

Detección de fallos: algunos fallos son detectables, por ejemplo, se pueden utilizar sumas
de comprobación (checksums) para detectar datos corruptos en un mensaje o un archivo.

Enmascaramiento de fallos: algunos fallos que han sido detectados pueden ocultarse o
atenuarse. Dos ejemplos de ocultación de fallos son:

1. Los mensajes pueden retransmitirse cuando falla la recepción.

2. Los archivos con datos pueden escribirse en una pareja de discos de forma que si
uno está deteriorado el otro seguramente está en buen estado.

Tolerancia de fallos: la mayoría de los servicios en internet exhiben fallos; es posible que
no sea practico para ellos pretender detectar y ocultar todos los fallos que pudieran
aparecer en una red tan grande y con tantos componentes. Por ejemplo, cuando un
visualizador web no puede contactar con un servidor web no hará que el cliente tenga que
esperar indefinidamente mientras hace sucesivos intentos; informara al usuario del
problema, dándole la libertad de intentarlo más tarde.

Recuperación frente a fallos: la recuperación implica el diseño de software en el que, tras

una caída del servidor, el estado de los datos pueda reponerse o retractarse a una
situación anterior.

Redundancia: puede lograrse que los servicios toleren fallos mediante el empleo
redundante de componentes. El diseño de técnicas eficaces para mantener réplicas
actualizadas de datos que cambian rápidamente sin una perdida excesiva de prestaciones
es un reto.

1.2.6 Concurrencia
Tanto los servicios como las aplicaciones proporcionan recurso que pueden compartirse
entre los clientes en un sistema distribuido. Existe por lo tanto una posibilidad de que
varios clientes intenten acceder a un recurso compartido a la vez. El proceso que
administra un recurso compartido puede atender las peticiones de cliente una por una en
cada momento, pero esta aproximación limita el ritmo de producción del sistema
(throughput). Por esto los servicios y aplicaciones permiten usualmente, procesar
concurrentemente múltiples peticiones de los clientes.

1.2.7 Transparencia

se define transparencia como la ocultación al usuario y al programador de aplicaciones de

la separación de los componentes en un sistema distribuido, de forma que se perciba el
sistema como un todo más que como una colección de componentes independientes.

• Transparencia de acceso: permite acceder a los recursos locales y remotos

empleando operaciones idénticas.

• Transparencia de ubicación permite acceder a los recursos sin conocer su

localización.

• Transparencia de concurrencia permite que varios procesos operen

concurrentemente sobre recursos compartidos sin referencia mutua.

• Transparencia de replicación permite utilizar múltiples ejemplares de cada recurso

para aumentar la fiabilidad y las prestaciones sin que los usuarios y los
programadores se aplicaciones necesiten su conocimiento.

• Transparencia frente a fallos permite ocultar los fallos dejando que los usuarios y
programadores de aplicación completen sus tareas a pesar de fallos de hardware
o de los componentes software.

• Transparencia de movilidad permite la reubicación de recursos y clientes en un

sistema sin afectar la operación de los usuarios y los programas.

• Transparencia de prestaciones permite reconfigurar el sistema para mejorar las

prestaciones según varia su carga.

• Transparencia al escalado permite al sistema y a las aplicaciones expandirse en

un tamaño sin cambiar la estructura del sistema o los algoritmos de aplicación.

Los dos más importantes son la transparencia de acceso y la transparencia de ubicación;

su presencia o ausencia afecta principalmente a la utilización de recursos distribuidos.

1.3 Modelos arquitectónicos

La arquitectura de un sistema es su estructura en términos de los componentes

especificados por separado y sus interrelaciones. El objetivo de una arquitectura general
es asegurar que la estructura reunirá presentes y probables futuras demandas sobre el
mismo. Las principales preocupaciones son que el sistema sea fiable, manejable,
adaptable y rentable. La arquitectura de un sistema distribuido guarda algunos aspectos
similares con el diseño arquitectónico de un edificio, los cuales determinan no solo su
apariencia, sino también su estructura general y el estilo arquitectónico (gótico, neoclásico
y moderno) y proporciona un marco coherente de referencia para el diseño. Todos los
tipos de sistemas distribuidos tienen características básicas comunes. Un modelo de
arquitectura es una descripción abstracta simplificada pero consistente de cada aspecto
relevante del diseño de un sistema distribuido.

Modelo cliente – servidor: El modelo cliente-servidor es la arquitectura más citada cuando

se discuten los sistemas distribuidos. Es el modelo más importante y sigue siendo el más
ampliamente utilizado. En particular, los procesos de cliente interactúan con los procesos
de servidor individuales en equipos anfitriones (host) potencialmente separados, con el fin
de acceder a los recursos compartidos que administran.

El modelo cliente-servidor puede tomar diferentes configuraciones. Por ejemplo, puede

existir más de un cliente conectado a un servidor. También se puede tener un grupo de
servidores interconectados dedicados a dar servicio a un grupo de clientes.

Proxy: Es un servidor que se emplea como intermediario entre las peticiones de recursos
que realiza un cliente a otro servidor. Por ejemplo, si una computadora A solicita un
recurso a una computadora C, lo hará mediante una petición a la computadora B que, a
su vez, trasladará la petición a la computadora C. De esta manera, la computadora C no
sabrá que la petición procedió originalmente de la computadora A. Esta situación
estratégica de punto intermedio suele ser aprovechada para soportar una serie de
funcionalidades, como:

• Proporcionar caché.

• Control de acceso.

• Registro del tráfico.

• Prohibir cierto tipo de tráfico.

• Mejorar el rendimiento.

• Mantener el anonimato.

El proxy más conocido es el servidor proxy web, su función principal es interceptar la

navegación de los clientes por páginas web por motivos de seguridad, rendimiento,
anonimato, entre otros.

Peer-to-Peer: El paradigma peer-to-peer (P2P) ha sido un tema muy atractivo para

muchos investigadores de diferentes áreas, tales como redes, sistemas distribuidos,
teoría de la complejidad, bases de datos y otros. En el modelo cliente-servidor tradicional,
dos tipos de nodos son empleados: clientes y servidores. En este contexto, los clientes
solo solicitan servicios y el servidor solo proporciona a los clientes el servicio apropiado.
Un servidor puede aceptar varias solicitudes, procesarlas y devolver los contenidos
solicitados a los clientes. En la Internet actual, los clientes incluyen navegadores web,
clientes de chat en línea y clientes de correo electrónico, mientras que los servidores
normalmente son servidores web, servidores FTP y servidores de correo.
En contraste, en los sistemas P2P no se requiere una infraestructura dedicada. Los
servidores dedicados y clientes no existen, ya que cada peer puede tomar el papel tanto
de servidor como de cliente al mismo tiempo.

Applets: Un applet es un código que se ejecuta en el contexto de otro programa, por

ejemplo, en un navegador web. El código se descarga en el navegador y se ejecuta allí.
Un applet normalmente lleva a cabo una función muy específica, que carece de uso
independiente, y son ampliamente utilizados en aplicaciones de telefonía móvil. Un applet
puede dar una buena respuesta interactiva, ya que no sufre de los retrasos o variabilidad
de ancho de banda asociado con la comunicación de la red. Sin embargo, un applet
típicamente carece de sesión y tiene privilegios restringidos de seguridad.

Clúster: En informática, el término clúster (“grupo” o “racimo”) hace referencia a conjuntos

o conglomerados de computadoras construidos mediante el uso de hardware común y
que se comportan como si fueran una única computadora. El uso de los clústeres varía
desde las aplicaciones de supercómputo, servidores web y comercio electrónico hasta el
software de misiones críticas y bases de datos de alto rendimiento. El cómputo con
clústeres es el resultado de la convergencia de varias tendencias tecnológicas actuales,
entre las que se pueden destacar:

• Microprocesadores de alto rendimiento.

• Redes de alta velocidad.

• Software para cómputo distribuido de alto rendimiento.

• Crecientes necesidades de potencia computacional.

Los servicios esperados de un clúster principalmente son:

• Alto rendimiento.

• Alta disponibilidad.

• Escalabilidad.

• Balanceo de carga.

Un clúster puede ser:

• Homogéneo.

• Semihomogéneo.

• Heterogéneo.

Grid: El cómputo grid es un paradigma del cómputo distribuido, frecuentemente usado

para indicar una infraestructura de gestión de recursos distribuidos que se centra en el
acceso coordinado a los recursos informáticos remotos. Estos recursos de cómputo son
colectados desde múltiples localizaciones para alcanzar una meta común. A diferencia del
cómputo de cluster (en grupo o racimo), el cómputo grid tiende a ser más heterogéneo y
disperso geográficamente.

Arquitectura de capas

Una arquitectura de capa resulta familiar en los sistemas distribuidos y está relacionado
con la abstracción. Con este enfoque, un sistema complejo puede ser dividido en cierto
número de capas, donde las capas superiores hacen uso de los servicios ofrecidos por las
capas inferiores. De esta manera, una determinada capa ofrece una abstracción de
software, sin que las capas superiores o inferiores a esta deban de estar al tanto de los
detalles de implementación.

1.4 Modelo fundamentales

Todos los modelos de sistemas anteriores, aunque bien diferentes, comparten algunas
propiedades fundamentales. En particular, todos ellos se componen de procesos que se
comunican unos con otros mediante el envío de mensajes en una red de computadores.
En general un modelo contiene solamente aquellos ingredientes esenciales que
necesitamos para comprender y razonar sobre algunos aspectos del comportamiento del
sistema.

Modelo de interacción trata sobre el rendimiento y sobre la dificultad de poner límites

temporales en un sistema distribuido.

Modelo de fallo intenta dar una especificación precisa de los fallos que se pueden producir
en procesos y en canales de comunicación.

Modelo de seguridad posibles amenazas para los procesos y canales de comunicación.

1.5 Recursos de comunicación

El objetivo principal de las redes de computadoras es compartir recursos, de tal manera

que todos los programas, equipos y datos se encuentren disponibles para quien lo solicite
sin importar su ubicación. El uso de las redes de cómputo se ha incrementado durante los
últimos años. La comunicación por computadora se ha convertido en una parte esencial
de la infraestructura actual. La conectividad se usa en muchos aspectos y, con el
crecimiento continuo de la Internet, las demandas de enlaces de mayor capacidad
también han aumentado. En una red de cómputo, los datos son transmitidos entre
computadoras usando secuencia de bits para representar códigos. La capacidad de
transmisión de los datos, referida comúnmente como ancho de banda, es descrita en bits
por segundo (bit/s).

Las funciones relacionadas a la API sockets que permiten establecer una comunicación
entre dos computadoras son:

socket( )

Esta rutina se usa para crear un socket y regresa un descriptor correspondiente a este
socket. Este descriptor es usado en el lado del cliente y en el lado del servidor de su
aplicación. Desde el punto de vista de la aplicación, el descriptor de archivo es el final de
un canal de comunicación. La rutina retorna -1 si ocurre un error.

close( )

Indica al sistema que el uso de un socket debe de ser finalizado. Si se usa un protocolo
TCP (orientado a conexión), close termina la conexión antes de cerrarlo. Cuando el socket
se cierra, se libera al descriptor, por lo que la aplicación ya no transmite datos y el
protocolo de transportación ya no acepta mensajes de entradas para el socket.

bind( )

Suministra un número a una dirección local a asociar con el socket, ya que cuando un
socket es creado no cuenta con dirección alguna.

listen( )

Esta rutina prepara un socket para aceptar conexiones y solo puede ser usada en sockets
que utilizan un canal de comunicación virtual. Esta rutina se deberá usar del lado del
servidor de la aplicación antes de que se pueda aceptar alguna solicitud de conexión del
lado del cliente. El servidor encola las solicitudes de los clientes conforme estas llegan. La
cola de solicitudes permite que el sistema detenga las solicitudes nuevas mientras que el
servidor se encarga de las actuales.

accept( )

Esta rutina es usada del lado del servidor de la aplicación para permitir aceptar las
conexiones de los programas cliente. Después de configurar una cola de datos, el
servidor llama accept, cesa su actividad y espera una solicitud de conexión de un
programa cliente. Esta rutina solo es válida en proveedores de transporte de circuito
virtual. Cuando llega una solicitud al socket especificado accept( ) llena la estructura de la
dirección, con la dirección del cliente que solicita la conexión y establece la longitud de la
dirección, accept( ) crea un socket nuevo para la conexión y regresa su descriptor al que
lo invoca, este nuevo socket es usado por el servidor para comunicarse con el cliente y al
terminar se cierra. El socket original es usado por el servidor para aceptar la siguiente
conexión del cliente.

connect( )

Esta rutina permite establecer una conexión a otro socket. Se utiliza del lado del cliente de
la aplicación permitiendo que un protocolo TCP inicie una conexión en la capa de
transporte para el servidor especificado. Cuando se utiliza para protocolos sin conexión,
esta rutina registra la dirección del servidor en el socket, esto permite que el cliente
transmita varios mensajes al mismo servidor. Usualmente el lado cliente de la aplicación
enlaza a una dirección antes de usar esta rutina, sin embargo, esto no es requerido.

send( )

Esta rutina es utilizada para enviar datos sobre un canal de comunicación tanto del lado
del cliente como del lado servidor de la aplicación. Se usa para sockets orientados a
conexión, sin embargo, podría utilizarse para datagramas pero haciendo uso de connect( )
para establecer la dirección del socket.

sendto( )

Permite que el cliente o servidor transmita mensajes usando un socket sin conexión
(usando datagramas). Es exactamente similar a send( ) solo que se deberán especificar la
dirección destino del socket al cual se quiere enviar el dato. Se puede usar en sockets
orientados a conexión pero el sistema ignorará la dirección destino indicada en sendto( ).

recv( )

Esta rutina lee datos desde un socket conectado y es usado tanto en el lado del cliente
como del lado del servidor de la aplicación.

recvfrom( )

Esta rutina lee datos desde un socket sin conexión. En este caso, el sistema regresa la
dirección del transmisor con los mensajes de entrada y permite registrar la dirección del
socket transmisor en la misma forma que espera sendto( ), por lo que la aplicación usa la
dirección registrada como destino de la respuesta.

1.5.1 Protocolos TCP/IP

Los protocolos son un conjunto de reglas que gobiernan la interacción de procesos

concurrentes en sistemas distribuidos, estos son utilizados en un gran número de campos
como sistemas operativos, redes de computadoras o comunicación de datos. Uno de los
conjuntos de protocolos más usados en Internet y que usamos en los ejemplos de sockets
es el TCP/IP (Transmission Control Protocol / Internet Protocol). Este conjunto de
protocolos tiene menos capas que el OSI, lo que incrementa su eficiencia. TCP/IP es un
protocolo confiable, ya que los paquetes son recibidos en el orden en que son enviados.

Un servicio orientado a conexión requiere que dos aplicaciones establezcan una conexión
de transportación antes de comenzar el envío de datos. Para establecer la comunicación,
ambas aplicaciones primero interactúan localmente con protocolo de transporte y después
estos protocolos intercambian mensajes por la red. Una vez que ambos extremos están
de acuerdo y se haya establecido la conexión, las aplicaciones podrán enviar datos.

1.5.2 Servicios y puertos

El advenimiento de los sistemas de cómputo propició un campo ideal para que los
sistemas fueran abiertos, es decir que diferentes plataformas de diferentes fabricantes se
pudieran comunicar. Los especialistas del ISO (International Standard Organization)
crearon el OSI (Open System Interconnection), un modelo de referencia para la
interconexión de sistemas abiertos. El modelo ISO/OSI utiliza siete capas para organizar
una red en módulos funcionales bien definidos, con la cual los diseñadores puedan
construir redes reales, sin embargo, al ser este solo un modelo y no una norma, el
diseñador puede modificar el número, nombre y función de la red.

1.5.3 Procesos y demonios

La comunicación entre procesos es el núcleo de todos los sistemas distribuidos, por tal
razón es importante entender la manera en que los procesos localizados en diferentes
computadoras pueden intercambiar información. En los sistemas distribuidos
tradicionalmente la comunicación está basada en el paso de mensaje. Esta técnica aporta
sincronización entre procesos y permite la exclusión mutua, su principal característica es
que no requiere memoria compartida, por lo que resulta ser muy importante en la
programación de sistemas distribuidos.

La comunicación entre procesos es un factor clave para construir sistemas distribuidos,

los paradigmas de comunicación más usados en sistemas distribuidos son:

• Cliente - servidor.

• Llamada a un procedimiento remoto (RPC).

• Comunicación en grupo.

Los conceptos fundamentales que deben ser considerados para la comunicación son:

• Los datos tienen que ser aplanados antes de ser enviados.

• Los datos tienen que ser representados de la misma manera en la fuente y

destino.

• Los datos tienen que empaquetarse para ser enviados.

• Usar operaciones de send para enviar y receive para recibir.

• Especificar la comunicación, ya sea en modo bloqueante o no bloqueante.

• Abstracción del mecanismo de paso de mensaje.

• La confiabilidad de la comunicación. Por ejemplo, usar TCP en lugar de UDP.

Los hilos se diferencian de los procesos en que los primeros comparten los mismos
recursos del programa que las contiene, en tanto los procesos tienen de manera separada
su código, así como sus datos. Se pueden identificar hilos de dos tipos de flujo:

• Flujo único: En este caso, un programa utiliza únicamente un hilo para controlar su
ejecución.

• Flujo múltiple: Son aquellos programas que utilizan varios contextos de ejecución
para realizar su trabajo.

En un sistema multihilos, cada tarea se inicia y termina tan pronto como sea posible, esto
facilita la entrada de datos en sistemas en tiempo real, especialmente si estos datos
provienen de diferentes fuentes. En un programa multihilo se tiene el hilo principal del
programa en ejecución, quien a su vez tiene otros hilos o tareas paralelas en ejecución.
Un hilo se define como una secuencia única de control de flujo dentro de un programa, en
un programa puede haber más de una secuencia de control o hilos. Un hilo es una parte
del programa que se ejecuta independientemente del resto.

En un sistema distribuido, el cliente es el elemento que solicita y usa el servicio que

proporciona una funcionalidad específica o dato. El cliente tiene una postura proactiva,
esto quiere decir que está trabajando en una tarea específica y cuando necesita cierto
dato o una operación específica invoca al servidor para obtenerlo.

El servidor es el elemento que proporciona la funcionalidad o servicio en un sistema

distribuido. Este servicio puede consistir en compartir datos, informar sobre una solicitud,
compartir recursos físicos, imprimir, etc. Generalmente se considera que un servidor tiene
una posición reactiva en el sistema, ya que se encuentra inactivo hasta que recibe una
petición de servicio. Cuando recibe la petición, la procesa y envía la respuesta al
solicitante, para después quedar nuevamente inactivo en espera de una nueva petición.
Referencias
Coulouris G, Dollimore, Kindberg T. Sistemas Distribuidos, Conceptos y Diseño, Tercera
edición, Addison Wesley, Estados Unidos, 2001. 719pp.

López Fuentes, Francisco de Asís, Sistemas distribuidos / Francisco de Asís López

Fuentes. -- México: UAM, Unidad Cuajimalpa, c2015. 200 p.: il., diagramas, col.; 24 cm.
(Una década de la Unidad Cuajimalpa de la Universidad Autónoma Metropolitana)

S Tanenbaum, Andrews, Sistemas operativos distribuidos, Primera edición, Prentice Hall,

Amsterdam, Netherlands, 1996. 617pp.