On Saturday, January 26, 2013 10:10:09 AM Curtis King wrote: > On 2013-01-26, at 12:11 AM, Kevin Smith <[email protected]> wrote: > > On Fri, Jan 25, 2013 at 3:29 PM, Winfried Tilanus <[email protected]> wrote: > >> On 01/25/2013 03:16 PM, Stefan Strigler wrote: > >> > >> Hi, > >> > >>> In order to resend unacknowledged stanzas upon resuming a stream you > >>> need to know about request and anwers.>> > >> Clear answer, it made me realise I was thinking about a different case: > >> what to do when only one or two stanzas are dropped but then the stream > >> is continued? In that case the session is not resumed, but the acking > >> fails... > > > > This can't happen over a reliable stream like TCP. > > I think the case he is talking about is an implementation which does acks > but no resumption. The connection drops, servers re-establish the > connection where should they re-start from? It's an reasonable assumption > to make when you have acks with no requirement to implement resumption. 198 > should mandate both acks and resumption, plus provide a number of clear > examples.
I'd say implementing acks without resumption is definitely half-assing it in the present day. It just means more endorsement for HTTP, where sessions tend to transcend TCP connections easily. To answer the OP though, you start completely over with stuff like roster, presence, etc. And you treat the unacked stanzas as if they failed to send. This can happen even if you do support resumption, but your session times out. Justin
