Re: [xmpp] 3921bis: probe + unavailable

[Jonas Lindberg <[e-mail]>]

On Mon, Feb 1, 2010 at 8:56 PM, Ben Schumacher <[e-mail]> wrote:
> On 01/30/2010 03:29 PM, Jonas Lindberg wrote:
>> While I agree this would simplify the protocol a little, I am not
>> convinced it is a change worth making.
>>
>> First of all, not responding to probe when unavailable is a pretty
>> good optimization. A large part of Xmpp traffic is presence. This
>> change would further significantly increase the presence traffic,
>> making scaling more challenging and adding load to c2s and s2s
>> connections. For example, a cell phone xmpp client may be better off
>> not getting potentially thousands of presence unavailable stanzas for
>> offline friends when connecting over gprs.
>>
>> I'm also not convinced this change make it significantly easier to
>> implement xmpp clients/servers. Especially if we are going to
>> recommend that clients and servers SHOULD cope with no response for
>> legacy reasons.
>>
>
> Jonas-
>
> I agree with your points -- it would likely result in extra traffic.
> That being said, I much prefer this to the ambiguity (and potential
> presence leak) of the prior language. As it happens, servers and clients
> will *always* have to cope with no response as this is a network'd
> service and packets can get lost, etc, so I'm not sure the language
> should be "SHOULD" re: legacy services, but rather maybe a note that
> indicates that you may not get a response.
>
> Ben
>

While one can argue it's a little prettier, I don't think it's very practical.

Making this change at scale requires very significant work and comes
at a significant cost in traffic increase (consider user with >1000
mostly offline friends). It will also result in worse user experience
for users with large rosters on low bandwidth connections, like the
common scenario of a cell phone.

Clients will need to deal with presence leaks as long as delivery
isn't guaranteed.. How about just adding an probe answer-required
extension?