UNIDAD 2

“INVESTIGACIÓN SEGUNDA UNIDAD”

CARRERA

INGENIERÍA INFORMÁTICA

ASIGNATURA
SISTEMAS OPERATIVOS II

PRESENTA
RODRIGO MALDONADO SORIANO

NUMERO DE CONTROL
181230059

SEMESTRE
5

DOCENTE
OSCAR VENANCIO CHORA

SAN MARCOS GUERRERO, MEX. NOVIEMBRE DEL 2020

1
 ÍNDICE
INTRODUCCIÓN..................................................................................................................3

HILOS.....................................................................................................................................4

CLIENTE................................................................................................................................5

SERVIDORES.......................................................................................................................5

COMUNICACIÓN ENTRE PROCESOS...........................................................................6

MODELO CLIENTE - SERVIDOR (C-S ).........................................................................7

INTERFAZ DE PROGRAMACIÓN DE APLICACIONES (API )...................................9

LA INTERFAZ DE SOCKET...............................................................................................9

FUNCIONES DE LA API DE SOCKETS........................................................................10

COMUNICACIÓN ORIENTADA A CONEXIÓN (TCP )...............................................12

SINCRONIZACIÓN............................................................................................................13

SINCRONIZACIÓN DE RELOJES..............................................................................13

ALGORITMOS PARA LA SINCRONIZACIÓN DE RELOJES....................................14

EL ALGORITMO DE LAMPORT..................................................................................14

EL ALGORITMO DE CHRISTIAN...............................................................................15

EL ALGORITMO DE BERKELEY................................................................................16

CONCLUSIÓN....................................................................................................................17

BIBLIOGRAFÍA...................................................................................................................18

2
 INTRODUCCIÓN
En este trabajo lo que se pretende realizar es un resumen acerca de la segunda
unidad de la asignatura de sistemas operativos II esto con la finalidad de poder
entender mejor la unidad y comprender a si cada elemento , los temas que se
vienen en la unidad tiene referencia con la comunicación que se realiza entre
cliente servidor , para lograr esta comunicación se tomara en cuenta también hilos
y hebras , pues estas estructuras son importantes, de esta manera también se
tienen que seguir protocolos como por ejemplo los protocolos API , esto con la
finalidad de poder realizar una buena comunicación entre el cliente y servidor.

La comunicación entre procesos es el núcleo de todos los sistemas distribuidos

[Tanenbaum & Van Steen, 2008], por tal razón es importante entender la manera
en que los procesos localizados en diferentes computadoras pueden intercambiar
información.

A continuación se muestra la investigación espero que sea de su agrado.

3
 HILOS
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. El uso de hilos permite al programador escribir
programas más eficientes, debido a que los hilos permiten optimizar recursos tan
importantes como el mejor desempeño del CPU al minimizar sus tiempos de
inactividad. El uso de hilos es muy valioso en entornos interactivos en red, ya que
permiten sincronizar la diferencia entre la velocidad de transmisión de la red con
las de procesamiento del CPU. La figura ilustra esquemáticamente un programa
de un hilo y un programa de dos hilos

Figura 4.1. Comparación entre hilos:

a) Programa con un solo hilo, b) Programa multihilos

a) b)

4
 CLIENTE
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.
Generalmente es por medio de la aplicación cliente que un usuario accede y
mantiene un diálogo con el sistema. El usuario realiza el diálogo vía una interfaz
gráfica de usuario. La operación del cliente consiste en arrancar, realizar su
trabajo y terminar.

SERVIDORES
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. En un sistema, el modo de
ejecución de un servidor es continuo, ya que se inicializa al arrancar el sistema y
está en operación hasta que el sistema se apaga. Un servidor tiene dos modos de
arranque:

• Estático.
• Dinámico.

Un arranque estático sucede cuando el servidor se arranca como parte del

arranque general del sistema donde se encuentra localizado. En contraste, un
arranque dinámico sucede cuando un servidor es activado por un proceso del
cliente que solicite sus servicios.

Los servidores forman parte importante del middleware básico de un sistema

distribuido. Entre las características fundamentales de los servidores destaca que

5
pueden ser reusables y relocalizarse. Los servidores pueden ser usados en
diferentes tareas, entre las que se pueden destacar las siguientes:

• Servidores de datos.
• Servidores de archivos.
• Servidores de impresión.
• Servidores de correo.
• Servidores de programas.
• Servidores de bases de datos.
• Servidores de fecha y hora.
• Servidores de multimedia.
• Servidores de transacciones.
• Servidores web.

COMUNICACIÓN ENTRE PROCESOS

La comunicación entre procesos es un factor clave para construir sistemas
distribuidos, los paradigmas de comunicación más usados 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.

6
 MODELO CLIENTE - SERVIDOR (C-S )
El término cliente - servidor (C-S) hace referencia a la comunicación en la que
participan dos aplicaciones. Es decir que está basado en la comunicación de uno
a uno. La aplicación que inicia la comunicación enviando una petición y esperando
una respuesta se llama cliente. Mientras los servidores esperan pasivos, aceptan
peticiones recibidas a través de la red, realizan el trabajo y regresan el resultado o
un código de error porque no se generó la petición. Una máquina puede ejecutar
un proceso o varios procesos cliente. La transferencia de mensaje en el modelo C-
S se ejecuta en el núcleo. Una operación general del funcionamiento del cliente -
servidor se muestra en la figura 4.2, donde un servidor espera una petición sobre
un puerto bien conocido que ha sido reservado para cierto servicio. Un cliente
reserva un puerto arbitrario y no usado para poder comunicarse.

Modelo cliente - servidor

Características del software cliente - servidor

El software cliente es un programa de aplicación que se vuelve cliente temporal

cuando se necesita acceso remoto. Este programa llama directamente al usuario y
se ejecuta sólo durante una sesión. Se ejecuta localmente en la computadora del
usuario y se encarga de iniciar el contacto con el servidor. Este programa puede
acceder a varios servicios y no necesita hardware especial ni un complejo sistema
operativo. Por su parte, el software servidor es un programa especial de
propósitos dedicados a ofrecer un servicio pero que puede manejar varios clientes
remotos al mismo tiempo. Este programa se inicia automáticamente al arranque
del sistema y continuará ejecutándose en varias sesiones. El servidor espera
pasivamente el contacto de los clientes remotos. Por lo general, el software

7
servidor necesita ser instalado en un sistema operativo más robusto y contar con
mucha capacidad de recursos de hardware. En la figura 4.3 se muestra un
seudocódigo para un eco (echo) para un cliente - servidor (C-S).

Seudocódigo para un eco entre cliente y servidor [Lin,

Hsieh, Du, Thomas & McDonald, 1995]

La comunicación cliente - servidor puede ser implementada a través de librerías

PVM (Parallel Virtual Machine) o sockets que permiten implementar
comunicaciones bloqueantes y no bloqueantes, además de que también pueden
usar TCP para tener comunicaciones confiables.

Deficiencias del modelo cliente - servidor

• El paradigma de comunicación es la entrada/salida (E/S), ya que estos no son

fundamentales en el cómputo centralizado.
• No permite la transparencia requerida para un ambiente distribuido.
• El programador debe de atender la transferencia de mensajes o las E/S, tanto
del lado del cliente como del lado del servidor.

8
 INTERFAZ DE PROGRAMACIÓN DE APLICACIONES (API )
Las aplicaciones clientes - servidor se valen de protocolos de transporte para
comunicarse. Las aplicaciones deben de especificar los detalles sobre el tipo de
servicio (cliente o servidor), los datos a transmitir y el receptor donde situar los
datos. La interfaz entre un programa de aplicación y los protocolos de
comunicación de un sistema operativo se llama interfaz de programación de
aplicaciones (API).

Un API define un conjunto de procedimientos que puede efectuar una aplicación al

interactuar con el protocolo. Por lo general, un API tiene procedimientos para cada
operación básica. Los programadores pueden escoger una gran variedad de APIs
para sistemas distribuidos. Algunas de estas son BSD socket, Sun’s RPC/XDR,
librería de paso de mensajes PVM y Windows Sockets. La API de socket, que tuvo
sus orígenes en el UNIX BSD, se convirtió en una norma de facto en la industria y
muchos sistemas operativos la han adoptado, tanto para computadoras basadas
en Widows (winsock) como para algunos sistemas UNIX.

LA INTERFAZ DE SOCKET
Un socket es un punto de referencia hacia donde los mensajes pueden ser
enviados, o de donde pueden ser recibidos. Al llamar la aplicación a un
procedimiento de socket, el control pasa a una rutina de la biblioteca de sockets
que realiza las llamadas al sistema operativo para implementar la función de
socket. UNIX BSD y los sistemas derivados contienen una biblioteca de sockets, la
cual puede ofrecer a las aplicaciones una API de socket en un sistema de
cómputo que no ofrece sockets originales.

Los sockets emplean varios conceptos de otras partes del sistema, pero en
particular están integrados con la E/S, por lo que una aplicación se comunica con
un socket de la misma forma en que se transfiere un archivo. Cuando una
aplicación crea un socket, recibe un descriptor para hacer referencia a este. Si un
sistema usa el mismo espacio de descriptor para los sockets y otras E/S, es
posible emplear la misma aplicación para transferir datos localmente como para su

9
uso en red. La ventaja del método de socket es que la mayor parte de las
funciones tienen tres o menos parámetros, sin embargo, se debe llamar a varias
funciones a este método.

FUNCIONES DE LA API DE SOCKETS

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

10
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( )

11
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.

COMUNICACIÓN ORIENTADA A CONEXIÓN (TCP )

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. La secuencia de llamadas para un escenario
orientado a conexión se indica en la figura.

Uso del API socket para una comunicación orientada a conexión

[Jamsa & Cope, 1996]

12
En la Figura anterior se observa que, después de llamar a listen( ), el servidor se
pone en modo pasivo hasta que recibe una solicitud del cliente. Cuando la solicitud
de servicio del cliente llega al socket monitoreado por la función accept( ), se crea
de modo automático un socket nuevo, que será conectado inmediatamente con el
proceso cliente. Este socket se llama de servicio y se cierra al terminar la
transferencia de datos.

SINCRONIZACIÓN
La sincronización en sistemas distribuidos es más complicada que en un sistema
centralizado, ya que se debe de considerar algunos de los siguientes puntos:

• Que la información se distribuye en varias máquinas.

• Los procesos toman decisiones con base en información local.
• Se debe evitar un punto único de falla.
• No existe un reloj común, como tampoco otra fuente de tiempo global.

SINCRONIZACIÓN DE RELOJES
Para la sincronización de relojes existen las siguientes alternativas:

Relojes lógicos
• Según Lamport, la sincronización de relojes no debe ser absoluta, debido a
que si dos procesos no interactúan entre sí, no requieren que sus relojes estén
sincronizados.

13
• La distorsión de reloj es la diferencia entre los valores de tiempo de los
diferentes relojes locales.
• Aquí importa el orden de ocurrencia de los eventos, no la hora exacta.

Relojes físicos
• Usan el tiempo atómico internacional (TAI) y el tiempo coordenado universal
(UTC).
• Se pueden sincronizar por medio de radios de onda corta.
• También se puede usar satélite para sincronizar.

ALGORITMOS PARA LA SINCRONIZACIÓN DE RELOJES

EL ALGORITMO DE LAMPORT
Lamport define una relación temporal llamada: ocurre antes de. Por ejemplo, (a →
b) se interpreta como “a ocurre antes de b”. Para ilustrar esto, consideremos la
siguiente situación:

1. Si a y b son eventos del mismo proceso y a ocurre antes que b, entonces a

→ b es verdadero.
2. Si a es un envío de un mensaje por un proceso y b es la recepción del
mensaje por otro proceso, entonces a → b es verdadero.
3. Eventos concurrentes: si a → b no es verdadero ni b → a tampoco.

Se requieren valores de tiempo para medir el tiempo:

• Si a → b, entonces C (a) < C (b).

• C siempre es creciente (se pueden hacer correcciones hacia adelante pero no
hacia atrás).
• Para todos los eventos a y b, tenemos que C(a) ≠ C (b).

Un ejemplo de tres procesos (P1, P2 y P3), donde cada uno tiene su propio reloj a
diferentes velocidades se muestra en la figura 5.1a, mientras que en la figura 5.1b
se muestra la corrección de los relojes usando el algoritmo de Lamport.

14
Figura 5.1. Un ejemplo del algoritmo de Lamport en tres procesos

EL ALGORITMO DE CHRISTIAN
En este algoritmo un servidor central provee el tiempo por petición del usuario,
este servidor es conocido como servidor del tiempo (ver figura 5.2).

Figura 5.2. Actualizando la hora a través de un servidor de tiempo

La operación de este algoritmo se resume a continuación:

• Periódicamente cada máquina envía un mensaje para solicitar el tiempo actual

a este servidor.
• El servidor de tiempos responde con un mensaje que contiene el tiempo actual
t.
• La máquina emisora puede poner su tiempo en t + T trans.
• Un problema grave es que, como el tiempo nunca corre hacia atrás, el valor
actual del tiempo del emisor podría ser mayor al valor de t+T trans, lo que
perjudicaría a los archivos compilados.
• Otro problema es el tiempo de propagación (T trans), el cuál es distinto de 0 y
varía según la carga en la red.

15
• Una estimación del tiempo de propagación sería realizado por el reloj de la
máquina emisora calculando (T1 - T0)/2 e incrementándolo al llegar el valor t.
• Si se conoce el tiempo que tarda el servidor en manejar la interrupción (t I), la
estimación de tiempo puede mejorar con base en la siguiente expresión: (T 1- T0
- tI) / 2.
• Christian sugiere hacer varias mediciones para mejorar la precisión y descartar
los valores límites de (T1-T0), ya que estos están en función de la operación de
la red.

EL ALGORITMO DE BERKELEY
En este algoritmo una computadora maestra pide periódicamente a las
computadoras esclavas sus relojes y efectúa la sincronización (ver figura 5.3). Se
calcula un tiempo promedio, el cual es tomado como base si este no se diferencia
más de un valor base. La computadora maestra envía los desfases de tiempo a
los esclavos para que avancen su reloj o disminuyan la velocidad del mismo hasta
lograr una reducción específica.

Figura 5.3. Representación del algoritmo de

Berkeley [Tanenbaum & Van Steen, 2008]

16
 CONCLUSIÓN
Para concluir con este trabajo podemos decir que cumple la función principal la
cual era que el amino desfolle la capacidad de poder investigar los temas que
comprende la unidad y de esta manera poder repasar los temas , recordando la
importancia de poder comprender los temas puesto que se abonara al perfil de
egreso de nuestra carrera pues la comunicación entre cliente servidor es muy
importante en la carrera pues el cliente dará la orden que es lo que necesita
realizar con el servidor por ejemplo podemos mostrar un mensaje tomando como
referencia la palabra hola , esta misma palabra se mostrara en el cliente y a su vez
también se mostrara en el servidor, tenemos que tener presente los protocolos de
servicio que tenemos haciendo referencia al protocolo API, para poder realizar la
comunicación cliente servidor , tenemos que poner en practica la utilización de
hilos y hebras.

17
 BIBLIOGRAFÍA
Adve, S. & Hill, M. (1990). Weak Ordering: A New Definition, 17th Annual International
Symposium on Computer Architecture, pp.2-14, Seattle, WA, USA.

Akami (2014). Web: www.akami.com. Accedido: 5 de Octubre de 2014.

Amazon Web Services, Inc (2014) Amazon Elastic Load Balancer. Web:
http://aws.amazon.com/elasticloadbalancing/. Accedido: 5 de Octubre de 2014.

Apostolopoulos, J. G., Tan, W. T. & Wee, S. J. (2002). Video Streaming: Concepts,

Algorithms, and Systems, Technical Report HPL-2002-260, HP Laboratories Palo Alto.

Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R. H., Konwinski, A., Lee, G.,
Patterson, D. A., Rabkin, A., Stoica, I. & Zanaria, I. (2009). Above the Clouds: A
Berkeley View of Cloud, Technical Report No. UCB/EECS2009-28, University of
California at Berkeley, Berkeley, CA, USA.

Babaoglu, O., Marzolla, M. & Tamburini, M. (2012). Design and implementation of a P2P
cloud system, 27th Annual ACM Symposium on Applied Computing (SAC’12), pp.
412–417, Trento, Italy.

Banerjee, S., Bhattacharjee, B. & C. Kommareddy, C. (2002). Scalable Application Layer

Multicast, Proceedings of the ACM SIGCOMM’02, pp. 205217 , Pittsburgh, PA, USA.

Berstis, V. (2005). Fundamentals of Grid Computing, IBM Corporation, ReedBooks paper.

18