[Standards] s2s and gracelessly broken streams

Mridul mridul at sun.com
Fri Mar 30 18:50:02 UTC 2007

Justin Karneges wrote:
> On Friday 30 March 2007 10:04 am, Peter Saint-Andre wrote:
>> Bruce Campbell wrote:
>>> On Wed, 28 Mar 2007, Justin Karneges wrote:
>>>> On Tuesday 27 March 2007 10:09 pm, Philipp Hancke wrote:
>>>>> Justin Karneges wrote:
>>>>> [...]
>>>>>> The best solution, as far as I can tell, would be for the server to
>>>>>> perform presence probes on a periodic basis, rather than only on
>>>>>> client
>>>>> The problem with that is that replies to the probe are optional. So If
>>>>> the remote contact is assumed to be online and the remote server
>>>>> chooses not to reply to probes if the contact is offline you have a
>>>>> problem.
>>>> Right.  However, I think for this procedure we'd only want to probe
>>>> against
>>>> servers that we are no longer connected to, and only after some
>>>> timeout.  If
>>> Seems to me that it would make more sense to periodically probe against
>>> the remote server itself, rather than each contact at the remote server.
>>> Is this possible?
>> Sure, servers could share presence information, though that's not done
>> today.
> It may also be enough for the "probe" in this sense to simply be s2s 
> connectivity establishment, and not an actual presence probe.
> The full probe would be more reliable though.  I imagine that if the remote 
> contact changes presence (particularly to unavailable), and there is a lapse 
> in connectivity between your server and the remote server, then you might not 
> ever receive this presence notification.
> -Justin

Hi Justin,

   One of the things I was thinking of was to use a opaque id to 
identify last updated presence state from one server to next (modelled 
loosely around xep 198).
This would be used in conjugation with probe-server to identify if 
server wants to reset state or send diff's of presence which are missing 
on remote server side.

Something like this :

Server A                                  Server B

presence userAi                 ----->   userBk
userAm                         <-----    presence userBn
probe-all presence-state query ----->    <ida>
<idb>                          <-----    probe-all presence-state query

.... after sometime which may or maynot include disconnection, reboots, 
crash, etc.

When server A has outbound to server B
probe-all currentstate query <ida> ----->   <error|result>

When server B has outbound to server A
<error|result>             <-----    probe-all currentstate query <ida>

Here, ida represets server B's presence update state for server A and 
vice versa.
On sending any presence to server A, server B will 'invalidate' this id.
Hence, if id sent in probe-all current state query by server A has not 
been invalidated, server B will return 'all ok'.

I am thinking of probe-all as iq - hence error/result.
The error could include status states which indicate :
a) too frequent polling (so prevent DOS, etc) - this should not indicate 
invalidation of id.
b) need to refresh presence.
I think there could be two ways of approaching refresh error : either 
server1 could send server2 the 'diffs' of all the presence updates which 
it missed (too complicated to maintain ?), or just ask it to flush 
remote session presence for server1 entities and then server1 could just 
send all the presence status's once server2 indicates completion (if 
not, then server1 presence updates might come in while server2 is 
updating presence on behalf of it).

Only downside of this is that server2 will need to maintain list of all 
presence updates from server1 as a from-to mapping which could 
potentially be pretty large ?
Just a pie in the sky idea ... but ofcourse without other servers 
implementing this, it is a non-starter.


More information about the Standards mailing list