Re: [javagroups-users] SMACK

[Bela B. <be...@ya...>]

gray wrote:
>
> Bela Ban wrote:
>> Wait, SMACK does not use GMS, so how can you use GMS ?
>>
>
> SMACK is really 2 things (and maybe should be just 1). It has a simple
> group membership protocol
> which (as far as we could tell) is full of holes and we are not using. We
> have: manage_channel_view=false

I assume you added manage_channel_view (because I don't see this prop in 
my code) ? That's why I was confused; I knew my impl didn't use GMS, but 
you must have added code which disable this and allows someone to use GMS.

> What SMACK gives us is multicast retransmits -- i.e. UNICAST for 
> multicast packets.

I still don't understand - what is this ? If you mean that in NAKACK all 
retransmitted messages are sent to the requester via unicasts, then 
that's right, by default. However, you can use multicasts for 
retransmissions, by setting use_mcast_xmit=true.


> It keeps track of who is talking SMACK to it (we had a lot of fun with 
> the name) and then if
> it doesn't get an ACK from someone, it will retransmit a multicast 
> packet to the missing remote(s) using unicast.

So you're interested in *not* using multicasting for retransmissions ? 
Well, if you configure use_mcast_xmit=false, NAKACK does *not* 
retransmit via multicasts. Instead, it wraps an xmitted msg into a 
unicast to the requester.


>> Interesting, in my perf experiments I've not seen high drop rates.
>>
>
> I suspect that when you have all machines plugged into one switch

Yes. That's not uncommon though; most customers have all cluster nodes 
plugged into the same switch. For larger clusters, this would not be the 
case though, correct.

> they are
> very rare. But we have a reasonably complicated network topology with 
> a lot
> of inner firewalls that have fragmentation and other transit tables which
> seem to cut the tops off of bursts dramatically.

I see. Yes, I agree, JGroups was not designed with these kinds of 
environments in mind, but we should nevertheless support them. This is 
similar to WAN environments, which we want to support better. Although 
folks are already using JGroups in WAN environments, but then again it 
will be always used in unanticipated ways... :-) I'm not syaing this 
won't work, but just that we are slowly moving to support it...



-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat