[Standards-JIG] Re: JEP-0124: comments on proposed version 1.5

Matt Tucker matt at jivesoftware.com
Tue May 9 15:26:38 UTC 2006


Ian,

We've submitted an initial proposal to PSA for a generic "multi-stream"
or "connection manager" (as we call it) protocol. It's largely similar
to the external component protocol, but with SASL, TLS, and a few extras
thrown in. This is part of our "Pampero" project for greatly increased
scalability in Wildfire.

We definitely agree that a cross-server protocol for connection managers
or multi-stream is the best approach. It will allow proxies to work with
any server as well as give the XMPP protocol fundamentally better
scalability. Our own implementation of the protocol will be in the next
several months and we're attempting to work with some other server
implementers to see it more widely adopted.

Regards,
Matt

> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Ian Paterson
> Sent: Tuesday, May 09, 2006 7:40 AM
> To: 'Jabber protocol discussion list'
> Subject: RE: [Standards-JIG] Re: JEP-0124: comments on 
> proposed version 1.5
> 
> Vinod wrote:
> > Yes, but [multi-streams] could also be used for higher 
> efficiency of 
> > the underlying tcp connection.  A 'separation of concerns', if you 
> > like.  The xmpp server still has a connection acceptor 
> running, but it 
> > is utilized more efficiently since it may receive multiple xmpp 
> > streams over the same tcp connection.
> > Imagine the efficiency increase of an xmpp server if it did 
> not have 
> > to waste cpu cycles in processing tcp connections.
> > 
> > In a real world scenario, the xmpp server would have 
> multiple 'proxy' 
> > front-ends, that would take care of tcp connection 
> management.  These 
> > proxies would have a single connection with the xmpp server over a 
> > gigabit or such connection, aiming to saturate the single 
> connection.
> > 
> > This multi-stream feature IMO has great implications for such proxy 
> > implementations and JEP-0124 server implementations as well.
> > 
> > WDYT?
> 
> This sounds like the way XMPP servers typically separate 
> concerns today.
> (Where each front-end XMPP connection manager merges multiple 
> port-5222 TCP connections into a single TCP connection to the 
> core Jabber server.)
> 
> An increasing number of 'native' JEP-0124 connection managers 
> are dedicated to specific core server implementations. They merge the
> JEP-0124 connections into a single TCP connection in much the 
> same way as the servers' normal TCP front-ends do.
> 
> Unfortunately the protocol over the merged connection has not 
> been standardised (see 
> http://jabberd.jabberstudio.org/dev/docs/session.shtml
> for the protocol used by Jabberd2.0). A standard protocol 
> could be employed by remote proxies too (and not just 
> JEP-0124 proxies).
> [Although proxies could not be responsible for authenticating 
> users in the way that Jabberd2 connection managers must.] 
> Perhaps that could be the 'multi-stream' 
> connection-manager-to-server JEP you are suggesting?
> 
> While JEP-0124 is exceptionally efficient considering it uses 
> HTTP, it can never be as efficient as TCP - even in 
> multi-stream mode. (For examples, it requires two HTTP/TCP 
> connections to emulate a single TCP connection, and the HTTP 
> headers consume extra bandwidth.) IMHO it is not a good 
> solution for a proxy-to-server connection.
> 
> The security constraints of Web applications mean native 
> JEP-0124 connection managers will never make JEP-0124 proxies 
> obsolete. So I would really like to see the new JEP mentioned 
> above. i.e. One that allows any proxy to forward multiple 
> XMPP *client* streams to a server over a single *TCP* 
> connection - bypassing the server's standard TCP client 
> connection managers. (JEP-0114 has already set a precident 
> for that type of 'internal' JEP.) No proxy-authentication 
> would be necessary since the client streams could be 
> authenticated in the standard ways.
> 
> Do the existing protocols used by Jabberd1.4 (pthsock_client 
> component), ejabberd, Wildfire etc all require the connection 
> manager to authenticate users?
> 
> - Ian
> 
> 



More information about the Standards mailing list