HTML and CSS Reference
In-Depth Information
implementation is less trivial, at least with traditional threaded servers. For these,
such as Apache, long polling does not work well. The one thread-per-connection
model does not scale with long polling, because every client keeps a near-consistent
connection. Evented server architecture is much more apt to deal with these situ-
ations, and allows minimal overhead. We'll take a closer look at the server-side in
Chapter 14,
Server-Side JavaScript with Node.js.
13.3.1 Implementing Long Polling Support
We will use what we have learned to add long polling support to our poller without
requiring a long timeout between requests. The goal of long polling is low latency,
and as such we would like to eliminate the timeout, at least in its current state. How-
ever, because frequent events may cause the client to make too frequent requests,
we need a way to throttle requests in the extreme cases.
The solution is to modify the way we use the timeout. Rather than timing out
the desired amount of milliseconds between requests, we will count elapsed time
from each started request and make sure requests are never fired too close to each
other.
13.3.1.1 Stubbing
Date
To test this feature we will need to fake the
Date
constructor. As with measuring
performance, we're going to use a
new Date()
to keep track of elapsed time.
To fake this in tests, we will use a simple helper. The helper accepts a single date
object, and overrides the
Date
constructor. The next time the constructor is used,
the fake object is returned and the native constructor is restored. The helper lives
in
lib/stub.js
and can be seen in Listing 13.35.
Listing 13.35
Stubbing the
Date
constructor for fixed output
(function (global) {
var NativeDate = global.Date;
global.stubDateConstructor = function (fakeDate) {
global.Date = function () {
global.Date = NativeDate;
return fakeDate;
};
};
}(this));
