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