[Standards-JIG] Re: JEP-0124: comments on proposed version 1.5
vinod.p at gmail.com
Sat Apr 29 05:49:44 UTC 2006
On 4/28/06, Ian Paterson <ian.paterson at clientside.co.uk> wrote:
> > Peter wrote:
> >> *Some runtime environments constrain the number of simultaneous HTTP
> >> requests a client may make to each connection manager; if such clients
> >> need to connect using more than one account at the same time, then
> >> support for multi-stream sessions is essential.
> >> * While XMPP does not allow two sessions with the same full JID to
> >> be open at the same time, it does use one stream in each direction for
> >> client-to-server connections; support for multiple streams enables
> >> clients that connect via the HTTP Binding to emulate that behavior and
> >> thereby reduce network traffic.
> I don't understand this second point (even if I assume that
> 'server-to-server' was meant instead of 'client-to-server').
> The intention of the original text was simply to say that restricted clients
> *need* multi-streams if they want to open more than one XMPP stream (with
> different JIDs). Other entities might not need to support multi-stream
> sessions in these cases (they could open multiple sessions instead), but it
> would be much more efficient for them to employ multi-stream sessions.
> (Since with multi-stream sessions only one HTTP request to the server is
> necessary to service all the streams in the session.)
> I agree with the rest of Peter's clarifications.
> Vinod wrote:
> > Shouldn't multi-stream support go into a separate JEP? This could be
> > used on both ends of a JEP-0124 implementation. Eg. an HTTP client
> > using multiple streams to a JEP-0124 server, and the JEP-0124 server
> > using a single tcp connection with multiple streams to an xmpp server.
> IMO multi-stream sessions fitted very neatly into JEP-0124.
> Broadening the explicit target of JEP-0124 to include server-to-server
> connections would seem to be a good idea - especially if people do start
> running their own servers (something Peter often advocates). The existing
> JEP would probably only need an extra sentence in the introduction and a few
> minor language changes (e.g. 'client' -> 'entity'). I think any security
> review should take those changes into account.
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. Rather than defining it in a scope that talks
about HTTP binding, it would be much more accessible and clear if it
were to be put in a separate JEP.
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.
More information about the Standards