> On Sun, May 22, 2011 at 8:14 AM, Dhruv Matani <dhruvbird at gmail.com> wrote: >> For example, say rid=10 and rid=11 were sent to the server and the >> server responded back in the correct order. However, the responses >> came in as 11 first and then 10 which means that the client will >> necessarily have to use the rid to re-order the packets. The reason >> for this is that the payload for the packet with rid=10 was much >> higher than that for rid=11 and it took longer for the complete >> response to come in. > >> This has complicated processing for me, and I think if many people are >> to adopt it, it makes sense to separate the 2 (except if there is a >> really pressing reason to keep them together - such as not mandating >> ACKs). > > You'll have to deal with this anyway, or you'd process responses in > the wrong order. It shouldn't be difficult to deal with this with > XHR. In rough pseudocode, it'd look something like this:
Exactly my point! So, keeping the 2 (request & response IDs) together doesn't really help simplify the code (since out-of-order re-construction needs to be performed in either case) and "keeping a queue of sent requests, and reading responses from sockets in the same order you made requests" won't quite be the right thing to do. There is still post-processing to be done in either situation. Regards, -Dhruv. -- -Dhruv Matani. http://dhruvbird.com/ "What's the simplest thing that could possibly work?" -- Ward Cunningham
