[Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)

René Treffer treffer+xmpp at measite.de
Fri Feb 19 09:34:40 UTC 2010


Evgeniy Khramtsov wrote:
> Pedro Melo wrote:
>>> There are a myriad of ways the original IQ or the ack could get 
>>> lost.  My
>>> point is that the response does not serve any value to the sender, 
>>> since I
>>> don't believe there is anything useful to be done when the sender 
>>> does not
>>> receive the ack.  Resending is almost always going to be wrong.
>>>     
>>
>> Why? I think the exact opposite is true. We have item ID's so we can
>> ignore duplicates.
>>
>> Bye,
>>   
>
> I guess because if a sender doesn't receive the response, this doesn't 
> mean a receiver doesn't receive the request.
>

I think we are talking about the wrong problem. Things may go wrong, 
everywhere. The only thing that matters would be a stable way for
"Server, my state is X, is that correct?" -> {"yes", "no", "error"}

Decreasing the size of X helps, getting good ways to sync helps, trying 
to build endless layers of ack that break randomly won't help much imho.

Sending a single IQ with the client state, at the clients discretion, 
wait for the reply, and you are done with detecting any kind of 
inconsistency. At least in the cases where the server stores data. Wave 
had some stuff for that, iirc. Running a pubsub without storage is a 
fire & forget, by definition.

Regarding tcp:
The funniest thing I've found recently is the tcp stack on the motorola 
milestone, which will happily accept data to a socket - while you are in 
flight mode. It even ignores the timeouts you've set. The only way I 
currently see to overcome this is doing a new tcp connection after 
celltower handover and trying to use that one.... So no, TCP guarantees 
don't help here. The next problem is that you have to be double carefull 
if your connection breaks in the middle of an operation (recieve/send).

Just my 2¢. Please note that this is my first mail to this list, so I 
may completly miss the point :-)

Regards,
  René Treffer



More information about the Standards mailing list