Hi, I tried setting up a bosh connection manager with PHP sometime back. Then i noticed, if you have a pending request from the browser, and user tries to send another message. In such case for some reason the previous pending request is immediately replied back by the jabber server to the conn manager. Finally, ajax corresponding to send message is processed and replied back. Thereafter, another request is put on hold for any incoming data.
As read from various docs that we can have 2 requests per domain at a single time, I actually never see that happening. My previous request is never being replied at a later point when data was actually available. However since everything works fine, I think this is how it should be. Checked speeqe and other web based bosh implementations, seems like same thing happen there too. Since this seemed like a relevant ongoing thread, i though i would clear my point here. Is this how it should be? Abhinav Singh, Bangalore, India http://abhinavsingh.com/blog ________________________________ From: Mridul Muralidharan <[email protected]> To: Bidirectional Streams Over Synchronous HTTP <[email protected]> Sent: Sat, January 9, 2010 4:24:46 AM Subject: Re: [BOSH] Pipelining / avoiding use of 2x HTTP-sockets --- On Sat, 9/1/10, Peter Saint-Andre <[email protected]> wrote: > From: Peter Saint-Andre <[email protected]> > Subject: Re: [BOSH] Pipelining / avoiding use of 2x HTTP-sockets > To: "Bidirectional Streams Over Synchronous HTTP" <[email protected]> > Date: Saturday, 9 January, 2010, 1:50 AM > On 12/30/09 8:47 AM, Mridul > Muralidharan wrote: > > > > Ian should really write up some document describing > the way 124 is > > supposed to work, I have seen it confusing quite a lot > of people. > > Ian disappeared quite a while ago. Ah ! Was not aware of that. > > > 124 requires that when client wants to send a request, > it should be > > able to as soon as possible : since the previous > request from client > > would typically be blocked at CM if there is no > response to be > > returned. > > Correct. > > > This means that : a) Client uses 'another' connection > to talk to CM. > > In this case, CM will immediately respond back on the > previous > > connection and 'block' on the new connection (for > returning responses > > with minimum delay when server needs to send async > messages back). > > Yes, that is the pattern we assume. > > > b) > > If client uses same socket (for whatever reason : > pipelining POST's > > is really weird behavior IIRC), then CM should detect > availability of > > a new request from client and send a response back for > the previous > > request. > > > > (b) is not required since most, if not all, impl's do > not pipeline > > post requests. > > Mridul, I agree with your later message that pipelining > POSTs should be > strongly discouraged, as it already is in RFC 2616. Do we > need some text > about that in XEP-0124? I always assumed that was implicit, but it is not obvious when starting out I guess. Considering the confusion it raised, I think you are right - we might want to discourage it strongly : with references to http rfc for the "why". Regards, Mridul > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
