Re: [Linux-cluster] Multicast ccsd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



However, it seems that you have forgoten to set mcast_ttl for a socket,
so mcast wouldn't have any sence, since mcast with ttl == 1 is same as
broadcast for many networks.

All you have to do is just add something like:
---8<---
char ttl = 10;

if (setsockopt(sfd, IPPROTO_IP, IP_MULTICAST_TTL,
    &ttl, sizeof (ttl) < 0 )) {
    log_err("Unable to set mcast ttl.\n");
    error = -errno;
    goto fail;
}
--->8---

Why did you choose 10? I know that ttl == 1 is subnet... but 3-31 is site local. Is 10 a better choice than 3? If so, why? I can certainly make something higher the default.


Sorry about the ttl not being an option, I must have forgotten about it when doing the IPv6 stuff. There (looking for confirmation), the ttl is part of the address.

ttl could be a new option to ccsd - '-t <ttl>' for threshold or ttl. Or, it could be part of the '-m' option, where the address and the ttl would be separated by a ','.


ttl could be defined somewhere outside join_group(), or ever fetched
from argv, which also goes for cman_tool.

Also, try not to use 224.0.0.0/23, as it is reserved, so we might get
into trouble with default values. 224.0.0.1 is reserved for all mcast
capable hosts, so even non-cluster members (potential or not) would get
ccsd announcements.

How does 224.3.0.65 sound for a default? This begs the question, should I be using ff02::3:1 rather than ff02::1 for IPv6?


btw, to all developers: it was so uncool to remove 2.6.7 kernel patch :(
2.6.8.1 has a problem with tg3 driver (some autonegotiation issues), so
it's completly unusable.

I doubt that those developers in charge of *-kernel subdirectories will want to maintain separate patches for various kernel other than where the head is at. So, current code will likely follow the head. The old kernel patches are removed because they become out of sync (no longer worked on). The only way to get them is to cvs co -D, which automatically lets the user know that they are not acquiring current code.


On the other hand, have you tried compiling the modules outside the kernel? I'd be surprised if that didn't work yet...

 brassow


[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux