2010/3/3 Ted Zlatanov <tzz@lifelogs.com>:
>
> I don't think routing multicasts across subnets is a burden.

Try telling that to a network administrator who is concerned about
flooding his routers with multicast chatter.  First, you'll have to
find a network administrator who is willing to even have that
conversation.  That setting defaults to 'off' for very good reasons.

>
> GD> RRDNS would work, but something would need to keep that updated when
> GD> servers go away (it wouldn't be automatic).
>
> GD> If you can count on one of your (seed nodes) to be up, RRDNS could be
> GD> used to connect to one of them and fetch the token range list.  To do
> GD> this, create a thrift client and call describe_ring.  In older
> GD> versions you can get a jsonified endpoint map by calling
> GD> get_string_property('token map').
>
> It would really be much more efficient if I didn't have to maintain
> RRDNS, but could instead look at the mDNS broadcasts for the Cassandra
> service.  What you describe is a centralized model, no?
>
> With mDNS I wouldn't have to know which nodes are up or down, and I
> wouldn't have to do extra queries, it would just work.  I don't see why
> Cassandra doesn't need that functionality.  How else could you be
> guaranteed to find a live node if there is one on your subnet?
>

It wouldn't be a lot work for you to write a mdns service that would
query the seeds for endpoints and publish it to interested clients.
It could go in contrib.

Gary.