2010/1/10 Abhinav Singh <[email protected]>: > Yup thats what i have observed with xmpp and wrote in my last mail. Thanks > for digging another level to explain the same. > But my question was, why is a previous request replied back in case another > request comes from the client. > > When i work with event based push server, i can actually avoid empty > response to client request which was on hold before. > By doing so, I save unnecessary another request going from browser to the > server. > > == xmpp case == > a client request is on hold looking for new data from server
Yes. > a new client request goes for publishing a message Yes. > server respond to previous holded request, and then process next incoming > request Yes. > finally client fires another request to maintain that 1 necessary connection > with CM. > No, the client already just fired a request, remember? The server never replied to this one, and it becomes the new "held" request. Whether the server replies to the newest request or oldest request doesn't make that much difference, but the latter seems cleaner and technically better (and this is what happens). > == event based push case == > a client request is on hold looking for new data > Another request comes from client for publishing a message. > Server respond to client's new request while still able to hold previous > request by the client. > Same as BOSH, except in BOSH the oldest request is replied to (and the newest is put "on hold" to replace it). As I said above, it doesn't make much difference, implementation just makes more sense this way. Matthew
