Hello!
> First try: does my (completely untested) patch at
> ftp://icaftp.epfl.ch/pub/people/almesber/junk/neigh-error-0.patch.gz
> look reasonable ?
It is reasonable in the highest extent.
> It would be good if an application could determine quickly if multicast
> or broadcast may actually work. If it comes back after trying for five
> minutes with a complaint about lack of connectivity or such, this isn't
> very friendly.
Until now it resulted only in more troubles. F.e. multicasts were used
mainly by routing control apps, which were supposed to start in void
state on bare iron and turn on all the lights. Relying on flags
they really went to coma instantly. 8)
The reason is that "multicast"/"broadcast" notions depend on protocol.
F.e. we can configure routing tables, so that IP multicasts will be routed
to a gateway or to a specific exploder using normal unicasts, so that
device never sees multicasts and application send multicatsts transparently.
After this CLIP becomes truly multicasting, despite of it is not multicasting
at MAC level and for protocols different of IP.
Conclusion: IFF_MULTICAST should be used only as advice, when application
has different modes of operation or is able to select from several devices
to make the work. Otherwise, it must assume that multicasts are available
on any kind of media.
Alexey
|