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

Ian Paterson ian.paterson at clientside.co.uk
Tue May 9 14:39:47 UTC 2006


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