Comunicación Confiable de Grupo

Descargar como pptx, pdf o txt
Descargar como pptx, pdf o txt
Está en la página 1de 12

4.

4 COMUNICACIÓN
CONFIABLE EN GRUPO
Sistemas operativos II
José Patricio González Cervantes
Gerardo Sierras Vasquez
ESQUEMAS DE MULTITRANSMISIÓN
BÁSICOS CONFIABLES

 Intuitivamente la comunicación confiable, significa que un mensaje enviado


a un grupo de procesos deberá ser entregado a cada uno de los miembros de
dicho grupo.
 se considera que la multitransmisión es confiable cuando puede
garantizar que todos los miembros no defectuosos del grupo recibirán
el mensaje. La parte engañosa es que deberá llegarse a un acuerdo
sobre cómo se ve en realidad el grupo antes de que un mensaje pueda
ser entregado, además de implementar varias restricciones en cuanto al
orden de entrega.
 Cada mensaje multitransmitido se guarda localmente en un bufer
de historial en el remitente.
 Suponiendo que el remitente conoce a los destinatarios, éste
simplemente conserva el mensaje en su búfer de historial hasta
que cada destinatario haya devuelto un acuse de recibo. Si un
destinatario detecta que se perdió un mensaje, regresa un acuse de
recibo negativo, solicitando al remitente que retransmita el
mensaje. De otro modo, el remitente puede retransmitir
automáticamente el mensaje cuando no haya recibido todos los
acuses de recibo dentro de cierto tiempo.
ESCALABILIDAD EN
MULTITRANSMISIÓN CONFIABLE

 El problema principal con el esquema de multitransmisión confiable que se


acaba de describir es que no puede soportar un gran número de destinatarios.
Si existen N destinatarios, el remitente debe estar preparado para aceptar por lo
menos N acuses de recibo. Con muchos destinatarios, el remitente puede verse
abrumado por los mensajes de retroalimentación, ello también se conoce como
implosión de retroalimentación.
 Una solución a este problema es no hacer que los destinatarios confirmen la
recepción de un mensaje. En cambio, un destinatario devuelve un mensaje de
retroalimentación sólo para informar que el remitente no envió un mensaje.
Regresando sólo acuses de recibo negativos
 Otro problema con la devolución de sólo acuses de recibo
negativos es que el remitente, en teoría, se verá obligado a
conservar por siempre un mensaje en un bufer de historial. Como
puede ser que el remitente nunca sepa si un mensaje ha sido
entregado correctamente a todos los destinatarios,

 el remitente borrará un mensaje de su bufer de historial después


de transcurrido cierto tiempo, para evitar que el bufer se
sobrecargue. No obstante, la eliminación de un
CONTROL DE
RETROALIMENTACIÓN NO
JERÁRQUICO

 El tema fundamental en relación con soluciones


escalables para multitransmisión confiable es reducir el
número de mensajes de retroalimentación devueltos al
remitente. Un modelo popular usado en varias
aplicaciones de área amplia es la supresión de
retroalimentación. Este esquema sirve de fundamento
al protocolo de multitransmisión confiable escalable
(SRM, del inglés Scalable Reliable Multicasting)
 En primer lugar, en SRM los destinatarios nunca confirman la entrega exitosa de un mensaje
multitransmitido, sino que informan sólo cuando no reciben un mensaje. El cómo detectar la pérdida
de un mensaje se deja a la aplicación. Sólo se devuelven acuses de recibo negativos como
retroalimentación. Siempre que un destinatario advierta que le falta un mensaje, multitransmite su
retroalimentación al resto del grupo.
 La multitransmisión mediante retroalimentación permite que otro miembro del grupo cancele su
propia retroalimentación. Supongamos que varios destinatarios no reciben el mensaje m.
 Cada quien tendrá que devolver un acuse negativo al remitente, S, de modo que m pueda ser
retransmitido.
 No obstante, si se supone que las retransmisiones siempre se multitransmiten a todo el grupo, es
suficiente con que S reciba sólo una solicitud de retransmisión.
MULTITRANSMISIÓN ATÓMICA

 En particular, lo que a menudo se requiere en un sistema distribuido es la


garantía de que un mensaje sea entregado o a todos los procesos o a ninguno
en absoluto.
 Además, en general, también se necesita que todos los mensajes sean
entregados en el mismo orden a todos los procesos. Esto es conocido también
como problema de
 El emisor comienza con el envió de un mensaje a todos los miembros del
grupo, los cronómetros se activan y se envían las retransmisiones en los casos
necesarias
 Cuando un proceso recibe un mensaje
 Si no recibió el mensaje particular
 Lo envía a todos los miembros del grupo

También podría gustarte