scottp at myinternet.com.au
Thu Oct 9 20:18:46 CDT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Friday, Oct 10, 2003, at 10:52 Australia/Melbourne, Joshua Goodall
> Three alternatives spring to mind
> i) Spread (http://www.spread.org/)
> (for which I have FreeBSD and Debian packages:
I had forgotten spread - thanks. This is particular good for high speed
and very remote apps. Unfortunately it is not really good on the
automatic discovery. Like many other alternatives (even Jabber) - it is
only the transport layer and has not defined the way of detecting
One of the key features of JINI is the detection of a devices purpose,
features, methods and events.
> ii) Tib/Rendezvous ($$$ !)
Rendezvous is zeroconfig (or an implementation of it). Howl is one of
the open source alternatives to Rendezvous - 100% compatible.
So good news for me who doesn't want to spend $$$ ! :-)
> iii) PerlDSM (distributed shared memory), if you can find it.
Again, interesting but not solving any of the actual requirements,
which I probably have not made very clear. Remote procedure calls or
sharing memory is not really a viable way of adding an adhoc network of
Unfortunately the main reason to rule out spread and PerlDSM is
performance and functionality. They are too large and power / processor
/ memory hungry for small embedded devices. I don't want anything more
complicated than an HTTP 1.0 protocol.
There are literally 100s of applications and protocols in the space of
communicating across a network. None of them unfortunately actually
solve any of the problems that JINI is solving. The standard
advertising and interaction of services in an adhoc network without
single points of dependence or failure (some of the failure parts have
to be handled by other things, such as networking gear etc).
Like HTML where you can invent a new tag - JINI allows you to invent a
new device and stick it into the mix. Like SNMP which provides a
standard set of functions you don't need to define (hello are you
there, who are you) - JINI has standard ways of knowing the type of
device and its methods / capabilities.
So what I am not trying to solve:
* Remote procedure calls
* Shared memory
* Inter Process Communications
What I am trying to solve:
* Automatic detection of devices
- seems zeroconf is the go here
- This is only the network layer though, no application
- Effectively you now have an IP number and named
devices from which to communicate.
- zeroconf then tends to use standard ports (80 for web) to
find the device services, - eg: Print Daemon, Chat client, Web
* Automatic detection of capabilities or services
- This is hard to define. In JINI it is simply a Class and Methods
- The class of type X is a Light and you just use the on method
- This is sort of like solving the RPC Portmap problem
- The only real solution is to start up an open registry
of device names and types.
- Automatic registration (like CORBA) of Class and Methods is
cool, but your application still has to support it.
* Very small
- I want to be able to write (like you can with HTTP), 50 lines
of code and get a basic working version.
- This means you can write a tiny tiny device on a PIC that
will still work.
- The nice bit of using zeroconf here might be that the
zeroconf part is actually optional.
eg: a little PIC could have a hard coded address
* Totally platform and product independent.
* Implementation independent. (eg: not depending
on perl, or spread, or howl etc)
Open source developer
scottp at dd.com.au
Dismaimer: Open sauce usually ends up never coming out (of the bottle).
Please do not send me Word or PowerPoint attachments.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
More information about the Melbourne-pm