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 notreceive 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
