2009/1/25 Jack Moffitt <[email protected]> > > This solution is not ideal. Why terminate the client for transient > HTTP or connection errors? Instead, if you get lastRid + 3, > immediately time out the lastRid + 1 request and resend it. This will > let you recover from the error gracefully.
Thank you Jack. Your offer indeed looks reasonable. As I understand from the XEP (http://xmpp.org/extensions/xep-0124.html#ack-response), it is optional for the client to cache and resend the request upon a 'report' received from the server. And because I was on the server side, I did not want to make assumptions about the client implementations. Still, I am not sure if this behavior is the best for the requests outside the defined window, e.g. (lastRid + 10) while 'requests'==2. You need this kind of graceful but prompt recovery because these > transient errors are quite common. User's are going to be very > frustrated if their BOSH sessions often and suddenly. If these errors usually happen, why don't we consider changing the XEP and making client side cache-resend obligatory? In Strophe.js we use two timeouts for this. The normal timeout is > approximately wait + 7 seconds, and triggers whenever we've waited > that long on any particular response. The second timeout is 7 > seconds, and it starts whenever we senda new request until the > previous response is received. For hold=1, this works because as soon > as we send a request when there was a previous request outstanding, we > know the server must immediately generate a response. If we receive > no response in a short amount of time, we can guess that it was lost > somewhere, and must be resent. How does your implementation perform with other hold values? The server may dictate another hold value at the session creation response. Regards, Safa Sofuoğlu
