Just to note, after having no replies to my question, I looked into various alternatives in some depth.

The question; how to host large numbers of JIDs on a single client machine without one socket per JID to the XMPP server.

I learned that Whack conforms to the XMPP Component protocol, and can therefore make a single TCP/IP connection to an Openfire Hub and route all inbound and outbound packets across it, but has no XMPP-specific functions defined, and is incompatible with Smack (i.e. Smack can't use Whack as a transport).

I also learned that other XMPP domains can be federated into an Openfire Hub, so our own implementation of an XMPP server on diet-agents.cefn.org can then connect to cefn.org across just two sockets - one outbound and one inbound. Our server can then be responsible for its internal account creation, login and event management without any extra sockets [thanks to Sean Meiners for this suggestion].

The options seem to be...

1. Use unmodified Openfire and Smack with a modified server which has its own internal subnet and loopback network drivers and hence no socket limitations (a torture)
2. Use Whack and patch the Smack API to remove the (unnecessary) architectural limitation of one Socket per JID as built into the implementation of XMPPConnection (a fork)
3. Use Whack and reimplement the subset of Smack XMPP capabilities we need from the ground up (a pain)
   
4. Use a different XMPP server (possibly our own implementation) which doesn't enforce the 'one Socket per JID'  limitation, and set it up as a peer to Openfire on a separate domain with separate user records (a shame)

My preferred option currently is either 2 or 3, and probably 2 is what we'll try first in order to try and benefit from the packet unmarshalling and Java API already defined in Smack. In other words we would use Whack to provide an alternate implementation of XMPPConnection, and have to modify the Smack API to support this.

It does make me wonder why this limitation exists, though. A few specific questions...

• Why does Smack currently rely on XMPPConnection as a concrete class rather than an interface?
• [If it was an interface, we could implement our own transport with Whack which shares sockets, and solve the problem with no fork]
• Why does XMPPConnection and Openfire have assumptions built-in that there should be one JID per socket?
• [It seems like every XMPP XML packet contains source or session identifiers anyway, so there's no reason I can see why a single socket shouldn't be authenticated for multiple JIDs at once for scalability.]

I believe that these minor modifications would help these java XMPP libraries to scale in ways more reminiscent of AMQP and be useful for a lot of other applications as a result.

Thanks for the suggestion, Jay.

Given a client library which doesn't initiate one socket per JID then it would definitely be worth examining the Openfire CM to address the complementary issue on the server side.

However, as a client library, Smack is currently busted in this respect in ways deeply embedded in the XMPPConnection and PacketReader/PacketWriter implementations - a thicket of package-protected cross references and indistinct roles and responsibilities. Until this modularity problem is fixed, the server-side behaviour will be continue to be a symptom of the requests forced on it by the client side implementation.

I'll have a go at fixing Smack and separating out some of the classes into more self-contained and modular units, but I'm fearful of modding the low level interactions between client and server sockets. One of the advantages of considering Openfire is to be able to rely on a robust XMPP server implementation - if I go throwing my own code into the server-side socket handling then there's a good chance it'll go phut, even where we're using others' conformant XMPP client libraries to connect to the hub (which wouldn't make me popular, as well as my bespoke code invalidating any premium support contracts we might hope to sign with Jive if our beta is successful).

My current thinking is to rely on the conformance of an unmodified Openfire server to XEP-0114. This should allow us packets into it and out of it via Whack along a single socket. Then we just need to modify Smack to be more modular, supporting the alternative Whack transport instead of the hard-coded one-TCP/IP-per-JID transport built into XMPPConnection.

For now, since I'll have to re-engineer Smack anyway, I guess using Whack for packet transport is probably easier than fixing assumptions and socket protocols on both sides of the client-server interaction. Am I barking up the wrong tree?