[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  
implementation.

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  
intercept.

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  
>> connect
>> directly, they become de-facto similar to IM servers, with the  
>> associated
>> 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  
>> servers
>> 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'  
> and
> '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  
> fresh
> 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:
> http://wiki.jabber.org/index.php/XMPPComponentProtocol.
>
> 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  
> entities,
> and only one SRV record.
>
> -- 
> Groetjes,
>
> ralphm
>

__________________
Robert Quattlebaum
Jabber: darco at deepdarc.com
eMail:  darco at deepdarc.com
www:    http://www.deepdarc.com/





More information about the Standards mailing list