I’m developing a system for embedded devices, and I plan on using XMPP for communication. I was planning on writing a server side application that translated between XMPP and a simpler protocol of my own devising. Recently though, I’ve been wondering if it would be possible for my server side application to act in a similar way as the Openfire Connection Manager, to save on the number of connections / file descriptors that the server process would use. Is this possible? And if so, is there anywhere other than the Connection Manager source that I can refer to about the protocol between the connection manager and openfire server?
However, I’m wondering if you would consider another approach altogether. If I were given the project I’d proceed as follows:
The processing module can run in an Openfire plugin. I would use Botz: Internal Bot Library for Openfire and create an internal bot to emulate an XMPP connection for each of my devices. I’d extend the BotzConnection class to support bots multiplexing, and let all bots use a single BotzPacketReceiver object for central processing job. The packet handling and processing job is all done in a single plugin. So what kind of interface will there be between the devices and the plugin? I have a myriad of selections because I’m not limited by any protocol. It could be a database transaction table, a web service, or whatever I think possible.
An advantage of doing this way is that you have full access to Openfire API. Whereas, a CM restrict your capabilities only to those features available between a normal client and a server, and dictates your clients to follow the protocol in xmlns=‘jabber:client’ namespace.
The disadvantage of doing this way is that you add up a processing load to Openfire and limit your ability to scale the system. However, a good system design would anticipate the future expansion and support for clustering; thus, overcome the limitations. The clustering support is available in Openfire Enterprise.