PART II
Chapter 6: Networking Considerations 251
The problem here is not necessarily solved by the use of a request queue. As seen in
Figure 6-12, when the checkbox ‘Use Request Queue’ is selected, the responses can still come
back out of order unless the number of concurrent requests is forced to be just one, which can
potentially severely throttle the overall progress if one of the requests stalls dramatically.
Forcing the responses to be in order is what should be done in this situation. To address
this issue, a sequence number can be added to make sure that we finish servicing requests
before moving on. For example, given the previous example that makes ten requests, we
could just make a rule that says request 3 won’t be sent until requests 1 and 2 come back.
Timeouts and retries would still be performed, of course, to make sure that those values
were received. However, this can be quite slow, so it might be better to incrementally allow
requests to move along a bit at a time instead of waiting. For example, if request 1 came
back but not request 2, request 3 and beyond could still be sent, just not finished off and
displayed until the previous items were handled. This is basic idea of response queuing. In
the library, to make sure responses happen in the order in which they go out, set a flag for
options called enforceOrder to true as shown by this simple options object:var options = { method: "GET",
onSuccess : showSuccess,
payload:payloadString,
enforceOrder : true
};FIGURE 6-11 Response out of order may not make sense