Slashdot Mirror

Anyway, this is an interesting question and problem, and I had to research this topic a few months ago myself, and came up with the Secure Multicast IETF that is dealing with reserach and secure multicast standards. One of the bigger research platform seems to be Secure Spread, a framework derived from the Spread Toolkit for reliable muticast. These are good places to start with the problem of secure multicast I think, although Secure Spread seems not to be under heavy development since 2002.

Since the original poster mostly talked about means to provide secure authentication and/or key distribution (dongle and smart-cards), I would like to point out that the main problem of secure multicast is rather providing

• a secure way of authentication and authorization of clients trying to join a multicast group
• a secure way to distribute shared keys for members of the same multicast group
• a secure way to re-key shared keys for all members of a multicast group
• a way of stopping access to the multicast data for specific members of a multicast group that should be rejected further data access (due to administrative decision) while maintaining the rest of the multicast group members and functionality

Neither IPSec, the number one secure IP protocol, provides for that, nor do IGMP or multicast routing protocols which are used for multicast group management. If you manage to solve this, the actual problem of distributing and managing account data to customers will be a bliss. (Oh, and since you involved the /. community in this problem, I expect you to provide your solution as free software, or at least open source, to the public... .)

I would add Ensemble and Spread to the list.

I think that messaging is nearly always a better solution than RPC, especially for wireless where the network might not be very reliable. I've been playing with Spread recently. It looks pretty good.

Errr... I paid AUD$2000 for MS Visual Studio.Net 2003.

And any remotely useful component for Windows programming (which is painful by itself) costs money, and it all adds up pretty damn quick.

What you get with Qt rocks. It makes programming fun, and provides many needed components anyway, that you'd be paying for individually, but at least they were designed to work together in Qt.

Oh, that, and Qt's documentation is UNMATCHED. GNOME/GTK/glib documentation is mediocre. So is KDEs for that matter. MSDN has them beat in that regard. But Qt's docs are second to none.

I could go on... but I'd get bored.

MS have C# and the .NET Framework now, which IMHO has saved them in the developers eyes.

MFC and Win32API suck so much. I don't know a single person who enjoys using that crap.

But anyway... GTK+ vs Qt (or GNOME APIs vs KDE APIs) is another long story. I'll sum it up:

GTK+ is a hodge podge of a bunch of libs that may or may not work together easily... it all depends on how the developer was feeling. Want to get that libart buffer onto a GTK Widget? Seems like a common thing to do right? Yeah... code it yourself. Want a toolbar that works? Use libegg... but libegg doesn't actually exist, so copy and paste the code from libegg into your application. And change it as required... hmmm... now every application maintains its own toolbar code.

What about components and communication under GNOME? Yuck. Bonobo/ORBit suck. Have you seen the amount of code required to make something a 'component'? Then instantiate it? Argh!!!

Compare this to Qt/KDE, where everything is A) uniform, because the libraries rock. Maybe C++ helps in this regard. B) Everything is a component and can be used: want IMAP or POP or SMTP or HTTP in your application? 3-4 lines of code to get an instance, and use it. HTML renderer? It's there. Try embedding Mozilla, or using gtkhtml3/libgtkhtml in your application. Maybe what, 1000-2000 LOC in C? C) DCOP rocks. You can make your application totally scriptable with DCOP very very easily (some actions even come for free! Just by having a KApplication instance.)

I don't know... the funny thing is, I still use GNOME... but I wish it was KDE. I like the look and feel of GNOME... but I wish it was as easy to develop for as KDE is. PyGTK helps a bit, but it's slow. Maybe Mono + Gtk# will help? Seems to be the way it'll go. I'm willing to bet GNOME 3.0 or 4.0 will be mostly C# based.

Meh... I wish for a lot of things.

I might as well lay down the prediction here.

GNOME will win (and not because it's better. But because there's more attention focused on it. And GNOME lays claim to stuff that isn't even GNOME based, like Mozilla or OOo. But anyway. Evolution beats out Kmail, Mozilla beats out Konqi, OOo beats out KOffice. The GIMP is unmatched. Too bad all that stuff doesn't work properly together. Sigh)

It'll mostly be coded for using C# (Miguel is a freaking genius. I'll go so far as to call him a visionary.)

D-BUS will rock (but not until version 2.0 -- the current spec is very immature. It needs way better security and the protocol has clearly not been thought out well. These guys should look at Spread and maybe use XML-RPC or SOAP or whatever over that. They'll get inter-computer communications as a bonus. D-BUS is such an obvious idea that I can't believe no one thought of it earlier. I suppose KDE has DCOP but it just isn't the same concept.

D-BUS will be _the_ system wide communication bus under Linux/*NIX.

HAL will also rock, and of course it'll use D-BUS. Plug in that Camera and your camera application will pop up. USB drive? pops up on your desktop like Mac OS X. And so forth.

Xserver will become the defacto standard on Linux. There's no doubt about that.

Everything freedesktop.org does will be the standard. It's a good thing what they're doing rocks. But I wonder about Havoc's capabilities sometimes (OK

Spread is a toolkit that provides a high performance messaging service that is resilient to faults across external or internal networks. Spread functions as a unified message bus for distributed applications, and provides highly tuned application-level multicast and group communication support. Spread services range from reliable message passing to fully ordered messages with delivery guarantees, even in case of computer failures and network partitions.

Spread is designed to encapsulate the challenging aspects of asynchronous networks and enable the construction of scalable distributed applications, allowing application builders to focus on the differentiating components of their application.

This is a solved problem, check out the splash project http://anoncvs.aldigital.co.uk/splash/ for details.

Basically, it is an Apache module which uses the spread http://spread.org secure mesaging server to synchronizes ssl conection information.

I have tried SwiftMQ, in which the main engine is free, but add ons are at a modest cost. What I would like to see are JMS implementations on top of Spread or Elvin. The OpenJMS and JBossMQ are okay, but still lag behind the commercial vendors, but are quickly catching up.

If you really wanna have some fun, write your own applications using multicasting, on your own protocols. See what you can do with mpeg streaming to the machines on your cluster. If thats too much work, which it probably is, play with Spread. It will do the low-level networking and reliability for you, and let you concentrate on what you want it to do.