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

Vinod Panicker vinod.p at gmail.com
Tue May 9 04:55:46 UTC 2006

On 4/30/06, Ian Paterson <ian.paterson at clientside.co.uk> wrote:
> Hi Vinod,
> > The reason I think it should be in a separate JEP is because some
> > entities would want to just use the multi-stream feature - an xmpp
> > proxy, for instance.
> [snip]
> > Makes perfect sense when deploying servers to cater to huge loads.  A
> > proxy would handle incoming connections (Connection Manager, if you
> > wish) and will route them to back end xmpp servers, optimising usage
> > of a few tcp connections, sending multiple streams over each of them.
> I expect that proxies will in almost all cases employ standard 5222 TCP
> connections with the servers. But perhaps I'm missing something? IMO
> JEP-0124 will probably never be used for server-to-server communications.
> However, I certainly don't want to close down unnecessarily that (or any
> other) possibility.

Yea, they would employ standard 5222 TCP connections, or may use a
different port.  I'm not looking at using JEP-0124 for s2s connects. 
The only point I was trying to make is that there are other scenarios
where a multi-stream use case comes into the picture.  In that
interest, it would be better if the multi-stream text is moved into a
separate JEP, and JEP-0124 could depend on that.

> The primary motivation for adding optional multi-streams was to allow a
> single constrained (Web) client to open several streams with a proxy
> (something that v1.4 of the JEP made impossible). For example, on weekdays a
> user might want their client to be logged in simultaneously via a proxy with
> these bare JIDs:
> vinod at work.com
> vinod at personal.com
> At least one implementation of client/proxy multi-streams is already in
> development.

Yes, but it 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

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.



More information about the Standards mailing list