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.
|