[Standards] s2s and gracelessly broken streams

[JD Conley]

> > There is a finite number of connections you can use per IP address.
> In a
> > 32 bit process space sometimes this TCP/IP imposed limit isn't even
> > achievable. In Windows, at least, you have to have kernel reserved
> > memory available for every socket connection (I would guess it's the
> > same in the *nix world). Holding a connection open is resource
> > intensive. Why not have that physical memory available for other,
> more
> > important things, than managing a stale connection. As the
popularity
> of
> > XMPP increases the number of openly federated services will also
> > increase. If we did not tear down stale s2s connections, I could see
> > even small organizations (i.e. low thousands of simultaneous users -
> > like jabber.org) needing more than one IP address and more advanced
> > software configurations for their publicly federated XMPP system.
> 
> OK.
> But following this reasoning you should tear down client connections
> also. There are the order of magnitude more of these than server
> connections. How come you could keep up many more c2s connections up
> and
> be happy with that, and cannot keep less s2s connections up? These are
> the same <stream:stream/>s. Why c2s are OK, and s2s not-OK?

First off, there is only an order of magnitude more c2s connections for
XMPP services that serve C2S. When more shared services come online,
those systems will be offering everything over S2S and probably not even
have c2s components. That's the only way you could make a large service
scale, since c2s connections can't reasonably be torn down today.

However, ideally you could tear down client connections after inactivity
and give them a token they could easily re-connect with and resume their
stream. I think I've even talked on this list about protocol for
resuming client streams in often-disconnected scenarios such as wireless
devices. However, this isn't always plausible and is missing the reverse
connection. The server won't necessarily be able to communicate back to
the client in near-real-time when it receives a message for while the
client isn't connected. There would need to be some sort of two-way
connection handshake in C2S land to make it work. You could probably
pull it off with long lived UPnP and some port forwarding, or some such.
With S2S we assume both servers can get in touch with each other
whenever they need to, so we can easily tear it down.

-JD