[Standards] s2s and gracelessly broken streams

[JD Conley]

Before I get into the TCP madness, I'd like to talk to probes here as
well. I was chatting with Justin the other day and we were scheming...
Probe after you have lost all incoming connections from a remote domain
and the presence status of your local JID changes from a less available
state (unavailable, dnd, xa, away) to a more available state (normal,
chat). This would eliminate the need for periodic probing on Bare JID's
and limit the probe storm quite a bit.

> On Tue, 2007-04-03 at 10:41 -0700, JD Conley wrote:
> > S2S connections should be able to be closed, like they are today.
> IMHO
> > C2S connections should as well. It's a good conservation of
> resources.
> 
> Disagree with the second part.
> 
> First, as has been pointed out elsewhere in this thread, closing a c2s
> connection is less transparent.  Without deep and failure-prone
network
> magic, the server won't be able to connect back to the client when
> there
> is a new message to send, so the TCP association is necessary in order
> to ensure bidirectional communication.

Yeah. I pointed that out. :) However, there are many cases where
bi-directional communication is not necessary. Let's say I walk away
from my desktop computer and lock it, or my screensaver goes on. There's
a very high probability I'm not going to care about incoming data. The
server could just queue that up for me until I come back and my client
(now a tad bit smarter) reconnect and re-establishes my session. There
are certainly some edges that would need to be worked out (disco, etc).

> 
> By contrast, the number of foreign servers your users exchange
messages
> with is much harder to predict and scale with.  If some gonzo user
> decides to send a message to 10,000 different sites one day and your
> server isn't cleaning up the resulting resource allocation, that's
> going
> to be displeasing to most admins.  The fan-out of s2s connections may
> be
> low on most servers today, but it's unlikely to remain low on all
> servers in the future.
> 

Yes, I completely agree with this. Also, the timeouts don't have to be
restrictive. We only timeout connections after 5 minutes of no
application data by default.

-JD