11.05.2013 Views

Mecanismos de Difusión Masiva en Aplicaciones Distribuidas - dtic ...

Mecanismos de Difusión Masiva en Aplicaciones Distribuidas - dtic ...

Mecanismos de Difusión Masiva en Aplicaciones Distribuidas - dtic ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Para evitar esta saturación <strong>en</strong> el canal <strong>de</strong> retorno, una <strong>de</strong> las técnicas<br />

que suel<strong>en</strong> aplicarse es cambiar las confirmaciones por paquetes <strong>de</strong><br />

información <strong>de</strong> pérdidas (NACK’s) [11].<br />

En casos <strong>de</strong> pocas pérdidas <strong>en</strong> la comunicación, esta técnica reduce<br />

drásticam<strong>en</strong>te la información <strong>de</strong> control <strong>en</strong> la comunicación e incluso,<br />

<strong>en</strong> casos óptimos, podría evitarse totalm<strong>en</strong>te.<br />

Sin embargo la falta <strong>de</strong> confirmación por parte <strong>de</strong> los receptores<br />

produce una serie <strong>de</strong> inconv<strong>en</strong>i<strong>en</strong>tes. En el caso <strong>de</strong> que por ejemplo <strong>en</strong><br />

todo el proceso <strong>de</strong> transmisión no se produzca la recepción por parte<br />

<strong>de</strong>l emisor <strong>de</strong> ningún paquete NACK, no significa que todos los<br />

paquetes <strong>de</strong> datos hayan sido recibidos por todos los receptores;<br />

pue<strong>de</strong> existir algún problema <strong>en</strong> el canal <strong>de</strong> vuelta que evite la<br />

recepción <strong>de</strong> dichos paquetes. Por lo tanto, con el simple uso <strong>de</strong> los<br />

paquetes NACK no se pue<strong>de</strong> garantizar la confiabilidad <strong>de</strong> la<br />

comunicación. Una posible solución a este problema sería el <strong>en</strong>vío <strong>de</strong><br />

un único paquete <strong>de</strong> confirmación al final <strong>de</strong> toda la transmisión, <strong>de</strong><br />

manera que el servidor tuviera la seguridad <strong>de</strong> la correcta recepción <strong>de</strong><br />

la información. Esto implicaría una pérdida <strong>de</strong> escalabilidad por la<br />

<strong>de</strong>p<strong>en</strong><strong>de</strong>ncia que volveríamos a t<strong>en</strong>er <strong>de</strong>l número <strong>de</strong> receptores, si<br />

bi<strong>en</strong> este <strong>en</strong>vío sería único y localizado siempre al final <strong>de</strong> la<br />

transmisión.<br />

2.5 Control <strong>de</strong> flujo<br />

Otro <strong>de</strong> los problemas que se plantea con el cambio <strong>de</strong> ACK’s por<br />

NACK’s es la pérdida <strong>de</strong> la sincronización <strong>en</strong> la comunicación. Si bi<strong>en</strong><br />

mediante el uso <strong>de</strong> las confirmaciones el emisor y el receptor se<br />

<strong>en</strong>cu<strong>en</strong>tran siempre acompasados <strong>en</strong> el flujo <strong>de</strong> la transmisión ya que<br />

el emisor no <strong>en</strong>vía el sigui<strong>en</strong>te paquete hasta no t<strong>en</strong>er confirmado el<br />

anterior, con el uso <strong>de</strong> NACK’s esto no pue<strong>de</strong> realizarse. Mi<strong>en</strong>tras el<br />

emisor difun<strong>de</strong> los paquetes <strong>de</strong> datos no ti<strong>en</strong>e información sobre el<br />

estado ni la cantidad <strong>de</strong> paquetes recibidos por cada receptor. El<br />

principal problema que se <strong>de</strong>riva <strong>de</strong> esta situación es una falta <strong>en</strong> el<br />

control <strong>de</strong> flujo o ratio <strong>de</strong> transmisión, es <strong>de</strong>cir, el emisor podría estar

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!