Support for XEP-0114: External Components

[Dan Devine]

Interested in using this library on Tomcat instance with XEP-0114 type connection to Openfire / ejabberd server.

See link to XMPP spec here: http://xmpp.org/extensions/xep-0114.html

Is this possible with this library? Are there any technical limitations that would prevent it? May be able to provide solution too, I'm just doing a preliminary investigation at present and looking for quick guidance.

[Christian Schudt]

This is not possible yet. After having a quick glance at the specification, I wonder if this protocol is still useful. It feels more like historical documentation of a protocol used by jabberd server many years ago.

What's the difference between a component which authenticates using the <handshake/> element and a user authenticating using the standard SASL process? Both are clients exchanging stanzas with the server. Or do I miss anything? Maybe you can connect from Tomcat with a normal user and standard connection?

I don't think there's a technical limitation, but I am also not eager to implement such an historical and probably rarely used protocol, which probably requires some major redesign and might have a big impact on the API. I mean, there's probably a good reason, why Whack library (for XEP-0114) has been designed as standalone library and is not included in Smack library.

On the other hand I think it would be better to have them in one library. Let's see, maybe I can get this done at some point.

[Dan Devine]

I just saw the 'historical' under 'track' too, and I'm not sure what that means. It doesn't say deprecated though, it's still in 'active' status.

I've actually been using XEP-0114 actively as a side-channel connection to Openfire for gaming purposes. Component support permits subdomains within the main XMPP server domain, like 'game1.hostingserver.com' and 'game2.hostingserver.com' with each addressable game component supporting it's own pubsub tree, multi-user chat room, etc. The main server only needs to provide proper routing and offloads the upkeep to the components. I built a pretty hackey mashup of Whack along with Openfire's PubSub bits to hold the game data.

https://github.com/AdSpore/Splat

This project is the solution to the really crappy "jaxb + dom4j" problem I've been having with Whack/Openfire.

I'll read up on SASL authentication and also see if there's a replacement for XEP-0114. I can do the coding if it's not technically impossible, I may need some guidance to figure out how to fit it together. I wasn't thinking of putting the extra load on you, just needed the creator's eye to keep me out of the weeds.

Thanks, DD

[Christian Schudt]

So the use case of XEP-0114 is that you can "control" (?) an XMPP component hosted within an XMPP server (e.g. Openfire) from extern via XMPP, e.g. by sending IQ commands to the component?

If I understand that correctly, probably some major refactorings are required:

1) Make the XmppSession class abstract and let it deal with common things like connect listener registration, connect(), send()

1.1) Create a "ClientSession" (extends XmppSession), which deals with normal c2s use cases, like resource binding, SASL authentication...

1.2) Create a "ComponentSession" (extends XmppSession) which does the handshake described in XEP-0114 (instead of the login in ClientSession)

1.3) Preferably have also XEP-174 in mind when doing this.

2) Rewrite TcpConnection/XmppStreamWriter classes so that they use the "jabber:component:accept" namespace. In the best case the existing classes can be used for both C2S connections and XEP-114 connections by somehow passing the namepace. Otherwise some abstraction needs to happen here, too. I also don't know if XEP-114 is supposed to work over BOSH.

3) Implement the XML schema described in XEP-114. I've already done this in an extra branch: 35271eeb7e6409d74ba520ff0daa0c60b1c65d90

I am not familiar with Whack / XEP-0114 at all. Maybe I've understood the component concept wrong and you have some other view on it and other ideas.

[Christian Schudt]

The good news: it works already.

It turned out, that there were indeed some major changes required to the core. I've applied some preliminary work to the master branch and also did some work to xep0114 branch.

https://bitbucket.org/sco0ter/babbler/commits/branch/xep0114

You could check it out or just have a code review. I've basically did what I said above. There's a ComponentSessionSample class, which you could try out. It only connects and logins. I've tested this successfully with my local Openfire.

I still need to do some polishing though. Let me know what you think.

[Dan Devine]

Fantastic, I'll give it a try. I'm a little lost on how to answer some of the questions/comments though... Over BOSH? No, that's definitely not part of the concept of 'component'

From my walking around the internals of Openfire, perhaps the best way to think of 'component' is to imagine a service (i.e. chat, conference, pubsub, presence, etc) that has access to the server's local IQ routing, but which does not exist within the server code itself.

My understanding of the packet routing within an XMPP server is this (really simplified): 1) Check if the destination of the packet exists on this server. Yes ? handle locally : direct packet to the foreign host. 2) Service or JID? Supposedly each JID could support it's own pubsub tree, in practice Openfire doesn't support this. 3) Component is routed as if it were a local service, just passed from Openfire out to the component, which handles the response to the requesting JID

I'll read through XEP-174 today too.

Thanks, Too awesome...

[Christian Schudt]

Better use the master branch for testing/review now. It's already more advanced. I will provide sample and documentation later, too.

[Dan Devine]

Got it working, thanks again. Learning how you've got the rest of the packages setup, so that I can contribute some bits back too. PS: some of the issues you were discussing above are also brought up in XEP-225...not solved or specified, mostly just outlined.

Thanks

[Christian Schudt]

Great! I just pushed a modified version of the ExternalComponentSample.java, which basically is an implementation of a XEP-171 Translation Provider as component.. Well without doing translation actually :-/

I think it's better to make ExternalComponent non-final so that you could write something like LanguageProvider extends ExternalComponent. Let me know, if you have similar thoughts for improvement.

[Christian Schudt]

Resolved with version 0.6.0