Re: SMACK

Bela Ban wrote:

No. Discovery does not need retransmission, even *with* NAKACK / UNICAST
and GMS (it is below those prots). A request can be sent multiple times,
but in general, discovery is unreliable. If a new joiner doesn't find
anyone else, it'll become the coordinator. If it later detects other
members, it'll merge.

Alright, that makes sense. A later merge would resolve the lost discovery ping.

Bela Ban wrote:

I recall him mentioning that SMACK (with modifications) works fine for
him /? Gray ?

I've been able to look at Gray's version of SMACK. My main issue now is that using either the official SMACK, or Gray's modified one, none of my nodes are able to recover from pulling the network cable of a machine from the switch and plugging it back in.

My test stack contained only:

UDP
FD_ALL
SMACK

Test:
-Start each node.
-Send a test string each way.
-Unplug the cable from one node.
-Wait for FD_ALL to suspect and remove the errant node. At this point each node's view contains only itself. (singletons)
-Plug the cable back in.
-Send a test string each way.

Expected:
-SMACK would add the addresses back its membership and generate new views and receive the message.

Actually:
One of the nodes (generally the one which had the cable unplugged) no longer receive any messages at all. All messages received go through "up" and stop at SMACK and are not passed higher. Some debugging indicates problems with the AckMCastSenderWindow class, and message seqno problems when it comes to adding the new messages to the tables.

As well, frequently concurrent modification exceptions occur on the AckMCastSenderWindow instance in SMACK when a node tries to leave the group. One or more of the nodes receive this, fail to remove the address from their window, and then proceed to retransmit messages to them forever.

Any suggestions? As I said, both issues occur with either version of SMACK.