[Standards-JIG] Re: component protocol
Robert B Quattlebaum, Jr.
darco at deepdarc.com
Fri Nov 17 23:45:54 UTC 2006
This reminded me of something I was thinking about earlier. Features
like PEP, vcard-temp, etc, require that the server support those
protocols directly. What I was thinking about was a mechanism to move
the functionality of these services outside of the server. That way
they could be maintained and administered separate from the server
Conceptually, what is required is a way for a component to insert
itself right before the packets get to the session manager. This
component would then be able to take PEP stanzas and handle them
itself, and let any other stanzas pass thru transparently. This
should make it much easier to quickly deploy new technologies like
PEP, because one PEP implementation would work on many different
kinds of servers.
This is what I was thinking:
1) Interception can be both inbound or outbound. An example of
inbound interception would be for all of the IQ's in the PEP
namespace. An example of outbound interception would be for a disco
features reply, where the component would insert the namespace into
the list of features.
2) Intercepted packets can be directly responded to, dropped, or
modified and passed along.
3) The component must register the namespaces that it wants to
Imagine what we could do if we had a standards-track protocol for
this that would be widely implemented in servers. Server implementors
would no longer have to worry about implementing all of these fancy
features directly. New server-level features could be added (or
removed) with ease. Experimental server features would be much easier
to test and deploy.
On Nov 17, 2006, at 12:51 AM, Ralph Meijer wrote:
> On Fri, 2006-11-17 at 09:03 +0100, Jean-Louis Seguineau wrote:
>> I support Matthias approach here. If we make components able to
>> directly, they become de-facto similar to IM servers, with the
>> advantages and drawbacks. In particular, it could impose a
>> dependence on DNS
>> which components do not need.
>> IMO components are meant to extend the functionality of an associated
>> server, and sometimes do not provide services which are visible to
>> an end
>> users. They may need to receive stanzas independently from any DNS
>> resolution. In many cases, they will be part of a greater whole
>> comprising a
>> home server.
>> Rationalizing the namespace is probably the way to go. But as many
>> use the "jabber:component:accept" to differentiate from an S2S
>> connection we
>> need to come up with a better alternative than just connecting on a
>> different port. Maybe adding a new optional feature on the stream...
> If your server has an s2s implementation you have to configure it to
> listen to port 5269. Or, i you choose another port, you can setup DNS
> SRV records to point to the actual port.
> If your server has an c2s implementation [..] 5222. Or, [..]
> So, why is it a problem to configure a server to use a particular port
> for component connections. E.g. jabberd2 accepts all components on the
> same port 5347.
> About the namespace, why is that a problem exactly? I suppose that if
> your development platform is able to switch between 'jabber:client'
> 'jabber:server', a third namespace wouldn't be an issue. I haven't had
> any difficulty with it in my code.
> The advantage of a separate namespace is that it clearly marks that
> stanzas are treated differently.
> As for the actual component protocol, I do agree that it can use a
> look. SASL and TLS are one thing. But I am also interested in giving
> components more access to server internals to implement something like
> PEP as a component.
> A while back this page was created to try and list some requirements:
> Making 'components' do s2s is not a protocol issue, but an
> implementation issue. You can do this today, and I am actually looking
> into implementing this in Twisted. The reason the component protocol
> exists is that it makes it easier to 'offshore' the s2s handling.
> External entities need to set up separate s2s connections for every
> component that you host in this way, too.
> I also want to investigate the possibility to create a server of which
> the node part of its JIDs is in a shared namespace. For example, you
> could have ralphm at ik.nu being a user account and hallway at ik.nu being a
> MUC room. This deviates a bit from the traditional view on how to
> implement servers, but I think it simplifies deployment. You only need
> one s2s connection for exposing all your services to external
> and only one SRV record.
Jabber: darco at deepdarc.com
eMail: darco at deepdarc.com
More information about the Standards