Hi,
Just some comments ...
Dirk Meyer said the following on 11/04/2004 06:49 PM:
1. Configuration file[...]
All applications on the same bus must share most of the values in the config file. If ADDRESS or PORT don't match, the applications simply won't find each other, if HASHKEY is different, pymbus won't deliver the messages. Do not activate ENCRYPTIONKEY, pyMbus doesn't support encryption yet.
Encryption is definitely one of the most important thing to implement next.
2. Multicast setup[...]
To set the default route for mbus for 224.255.222.240 (default) type 'route add 224.255.222.240 <interface>' is root. For host local usage use 'lo' as <interface>.
As you said that would just allow multicast traffic for this single IP multicast address. To accept all multicast traffic something like the following would be the right thing:
route add -net 224.0.0.0 netmask 240.0.0.0 <interface>
Another thing I want to mention is related to the Mbus features we[1] are using for the freevo Mbus interface. The RFC 3259 defines a transport layer using Mbus. But the Mbus communication interface is also based an very old draft that expired a few years ago (included in the ppMbus package). This draft defines the RPC mechanism used for the freevo Mbus.
Why do we base a communciation interface on a mechanism that will probably never become a RFC/standard?
This is quite simple as we know why this draft will (probably) never become an RFC. The IETF consists of a very high number of working groups, each discusses topics of a specfic area. This draft (originally discussed in the MMusic working group) seems to belong to an area of topics that is not covered by any group of the IETF. And exactly at this point is the problem. As no one, involved in the devolopment of Mbus, has the time to create a new working group for just _one_ draft, it will be as it is. And we are happy with it.
Almost all "fathers of the Mbus" are colleagues to Dischi and myself and we are working with the Mbus and the draft features for about 5 years now. In this time we've learned to appreciate Mbus and the modular application design which is directly connected to it.
So we do not just base the communication on an RFC and a Draft, but on an RFC, a Draft and a lot of experience ;-)
JFYI
crunchy
Footnote: [1] Dischi, S�nke (Juergen) and myself
-- If windows is the answer, it must have been a stupid question.
signature.asc
Description: OpenPGP digital signature
