[Standards-JIG] Re: JEP-0124: comments on proposed version 1.5
ian.paterson at clientside.co.uk
Tue May 9 14:39:47 UTC 2006
> 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
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
More information about the Standards