Alright i wrote what i see from my bosh implementation. Here is the log: 2010-01-11 16:33:07 Sending Body>> http://jabber.org/protocol/httpbind'/> (Previous request on hold, looking for new data)
2010-01-11 16:33:35 Sending Body>> http://jabber.org/protocol/httpbind'>Hi(User sends new message) 2010-01-11 16:33:35 Received Body<< http://jabber.org/protocol/httpbind'/> (Empty response for previous hold request) 2010-01-11 16:33:35 Sending Body>> http://jabber.org/protocol/httpbind'/>(New request on hold, looking for new data) 2010-01-11 16:33:35 Received Body<< http://jabber.org/protocol/httpbind'/> (Empty response for new send message request) Now from the discussion i assume, my client side js should not be send an extra request after an empty response returned for previous holded request. It should ideally wait for the response of sendMessage request which ideally will be holded by the server until new data is available, right? Abhinav Singh, Bangalore, India http://abhinavsingh.com ________________________________ From: Matthew Wild <[email protected]> To: Bidirectional Streams Over Synchronous HTTP <[email protected]> Sent: Mon, January 11, 2010 4:20:10 PM Subject: Re: [BOSH] Pipelining / avoiding use of 2x HTTP-sockets 2010/1/11 Abhinav Singh <[email protected]>: > > @Matt > Yeah it doesn't make a difference (xmpp or event based approach). > In any case server always have a request from client to which it can reply > to. > However in case of xmpp it's another extra request which serves this purpose > and in event based servers this extra request can be saved. > As I wrote above it is *not* an extra request. What makes you think otherwise? Am I misunderstanding you? Client fires first request (1) Server has no requests open, so holds it open (time passes) Client wants to send data, so it makes a new request (2) Server now sees that it has 2 requests open from the client (1 and 2) Server replies to request 1 with no data Request 2 is being held until there is data to send the client I don't see how you could reduce the number of requests here. Matthew
