NO!! Altering the clock cannot occur.  There are several reasons for this, but to truly understand them, there are a few concepts that you must first understand:

NOTE: YOU MUST READ THIS ENTIRE DOCUMENT IF YOU REALLY WANT TO UNDERSTAND THE ISSUE AT HAND.

1. The Basics of Internet Communications

Here are a few basic terms which are important to know for understanding Internet Communications and the clock phenomenon in ChessRally you're about to learn about:

• Host - A Host is the term used for a device on a network, in this case, the Internet.  The term "host" is sometimes used interchangeably with "node", but for the purpose of this document, we will refer to only the term "host".  A host can be a computer (like the one your using now), a router (a device that directs traffic), a mainframe, etc.  All such devices are referred to as "hosts", regardless of their purpose.  If the device can communicate on the network (Internet), it is called a "host".
• Client - A client is a host that is making a connection to a server.
• Server - A server is a host that "listens" for incoming clients, and when a client tries to connect to the server, the server "hears" the connection request and honors it or refuses it.  Whether Client or Server, both devices are ultimately called "hosts" (above) and once the connection is established are generally on "equal terms".
• Packet - A packet is a small chunk of data, usually 2 kilobytes or less in size.  When you send an email, for example, the email is deconstructed into many packets, and each packet is transmitted from one host to another, until all packets arrive at the destination, where the packets are reconstructed into your email transmission.
• Traffic - Traffic is the whole of the packets zipping around the network going between hosts.  Sometimes, if you notice the network seems slower than usual, this is called "a lot of traffic".  This is just like driving a car... when there are lots of cars out, there's "a lot of traffic".  Same concept.  Different objects.
• IP - "Internet Protocol".  IP is referred to as a "transport protocol" and it is the foundation of Internet communications.  All data that goes over the Internet is formatted in IP packets.
• IP Address - An IP Address is a number assigned to a unique host on the Internet.  The format for the number is in four parts, an A field, a B field, a C field, and a D field, all put together by periods, so it is in the format of A.B.C.D.  For example, 123.24.145.12.  Each field number can range from 0 to 255.  If you log onto the Internet through a dial-up, your Internet Service Provider will assign your computer an IP address temporarily until you drop your connection.  Temporary IP addresses are called "dynamic IP addresses".  Public servers on the Internet almost always have a unique IP address for that computer alone, and these addresses are called "static IP addresses".
• TCP/IP - "Transfer Control Protocol / Internet Protcol".  TCP/IP is a "gussied up" version of IP, and has features built into it to manage the data stream, so every single packet sent is ensured that it will arrive at the destination, is intact, and is in the right order in relation to other packets involved in the transmission.
• Application Protocol - An application protocol is the actual data sent between hosts in a format that each other understands.  For example, the application protocol of the web is HTTP (Hyper Text Transfer Protocol).  With HTTP, the client makes a request of the server for a specific document.  The server replies with either the document or an error.  It's a very simple application protocol.  Other application protocols are FTP, Telnet, etc.  For ChessRally, we have designed our own application protocol called CRP (ChessRally Protocol).  All of these application protocols are transmitted over the Internet via IP (typically TCP/IP).
• Message - This is a term specific to the ChessRally Protocol.  Each group of data sent from one host to another is called a "message".  Do not confuse this with the end-user game terms "chat message" and "private message", which are human to human messages.  In the world of "ChessRally Under-The-Hood", a message is a "transmission" containing a complete CRP item.

It is important to note that the Internet is comprised of millions of hosts, all sending data back and forth over IP.  Because of the sheer magnitude of the number of hosts, it is not practical (really, it's impossible) to directly wire every host to every other host.  Instead, the hosts are only connected to their "peer group" (usually a LAN), and a host on the peer group (typically a router) is the "interface" to the other hosts for other peer groups.  There are many levels to this topology (a topology is a physical design of a network).  As a result of this topology, when a host wants to send data to/from another host very far away, the data must pass through a series of hosts until it reaches the destination.  If you do a "trace route" to another host (The "tracert" command in your Windows Command Prompt) it will show you what hosts your data passes through to get to the destination.  Each step along the way is generally called a "hop".

This is quite significant, because "hopping around" slows down the flow of data, which is incredibly important to understanding the whole clock phenomenon.  You could send a 3 packets of data to another host, and the 1st might take 4 seconds to get to the destination, 2nd might take 1 second, and the 3rd might take 40 seconds.  This happens because the state of the Internet and all the hosts is constantly changing, and traffic is constantly fluctuating, causing 3 different packets all coming from one host and going to the same host to arrive at different times.  Also, the three packets in that example, may actually travel along different routes.  If a host that accepts packet one suddenly gets busy, the packet may be redirected to another host which can handle the traffic.  In doing so, the packets may all take dramatically different routes, but they will all eventually arrive at the same destination.

Therefore, when your computer (the client) is connected to a ChessRally Room Server (the server) and you're playing a game.  Each of your moves may take arbitrarily longer and shorter times to arrive at your opponent's computer.  Vice Versa.

2. The Basics of Internet Synchronization

Since the Internet is by design very slow (at least in terms of electronics), synchronization becomes a problem.  On the Internet today, there cannot be true real time activities.  We can simulate real time, but due to the lack of speed across the Internet and the lack of consistency, true real time cannot yet exist.  (And if anyone claims otherwise, they're either trying to sell you something, or simply don't know any better.)

For multimedia on the Internet, the solution is buffering.  I'm sure you've watched a video clip or two, or at least listened to an audio clip or two.  When you do, you'll notice that your media playing software will wait a few seconds (sometimes as long as a minute or more) before playing the media while it "buffers" the data.  Buffering is simply keeping a big chunk of the data in store for easy access, then while you use the stored (buffered) data, more data comes in to keep the buffer full.  Basically, it's a form of intentional time delay, in order to keep your multimedia running smoothly.  This way, if the network gets slow, you still have some unplayed media stored up, which keeps playing until the buffer runs out... and the idea is that the temporary slowness or outage will be resolved and the buffer will be filled again before it runs out.

All synchronization on the Internet utilizes some form of "time delay" because of the volatile nature of the Internet.  The same goes for ChessRally.

3. The Clock Problem

For timed games in ChessRally, buffering as such is not an option.  However, we still needed a way to ensure that each player got the same exact amount of time for their moves so the game would be fair.  Also, according to the FIDE Laws of Chess for computer play, "network transmission time" must be accounted for and not counted against either player, since while data is in transit, it is really neither player's turn.

So, a couple of options were considered...

A. We could run the clocks from the server, which would work, but the clocks on the client end would tick in a VERY offbeat way... making people think the clock was buggy, even though it would technically be accurate.  For example, consider the following diagram:

  Accurate clock time displayed over time:
    1     2     3     4     5     6     7     8
    +-----+-----+-----+-----+-----+-----+-----+>>
    (time in seconds)

  Server controlled clock time displayed over time
  (possible results of network delay):
    1      2     3        4   5    6      7   8
    +-----+-----+-----+-----+-----+-----+-----+>>
    (time in seconds)

As you can see from the diagram, the server controlled clock would appear "off" and "jumpy", although the actual time represented would generally be accurate.  We didn't feel this was good because most users would thing the game was "buggy" as a result.  So, we scrapped that idea.  (Note also that the above example is merely an example... the fact is that it could be a little "neater" than that, or it could be way, way worse... it depends on network conditions, etc.)

B. We could run the clocks from a central time server, synchronizing the clocks at the beginning of a game, so each players PC was in tune with the other.  This sounds great at first, but would open the game up to cheating very easily, since it is so easy to change one's own system clock.  So, we scrapped that idea very, very quickly.

C. (Addendum, June 2005) We did also consider taking approach "A", above, and then "smoothing out" the clock results with a player's PC for perceptual consistency.  This would yield perfect LOOKING clocks, but would not account for time-in-transit, making it possible for someone to cheat on time by lagging their connection to the Internet while waiting for an opponent's move... and no one would be the wiser, since the clocks would always LOOK right... never mind the fact that it would make the games incredibly unfair time-wise.  This is actually the approach that most chess sites and online chess software venues take.  They do it because people don't complain about it if the clocks LOOK right.  However, this is also in direct violation with the FIDE (World Chess Federation) handbook, which requires that time-in-transit of networked games must be accounted for, with neither player penalized for it.  The approach of such sites and services is "what the user doesn't know can't hurt them".  We're a bit more honest than that, but the downside is using the most accurate clocks is that time-in-transit makes them LOOK wrong, and your total game time will ALWAYS be more (sometimes MUCH more) than the two player clocks combined, since it contains not only player move time, but time-in-transit as well.  We are working on a new system which will provide better estimation, in order to appease the many players that simply do not understand why their opponent seemed to have been given more time (even though, under the hood, they did NOT) and assumed someone was cheating.  In v2.5, we made it so that the clock as perceived by the one player would wait for an acknowledgement from the other player's computer, and to DELAY the starting of one's perceptual clock.  Unfortunately, in some cases, the acknowledgement (a tiny packet) gets lost en route, and the clock never starts... which makes EVERYONE believe "cheater cheater!!!", while it not be the case.  Hopefully, in 2.6, we will be able to devise a new clock system which will maintain the incredible accuracy of the current clocks, but with much more "natural looking" clock values so as not to alarm anyone.  In any case... up until (& including) version 2.5, we have used a different solution...

4. The Solution

To make it as fair as possible, so each player gets exactly the time they deserve, not a millisecond more, and not a millisecond less... we came up with the idea for a "decentralized" clock, where each player's own computer manages his/her own respective playing clock.  This might sound at first like it leaves the game open to cheating, but it really doesn't... each player's clock is governed not by the system clock, but by the High Performance Counter (HPC), which is accurate to nanoseconds.  The player's time is merely "marked" at the beginning of their turn, then a second "mark" is taken from the end of their turn, and the difference is calculated to generate the appropriate number seconds (accurate to the microsecond) and that value is used as their "move time".  The clock that you see is being updated by a standard timer, and is just an estimate.  The REAL clock is true to itself, regardless of what shows on your display.  In order for someone to hypothetically cheat, they'd have to somehow manipulate the values that the HPC timer gets.  However, this kind of counter can not be tampered with.  The HPC is based on Processor (CPU) cycles, and not on a 24 hour clock.  Even if a player was an "uber hacker" and smart enough to trigger the timer manually (which in truth is quite impossible, but hypothetically...), such manual triggering would increase the clock count, shortening their time.  The reason it's not possible is because CPU cycle tracking and the instruction pointer inside the CPU are co-dependant, so if someone COULD mess with it, they'd cause a system crash (or possibly even catastrophic system failure) on their own computer.

Naturally, each player's turn ONLY begins when their opponent's turn ends, and their own turn ends when they move a piece (and slap their clock button, which in ChessRally, is the "Finish Turn" button, unless you have "Single Step Turn Completion" enabled, then you don't have to press "Finish Turn".)  On the Internet however, a player does not know when their opponent's turn has ended until the "move message" arrives from their opponent's computer, so there is a piece of time that is "unaccounted for" while the move message is transmitted between hosts... and sometimes this "time in transit" is quite significant - it can range from 40 milliseconds all the way up to 4 minutes if both of the players are on connections where routing to the game server is extremely slow, or heavily obstructed.  During this "time in transit", it is neither player's turn since the opponent has already finished their turn (from their perspective), but from the player's perspective, the opponent still has the move, since the "move message" has not yet arrived.  For that player, their own turn has not yet begun.  So, we have "dead time" between the instant one player finished their turn and the instant their opponent received it, thus starting their turn.

To make sure the system was fair, the move message is comprised of both a player's move (piece, location, capture info, etc.), and the exact time (in microseconds) it took to make that move, from the time the player's computer received their opponent's move message to the time the player completes his/her own move.  (Their own move is then transmitted over the Internet as a move message to their opponent.)  Each copy of ChessRally then adds up the time-of-move for each move of the game and calculates each players clock accordingly.  Both player's clocks are handled in this same exact fashion.

For example, in a 5 minute game (which is 300 seconds [and no time bonus]), if "White Client" made 3 moves in the game, and the moves took 1.234 seconds, 3.721 seconds, and 0.781 seconds, respectively, and "Black Client" made 2 moves in the game (it's black's turn now, and so far, the move clock is at 0.456), which are timed at 3.108 seconds and 1.583 seconds, respectively, those times are added up by the game client (your copy of ChessRally) and subtracted from the 5 minute limit.  Here's how that works:

When an opponent has the move, the player's computer does not yet not what the "time-in-transit" was, and it will not know that value until the opponent replies.  So when a player's copy of ChessRally doesn't know what the exact value of the opponent's clock is, it shows the clock as if the opponent received it immediately.  This seemed better than just freezing the opponent's clock until they reply with a move, although it is a rough estimate of what the opponent's clock really is.

In the case of the above example, since it is Black's turn, on White's computer, it shows MERELY AN ESTIMATE of Black's clock based on the best available data.  However, this may be ahead of Black's actual clock by anywhere from 0.5 seconds to 6 seconds (and on up to 30-60 in extreme cases).  So, when Black finishes the move, and White receives the move message, the clock for the Black player on White's computer reads "SYNC" for a moment, and then shows the corrected, adjusted time.  This is what gives the appearance of one's opponent's clock getting extra time.  However, it is not actually getting extra time at all.  Your copy of ChessRally is just adding the real actual time of the move to the game, discarding the excess since it belongs to "dead" network transmission time, and not to any particular player's move.

PLEASE NOTE: Your own clock will never need to be synchronized on your own PC, since your own PC is already in synch with your copy of the game.  There is no network transmission time to consider.  This is why your opponent's clock may seem to add time, but your own clock does not.  It is also why your own player clock never reads "SYNC".

To further illustrate the point, follow this timeline (top to bottom) and watch what takes place during a game.  First, the White Client sends their move to the server, starting the estimated Black Client's clock as it appears on White Client's computer.  (MM = Move Message)

 Actual     White Client's      Server       Black Client's
 Seconds     Computer                         Computer
 
  00:00   +-------+-------+     +----+     +-------+-------+
          | Black | White | MM  |    |     | Black | White |
          | Clock | Clock | >>  |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 01:00 | 01:00 |     |    |     | 01:00 | 01:00 |
          +-------+-------+     +----+     +-------+-------+

  00:01   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     | MM |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:59 | 01:00 |     |    |     | 01:00 | 01:00 |
          +-------+-------+     +----+     +-------+-------+

  00:02   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |  MM | Black | White |
          | Clock | Clock |     |    |  >> | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:58 | 01:00 |     |    |     | 01:00 | 01:00 |
          +-------+-------+     +----+     +-------+-------+

At this point, the Black Client (right) has received White's Move Message (MM), and so the Black Client's clock starts on his/her own PC.  (Note that the Black Clock on White Client's Computer (left) is purely an estimate since it doesn't know when the move will be received by the Black Client's Computer, and is different than what shows up on Black's own clock for him/herself.)  It is now officially Black's turn.

  00:03   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:57 | 01:00 |     |    |     | 01:00 | 01:00 |
          +-------+-------+     +----+     +-------+-------+

For the sake of example, we're going to say Black took about 3 seconds to take their move, so we're skipping to the point where Black finishes his/her turn.  Note also that Black's "time of move" (3 seconds) is sent with his/her move message.  Also note that the Black Clock on White Client's Computer is off now by about 3 seconds as a result of network transmission time, and that since Black is done with his/her move, the White Clock on Black Client's Computer begins to count down.

  00:06   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:54 | 01:00 |     |    |     | 00:57 | 01:00 |
          +-------+-------+     +----+     +-------+-------+

  00:07   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |  MM | Black | White |
          | Clock | Clock |     |    |  << | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:53 | 01:00 |     |    |     | 00:57 | 00:59 |
          +-------+-------+     +----+     +-------+-------+

  00:08   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     | MM |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:52 | 01:00 |     |    |     | 00:57 | 00:58 |
          +-------+-------+     +----+     +-------+-------+

  00:09   +-------+-------+     +----+     +-------+-------+
          | Black | White | MM  |    |     | Black | White |
          | Clock | Clock | <<  |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:51 | 01:00 |     |    |     | 00:57 | 00:57 |
          +-------+-------+     +----+     +-------+-------+

OK, at this point, notice that Black Clock on White Client's Computer reads "SYNC".  This is to alert the White Client that the Black Clock as it appears on White Client's Computer is being adjusted for the correct "time of move" for Black, which was 3 seconds, not 10 seconds. 

  00:10   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | SYNC! | 01:00 |     |    |     | 00:57 | 00:56 |
          +-------+-------+     +----+     +-------+-------+

Note that the Black Clock on White Client's Computer is now adjusted to read the correct clock for Black.  Also, White's clock is counting down, and notice the difference between the clocks on the two clients.

  00:11   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:57 | 00:59 |     |    |     | 00:57 | 00:55 |
          +-------+-------+     +----+     +-------+-------+

OK, White takes 4 seconds to complete the move.  However, due to unforeseen network difficulties, the move message takes a very long time to get to black.  (Also, remember that Black's Clock on White Client's Computer begins right away since it doesn't know how long it will take to get to Black Client - And that White Clock on Black Client's computer is STILL running down, since it doesn't yet know that white has moved.)

  00:15   +-------+-------+     +----+     +-------+-------+
          | Black | White |MM   |    |     | Black | White |
          | Clock | Clock |>>   |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:57 | 00:55 |     |    |     | 00:57 | 00:51 |
          +-------+-------+     +----+     +-------+-------+

  00:20   +-------+-------+     +----+     +-------+-------+
          | Black | White | MM  |    |     | Black | White |
          | Clock | Clock | >>  |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:52 | 00:55 |     |    |     | 00:57 | 00:46 |
          +-------+-------+     +----+     +-------+-------+

  00:25   +-------+-------+     +----+     +-------+-------+
          | Black | White |  MM |    |     | Black | White |
          | Clock | Clock |  >> |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:47 | 00:55 |     |    |     | 00:57 | 00:41 |
          +-------+-------+     +----+     +-------+-------+

  00:30   +-------+-------+     +----+     +-------+-------+
          | Black | White |   MM|    |     | Black | White |
          | Clock | Clock |   >>|    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:42 | 00:55 |     |    |     | 00:57 | 00:36 |
          +-------+-------+     +----+     +-------+-------+

  00:35   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     | MM |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:37 | 00:55 |     |    |     | 00:57 | 00:31 |
          +-------+-------+     +----+     +-------+-------+

  00:40   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |MM   | Black | White |
          | Clock | Clock |     |    |>>   | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:32 | 00:55 |     |    |     | 00:57 | 00:26 |
          +-------+-------+     +----+     +-------+-------+

  00:50   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    | MM  | Black | White |
          | Clock | Clock |     |    | >>  | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:22 | 00:55 |     |    |     | 00:57 | 00:16 |
          +-------+-------+     +----+     +-------+-------+

  01:00   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |  MM | Black | White |
          | Clock | Clock |     |    |  >> | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:12 | 00:55 |     |    |     | 00:57 | 00:06 |
          +-------+-------+     +----+     +-------+-------+

At this point, White Clock on Black Client's Computer has gone down to zero, but it is not really at zero, it's just taking forever for the Move Message to get to the Black Client's Computer... so the White Clock on Black Client's Computer goes to 00:00 and hovers there.  (Note that this does not end the game, as ending the game by time expiration is claimed ONLY by the player's computer who runs out of time.)

  01:10   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |   MM| Black | White |
          | Clock | Clock |     |    |   >>| Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:02 | 00:55 |     |    |     | 00:57 | 00:00 |
          +-------+-------+     +----+     +-------+-------+

  01:11   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:01 | 00:55 |     |    |     | 00:57 | SYNC! |
          +-------+-------+     +----+     +-------+-------+

Here, we have a classic example of what people are seeing that makes them think cheating is going on.  The White Clock on Black Client's Computer has JUMPED FROM 00:00 to 00:55!!  However, if you were following all this, you'd know this was normal, expected behavior... after all, it only did take White Client 4 seconds to make their move... it just took a really long time to get to Black.

  01:12   +-------+-------+     +----+     +-------+-------+
          | Black | White |     |    |     | Black | White |
          | Clock | Clock |     |    |     | Clock | Clock |
          +-------+-------+     |    |     +-------+-------+
          | 00:00 | 00:55 |     |    |     | 00:57 | 00:55 |
          +-------+-------+     +----+     +-------+-------+

So, let me restate all this clearly and concisely... EACH PLAYER'S CLOCK IS GOVERNED BY THEIR OWN PC IN A "NON-CHEATABLE" WAY.  EACH PLAYER'S OPPONENT'S CLOCK ON THEIR OWN COMPUTER IS EITHER THE TIME FROM ALL THE OPPONENT'S MOVES ADDED UP, OR AN ESTIMATE OF THE OPPONENT'S TIME (IF IT IS CURRENTLY THE OPPONENT'S TURN).  The clocks are 100% accurate and fair this way.  Any visual discrepancies due to poor network conditions are merely visual... that is, it's an issue of perception, and it doesn't really affect the game.

5. Not convinced?  Still think your opponent is cheating the clock?  Then consider the following Q&A:

Q: Isn't the Internet pretty much instantaneous for me?  I'm on a very fast connection!  When I type a message in ChessRally, it pops it RIGHT away.  So the clocks should be instantaneous too, right?

A: Depends.  As far as throughput is concerned, broadband is great.  (Cable, DSL, etc.)  This is not an issue of throughput/bandwidth, however, but an issue of latency.  Latency is the time it takes for the data to get from one place to another.  Throughput/bandwidth, is how much data can be pushed over the connection at one time.  For example, if you have a broadband connection to a server on the planet Mars.  (OK, clearly this is hypothetical)  To download a file, it might take a couple of hours for the file to get to your computer, BUT once it starts coming in, it comes in all at once because you have a lot of bandwidth.  To make that example more realistic, you may find that clicking on the download for ChessRally 2 takes a few seconds to popup the download screen, but once you begin downloading, it's quick.  Well, the few seconds to popup the download screen is because it took a few seconds for the first bits of data to get to your computer... that's latency.  And latency is the cause of the clock phenomenon.  As far as typing a chat message in ChessRally, if your connection to the server is pretty solid with only a few hosts in between you and the server, then sure, it might seem fairly instantaneous... but two things: 1. Your opponent may not be so lucky, and 2. The Internet is very volatile.  One message may be instantaneous, and another might take a minute or two.  Ideally, they are all very, very quick, but that's not always the case.

Q: Isn't it possible for someone to cheat by adding time as if it where a time bonus game?

A: No, absolutely not.  The bonus time functionality (adding seconds per completed move) is calculated locally on your own computer only.  It is not transmitted with the move messages.  There is no messaging interface for "notifying" of bonus time.  It is simply calculated after both player's clocks have been calculated on your own PC.  It is not part of an actual player's clock time, but an "after thought", added once the clock has been calculated.  Taking the above example of how ChessRally calculates the clocks, I'll now illustrate how bonus time is added:

.Q: I'm still not convinced.  How can I tell if someone is cheating on time?

A: Well, simply put, in order to make the clock go up from a previous confirmed value when their is no bonus time (or in excess of the bonus time, if one is present), then one of the time-of-moves for one of a players move MUST BE NEGATIVE.  For example, if a player's moves take 2, 1, 3, then 4 seconds, their expended time is 10 seconds.  If on their next move, it is 0 seconds (possible if < 0.5 seconds, and happens with experienced blitz players or people with a "fast mouse hand"), in any case, if it is 0 seconds on the next move, the expended time is 10 seconds, and the clock stays the same.  If the new time of move is > 0 (lets' say 2 seconds), then the expended time is 12 seconds, causing the time remaining on the clock to go down by 2 seconds.  THE ONLY WAY TO GET THE CLOCK TO "GIVE" TIME THAT IT SHOULDN'T IS TO HAVE A TIME OF MOVE LESS THAN 0.  For example, if the time of move was -2 seconds, then the total expended time would be 8 seconds, so the clock would appear to go up.  IF YOU DO NOT SEE A NEGATIVE NUMBER FOR A TIME OF MOVE IN THE MOVE HISTORY, THE PERSON DID NOT CHEAT.

.
News | Get Gold! | Features | Screens | Themes | Download | FAQ | Support | Corporate

All content on this website is Copyright © 2001-2010, Ingenuware, Ltd.  All Rights Reserved.
ChessRally™ and Ingenuware™ are Trademarks of Ingenuware, Ltd.
All "non-Ingenuware" trademarks and content are the Trademarks and Copyrighted material of their respective owners.