heymichaelp/gistify529542.txt

## gistify529542.txt
Ron,

Becuase all client browsers and computers are different, we need a way to make sure that all clients are keeping the correct time based on the server. To achieve this, we have historically been sending down a message from the server to all clients with the current time on the server.

A few problems have occurred with this approach. One is that, since we moved from our own custome web sockets implementation to Pusher, we are now being charged based on the number of messages sent to the clients. This means that our messages to each connected client will rack up our cost, which we want to avoid. The second problem is that this can be a drain on resources for the server, especially when it is unnecessary for the auction to be updating so frequently when the auction is weeks, days, even hours, away from expiring. The client clocks do not need to be so precise during these times.

To address both of these problems, we're planning on taking the following actions:

Remove the web socket approach to keeping the auction time up to date. Instead, favor a "polling" approach, where the client asks the server for it's time as a solicited request, not passively like it happens now. This will remove the web socket messages to keep the clients up-to-date with the server clock, and thus remove all associated costs, while still achieving the same functionality.
Prescribe a polling schedule for different "phases" of the countdown clock for a given auction. In other words, change the frequency at which the client asks the server for the correct time based on how critical it is that the client clock is perfectly synchronized with the sever. The schedule we propose is as follows:
From the time the auction opens to 1 day left: Every minute 1 day left - 1 hour left: Every 30 seconds 1 Hour left - clock reset threshold: Every 10 seconds

The "threshold" is the maximum time until expiration in which a bid will reset the clock back to the threshold time. This is almost always 10 seconds, but is configurable.

We don't plan on polling the server during the threshold period, since the server will be sending down notifications for the client clocks to reset to the threshold time, and we don't forsee an opportunity for significant separation between clients within a 10 second period.

These two steps, along with other optimizations, should alleviate any clock disparities between clients that we experienced with the first auction. We want to get your feedback on this before we implement any of these refactorings, and also wanted to field any questions you might have on the implementations.
	Ron,

	Becuase all client browsers and computers are different, we need a way to make sure that all clients are keeping the correct time based on the server. To achieve this, we have historically been sending down a message from the server to all clients with the current time on the server.

	A few problems have occurred with this approach. One is that, since we moved from our own custome web sockets implementation to Pusher, we are now being charged based on the number of messages sent to the clients. This means that our messages to each connected client will rack up our cost, which we want to avoid. The second problem is that this can be a drain on resources for the server, especially when it is unnecessary for the auction to be updating so frequently when the auction is weeks, days, even hours, away from expiring. The client clocks do not need to be so precise during these times.

	To address both of these problems, we're planning on taking the following actions:

	Remove the web socket approach to keeping the auction time up to date. Instead, favor a "polling" approach, where the client asks the server for it's time as a solicited request, not passively like it happens now. This will remove the web socket messages to keep the clients up-to-date with the server clock, and thus remove all associated costs, while still achieving the same functionality.
	Prescribe a polling schedule for different "phases" of the countdown clock for a given auction. In other words, change the frequency at which the client asks the server for the correct time based on how critical it is that the client clock is perfectly synchronized with the sever. The schedule we propose is as follows:
	From the time the auction opens to 1 day left: Every minute 1 day left - 1 hour left: Every 30 seconds 1 Hour left - clock reset threshold: Every 10 seconds

	The "threshold" is the maximum time until expiration in which a bid will reset the clock back to the threshold time. This is almost always 10 seconds, but is configurable.

	We don't plan on polling the server during the threshold period, since the server will be sending down notifications for the client clocks to reset to the threshold time, and we don't forsee an opportunity for significant separation between clients within a 10 second period.

	These two steps, along with other optimizations, should alleviate any clock disparities between clients that we experienced with the first auction. We want to get your feedback on this before we implement any of these refactorings, and also wanted to field any questions you might have on the implementations.