In the end, there's not only two connections, which flip-flop (one always being an active connection). But there are unlimited connections.
Every time a new request must be sent, a new connection is created, which sends the request and then waits for a response. If a new request must be sent, while the old request is still holding, it is send over a new connection. The first response is then received. If there's more data, again a new connection is created. So, there's no connection 1 and connection 2, which are reused, but new connections are created again and again. There are not more than two concurrent connections, though. At least this is how I understood and implemented it (and it works ;-)). Am 10.12.2013 um 23:46 schrieb Justin Karneges: > On 12/10/2013 02:36 PM, Lance Stout wrote: >> The moral of the story is that you really only ever need two connections, >> and you flip between the two whenever you need to send a stanza and the old >> connection is sent whatever traffic has been buffered. > > I'm curious, what's the rationale for the flip-flopping design? It seems to > me that we could have just used a long-polling loop for receiving data, and > then a normal request/response whenever we need to send data. Not suggesting > a change or anything, just wondering why the protocol works the way it does. > > Justin >
