[Summit] interop testing prep
romeda at gmail.com
Thu Jul 3 11:57:21 CDT 2008
One test I'm really interested in seeing is "what happens when an s2s link
when it's saturated?" It's the one question that I don't have really good
answers for in terms of the scalability of Jabber servers, and it's a fairly
real concern for some of the people I've spoken to.
If you've saturated one s2s link (e.g., 100 Mbit), it should be possible to
"spill over" into a second s2s link between two servers on a separate
connection, giving you horizontal scalability with respect to bandwidth.
Whether that actually happens is a big unknown for me.
On Thu, Jul 3, 2008 at 8:12 AM, Peter Saint-Andre <stpeter at stpeter.im>
> As mentioned, I think it would be productive to perform some server interop
> testing at the XMPP Summit in a few weeks (I'm also working to get at least
> a few client developers there, but so far we seem to have mostly server
> developers -- from ejabberd, Isode, Jabber Inc., Openfire, and Tigase). If
> we're going to do it right, we need to prepare a bit. In particular I think
> we need:
> 1. Server certificates. I can issue these through the XMPP ICA. Each server
> will have its own certificate in the interop.xmpp.org tree, such as
> openfire.interop.xmpp.org. Do you want to test the certificate generation
> rules in rfc3920bis? That means each cert would contain fields for
> id-on-dnsSRV (see RFC4985), dNSName, and id-on-xmppAddr. Given that I'm
> pushing to get rfc3920bis done and that the bis format is
> backward-compatible with the RFC3920 format,
> 2. Local or global DNS settings for these domains. I can do this for global
> settings. If we set up a local network, we can simply hardcode the IP
> addresses in /etc/hosts or whatever.
> 3. Some test plans or scenarios. At the 2006 summit we tested basic use
> cases like rosters and dialback. There was inconsistency regarding use cases
> like TLS+SASL (especially for server-to-server). I think it would be good to
> test those. Perhaps also TLS+dialback? I'd be happy to update
> draft-saintandre-xmpp-feature-set to reflect use cases of interest:
> 4. A process for creating user accounts on each server. Alexander Gnauck
> has been working on this -- basically we'd whitelist the IP address for
> interop.xmpp.org (yet to be set up on the Web) for in-band registration.
> We're not sure if all servers support that approach.
> 5. A schedule. I don't think we want to be testing the whole time, but we
> can set aside some time for this on Monday morning and then continue to do
> testing and debugging throughout the conference.
> Anything else?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Summit