Jamie's Blog

Ruby developer. CTO. Swimmer. Always trying to write more


Diego picked up on my piece re. JXTA and Jabber. He makes a distinction between discovering something and locating it. Fair enough although I’d never actually looked at it this way. To be honest I had always thought of discovering an entity as discovering something about that entity. Knowing that something is there isn’t really discovering anything all (but it can be useful, I’ll show you later), but knowing that the printer “1st Floor Colour” is within range of my wireless device is something different. I have discovered the name, type and location of the printer so in that sense location is just another attribute. And all attributes may require additional steps to resolve. For example, I may have deduced that there is an agent platform running on but it will take additional steps to discover the name of that machine (i.e. DNS), the name of the agent platform, the agents on that platform etc.

But Diego is right that I’m talking about wireless ad-hoc networks rather than Internet-based systems when I talk about discovery. It’s just a viewpoint/terminology thing.

I’ve wanted to write these thoughts down for a long time and Diego has given me the proper incentive:
Discovery is all about bootstrapping. Discovery (in my view) is all about leveraging the knowledge you have to discover something new. If we know an ip address we can use that to discover the host name. If we detect a serial port line being pulled high we know that a device has been connected to the other end of the cable and we can make attempts to discover more about it. If we receive a specific radio signal we might think that some other device is nearby and we can begin trying to find out more about it.

Bootstrapping the discovery process has three interesting properties described using three triangles.

First you start off with a “ping”. In an IP world this maybe a udp packet broadcast around the local subnet. On a low-power radio it might be a brief but recognisable pattern. On a serial port it could be the Ring Indicator (?) pin being pulled high. The key attributes of this “ping” stage are that it can happen frequently, it contains very little information and it’s small (hence efficient).

Now gradually as we move up the discovery stack we can use the previous step to build up our knowledge about the device. When we notice the pin being pulled high on the serial port we can proactively attempt to open a connection and send a query to the device (in whatever form it might take). If we receive a properly formatted udp packet on a particular port or multicast group we can respond to the sender. In each case, if the device understands what we’re asking it will respond with some initial information. At this point if the ping event was spurious or erroneous there is no harm done. We haven’t expended a great deal of effort or consumed many resources.

The initial information we receive might be a transport address, a name, a device type, … whatever it is it will give us a clue about how to proceed. With a name we can perform lookups in directories. With a transport address we can communicate outside of the protocol used for discovery. With information about the capabilities of the device we can understand how to communicate with it. If we know there’s a FIPA agent platform on the device, we can try to search the DF (a yellow-pages directory). And so on… right up until we hit semantic web style information upon which we might perform some reasoning.

The point is that although using semantic web data and ontologies is very expressive (it has a lot of information) it is also incredibly large (i.e. inefficient) and hence we can only afford to do this infrequently when we’re reasonably sure that the software at the other will understand it.

This is just a quick description but I hope it make some sense.

Another thing I’d like to point out is that Jabber servers are not centralised in the way a web server is centralised. Each Jabber server can communicate with another to forward on messages using a server-to-server protocol which is not dissimilar to the way a JXTA rendevous work. The difference is that the peers connected to a rendevous in JXTA can also talk directly to each other (i.e., peer-to-peer) whereas peers connected to a Jabber server must use that server for all communication.