Tipos de Fallas en Sistemas RPC, Sistemas Concurrentes y Distribuidos

Universidad de Guadalajara
Centro Universitario de Ciencias Exactas e Ingenierías
Sistemas Concurrentes y Distribuidos
Felipe Alejandro Jimenez Castillo - 215671386

Índice
Introducción...........................................................................................................................3
Clases de fallas en los sistemas RPC.....................................................................................4
Conclusión..............................................................................................................................7
Bibliografía............................................................................................................................8
Introducci ón
La comunicación confiable entre cliente y servidor es un reto para las metodologías y

algoritmos que se deben implementar y desarrollar. En este documento se observará una de
ellas, RPC, y como, aunque es la favorita para las comunicaciones entre sistemas distribui-
dos, demuestra tener fallas y redundancias en sus paradigmas de implementación; Esto nos
lleva a observar problemas de recepción en el servidor, problemas de recepción en el cliente,
cálculos inmenso e indeseados en CPU y más.
Clases de fallas en los sistemas RPC
El cliente no puede localizar al servidor.

• ¿Qué sucede, que problemáticas se enfrentan, se puede solucionar?
◦ El servidor puede estar inactivo y no ser localizado.
◦ Al existir diferentes versiones compiladas de la interfaz de comunicación en servidor y
cliente, este ultimo será incapaz de mantenerse a la par del servidor y reportara una fa-
lla.
◦ La solución más simple es hacer que el error haga surgir una excepción utilizando ma -
nejadores de señales. Esto a coste de la transparencia del error.
Se pierde el mensaje de solicitud del cliente al servidor.

◦ El servidor pierde el mensaje de solicitud del cliente.
◦ La problemática principal es la perdida de solicitud y por lo tanto concluir que el servi-
dor está inactivo.
◦ Para solucionarlo solo se tiene que asegurarse de que el sistema operativo o el res -
guardo del cliente inicie un cronómetro que mantendrá la caducidad del mensaje, si es -
to sucede el cliente reenviará la solicitud.
Se pierde el mensaje de respuesta del servidor al cliente.

• ¿Qué significa que una solicitud sea idempotente?
◦ Petición que no tiene efectos secundarios y puede ser ejecutada tan a menudo como
se necesite sin ningún perjuicio.

◦ El cliente no recibe el mensaje de repuesta a petición, por lo que no se sabe si la peti -
ción fue efectuada o no.
◦ La principal problemática es con las solicitudes no idempotentes, que pueden, si se
pierde la respuesta, ser efectuadas múltiples veces y ocasionar daños o riesgos de se -
guridad y confiabilidad.
◦ La solución a este problema es tratar de estructurar todas las solicitudes como idem-
potentes, sin embargo esto no es posible en todos los casos; Otra solución es asignar
un número de secuencia a las peticiones, de esta forma se identifica si una solicitud es
original o retransmisión y puede obviarse su ejecución. Finalmente esto puede obviarse
asignando un bit a los encabezados de las peticiones, que identifique si es la original o
una retransmisión.
El servidor falla antes de recibir una solicitud
◦ En está problemática el servidor fallá o se congela antes de recibir una solicitud del
cliente.
◦ La problemática principal es con el cliente, ya que esté no sabe si el servidor no está
activo, si se congelo después de recibir la petición o antes de enviar la respuesta.
◦ Esté problema se puede solucionar con 3 diferentes paradigmas:
A) Semántica de por lo menos una vez
1. En está se intenta la petición hasta que se recibe por lo menos una respuesta
del servidor.
B) Semántica a lo más una vez
1. En está solo se realiza una vez la petición, por lo que se garantiza que la opera-
ción se realizo como máximo una vez y no más, aunque posiblemente ninguna.
C) No garantizar nada
1. En está no se obtiene ayuda ni promesas sobre lo que sucedió, por lo que la pe-
tición puede ser realizada, ninguna, una o muchas veces.
El cliente falla después de enviar una solicitud.

◦ En está problemática el cliente falla o se congela tras enviar una solicitud al servidor.
◦ La problemática principal es que el cliente puede no recibir la respuesta del servidor a
su petición, lo que conlleva que el cliente retransmita la petición un número indefinido
de veces, según sea el paradigma implementado en el servidor sobre las retransmisio-
nes.
◦ La solución es la creación de una bitácora de solicitudes, que obvien si una operación
ya fue realizada.
Un procedimiento no puede encontrar su destino se genera un huérfano, ¿Qué se puede hacer

con los huérfanos?
• Exterminación
◦ Mantener una bitácora de las operaciones que se están a punto de hacer, en algún me-
dio que sobreviva al congelamiento. Finalmente después del reinicio, se revisa la bitá -
cora y el huérfano puede ser explícitamente eliminado.
• Reencarnación
◦ La forma en que funciona es dividiendo el tiempo en épocas numeradas en secuencia,
cuando un cliente se reinicia, transmite un mensaje a todas las máquinas para indicar -
les el inicio de una nueva época, cuando tal transmisión llega, todos los cálculos reali -
zados a nombre de dicho cliente son eliminados.
• Reencarnación sutil
◦ Está se basa en la reencarnación y las épocas, cuando llega una transmisión de época,
cada máquina ve si tiene cálculos remotos ejecutándose localmente, y de ser así, hace
lo que puede para localizar a sus propietarios. Sólo si los propietarios no pueden ser lo-
calizados en ninguna parte el cálculo se elimina.
• Expiración
◦ A cada RPC se le asigna un cantidad estándar de tiempo, Ƭ, para que realice el trabajo,
si no puede terminarlo, explícitamente debe solicitar otra cantidad de tiempo, lo cual es
una molestia. Por otra parte, si después de congelarse el cliente espera cierto tiempo T
antes de volverse a iniciar, con seguridad habrán desaparecido todos los huérfanos.
Conclusión
Tras el análisis de las fallás en el sistema RPC, nos damos cuenta que ningún algorit-
mo es eficiente como quisiéramos, ya que siempre existe un margen de error en las comuni -
caciones y sistemas que interactúan. El análisis nos llevo a observar las fallás en el cliente,
el servidor, las combinaciones de estas dos partes y todos los paradigmas que se abordan,
según sea el caso de implementación, lo que nos deja con la merá decisión de observar y
juzgar cual es la mejor estrategia para nuestros problemas y recursos.
Bibliografía
• Tanenbaum, A.,& Van Steen M.(2008). Sistemas Distribuidos, Principios y Paradigmas. (Segunda
ed.). Prentice Hall.

Tipos de Fallas en Sistemas RPC, Sistemas Concurrentes y Distribuidos

Cargado por

Copyright:

Formatos disponibles

Tipos de Fallas en Sistemas RPC, Sistemas Concurrentes y Distribuidos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tipos de Fallas en Sistemas RPC, Sistemas Concurrentes y Distribuidos

Cargado por

Copyright:

Formatos disponibles

Universidad de Guadalajara

Centro Universitario de Ciencias Exactas e Ingenierías

Sistemas Concurrentes y Distribuidos

Felipe Alejandro Jimenez Castillo - 215671386

La comunicación confiable entre cliente y servidor es un reto para las metodologías y

El cliente no puede localizar al servidor.

Se pierde el mensaje de solicitud del cliente al servidor.

Se pierde el mensaje de respuesta del servidor al cliente.

• ¿Qué sucede, que problemáticas se enfrentan, se puede solucionar?

El cliente falla después de enviar una solicitud.

Un procedimiento no puede encontrar su destino se genera un huérfano, ¿Qué se puede hacer

También podría gustarte