[jboss-jira] [JBoss JIRA] Updated: (JGRP-377) TLS: implement OOB handling in UNICAST

[ http://jira.jboss.com/jira/browse/JGRP-377?page=all ] Bela Ban updated JGRP-377: -------------------------- Summary: TLS: implement OOB handling in UNICAST (was: TLS: implement OOB handling in UNICAST and NAKACK) Description: - How are OOB messages handled by UNICAST ? Are these 2 effectively ignoring OOB flags ? Does it make sense to use OOB messages in protocols *above* UNICAST ? Exampe: GMS sending VIEW_ACK messages. Logic in UNICAST: - Receive OOB message, place in receiver table - Pass up the OOB message *immediately*, regardless of whether it is in sequence ! - When message is finally removed, do *NOT* pass it up when marked as OOB ! Example (for UNICAST): - We receive 1, 2, 4(OOB) , 5 - Messages 1 and 2 are delivered and removed from the table (AckReceiverTable) - Message 4 is added to AckReceiverWindow and *delivered* (passed up) - Message 3 is received, added to AckReceiverWindow and delivered - Message 4 is removed, but *not* delivered because it has already been delivered - Message 5 is removed from AckreceiverWindow and delivered This means that if we mark a message as OOB, that message may be delivered out-of-order, e.g. in the above example, the application will get 1, 2, 4, 3, 5 ! Therefore, an application has to think twice before marking a unicast or multicast message as OOB ! was: - How are OOB messages handled by UNICAST and NAKACK ? Are these 2 effectively ignoring OOB flags ? Does it make sense to use OOB messages in protocols *above* UNICAST or NAKACK ? Exampe: GMS sending VIEW_ACK messages. Logic in UNICAST: - Receive OOB message, place in receiver table - Pass up the OOB message *immediately*, regardless of whether it is in sequence ! - When message is finally removed, do *NOT* pass it up when marked as OOB ! Example (for UNICAST): - We receive 1, 2, 4(OOB) , 5 - Messages 1 and 2 are delivered and removed from the table (AckReceiverTable) - Message 4 is added to AckReceiverWindow and *delivered* (passed up) - Message 3 is received, added to AckReceiverWindow and delivered - Message 4 is removed, but *not* delivered because it has already been delivered - Message 5 is removed from AckreceiverWindow and delivered This means that if we mark a message as OOB, that message may be delivered out-of-order, e.g. in the above example, the application will get 1, 2, 4, 3, 5 ! Therefore, an application has to think twice before marking a unicast or multicast message as OOB ! A similar scheme will be applied for NAKACK messages -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira