Shibboleth Developers

["Scott Cantor" <>]

> It need not be multicast, TCP is supported too. While my experience with 
> this has been that the multicast has been reliable I'd probably 
> recommend TCP for production environments, though, because I believe 
> it's more secure.

I was speaking more abstractly, but I wasn't clear. Either multicast or TCP
clusters are going to be configured with a certain amount of information, so
there's not much you can do about it, short of just putting it in a separate
file, but I don't think that's such a bad thing. Nor is it that complicated,
but I actually tried the Tomcat stuff, so maybe my pain threshold isn't a
good test.

> Yeah, it deals with this just fine.  It picks up nodes that are down and 
> ones that come back up.  The only thing the multicast does is allow for 
> detection of nodes that have never been seen before.  With the TCP stuff 
> you define the IPs of the nodes in the cluster and so if you want to add 
> a new one you have to add the IP to the list, with UDP you just bring it 
> up and put it on the same mulitcast address and it just joins the 
> cluster (which is the exact reason I think it's a minor security risk).

Yes, I could have my multicast port firewalled off, which makes it pointless
since it just moves the list of peers to iptables.

> nodes is thus navigable)  So, this is why I suggest you place each nodes 
> IP address in every node's config.  It's not like the list should change 
> all that often.  (Sorry for the very long winded side track there.)

Right, just wanted to be sure I didn't have to take it out of every peer
list to safely take a box down.

One thing you might note is that there's really no amount of stickiness you
can use to make asynch replication work. It's two different boxes making the
connection for a given session, so I don't see how you'd ever link them. It
works for fail-over mode, but that's about it.

-- Scott