[jboss-jira] [JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1875:
---------------------------
    Description: 
If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
* B needs to get the lowest and highest seqno sent from A
* B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
* B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
* B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
* B creates an entry for A with the lowest and highest seqnos
* B sends a {{SYNC-ACK}} to A
* A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
* A and B now use the usual protocols to retransmit missing messages



  was:
If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
* B needs to get the lowest and highest seqno sent from A
* B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
* B sets a flag that discards all {{STABLE}} messages on reception of {{SYNC}}
* B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
* B creates an entry for A with the lowest and highest seqnos
* B sends a {{SYNC-DONE}} to A
* A resets the flag and starts accepting {{STABLE}} messages from B again
* A and B now use the usual protocols to retransmit missing messages





> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
>                 Key: JGRP-1875
>                 URL: https://issues.jboss.org/browse/JGRP-1875
>             Project: JGroups
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)