Well the human reaction time is about 400ms (eg. this figure is used in drag racing timing -- if your car moves less than 400ms after the light goes green, you are disqualified).
So you can actually move the piece in anticipation that the opponent's move will arrive in the next 300ms or so, and so achieve an actual move time of even as low as 100ms. Obviously this technique is best when your plan isn't affected by what the opponent's move might be. Incidentally this is a common cause of losing speed games: if you are both down to under 1 second, under perfect net conditions you can each move every 100ms (the server-imposed limit). But if there is a slight bit of lag (causing the opponent's move to not come in that window when you are expecting it), you will make your move too soon (so the client will ignore it), and you have to reposition the mouse and move again, so your move may take 400ms+ to go through, so you lose on time.
Let's say 100ms instead of 20ms then: when I change ISPs and have 400ms lag instead of 300ms, I can really tell the difference (in fact I play worse since I am not used to having to move that bit much faster).
But you're right: on the client end the calculation time would be neglibigle. (In fact I think the existing timestamp is slow: ICMP pings are consistently about 60ms faster than pings over the timestamp connection).
Having read the researcher's paper more fully: there are two "network security protocol"s in question: 1) 'timestamp' encrypts its messages to prevent tampering; this is obviously useless if you have already reverse-engineered the timestamp program 2) the Windows client uses some weak security to identify itself and allow credit-card processing.
Obviously the solution to (2) is, as the researchers suggest, only allowing credit card by a secure web-based system (which are known to work as well as possible).
As far as (1) goes, the paper highlights some possible improvements. Also note that this only applies to speed games -- in a long game (eg. 15 minutes per side), a couple of extra seconds won't make a difference, and ICC offers the facility to prevent people from playing games with you if their lag is above a certain limit you can specify.
FWIW the claim by ICC that they don't keep a record of credit cards is FALSE, as one time, I was accused of cheating by an administrator, whose evidence was that I paid my account with the same credit card as my creditcard-less friend's account (and the dumb admin thought that therefore I had 2 accounts).
ICC's game security relies on a program called 'timestamp' that accurately records how much time you used for the move (so that players with more internet latency than others don't get penalised). This timestamp program is not open source but they publish a binary version for various operating systems. It sounds as if someone has hacked this (ie. so you can tell it that your move took 0.1 seconds -- the server deliberately does not allow moves to be faster than 0.1 seconds). If you have ever played a timed chess game (especially, one with short times, eg. 1 minute per game), you will know that this represents a huge advantage.
I don't know what the article means about "complete control over the game", the server does not allow illegal moves etc. -- unless they have somehow hacked into the server, or managed to insert packets into the TCP/IP connections between the server and the opponent (which would be a problem with FreeBSD or the opponent's OS).
Also the article mentions 'network security protocol', which is odd given that you can play games there by a plain telnet connection (telnet to chessclub.com:23 or chessclub.com:5080) or any 3rd party clients with no security.
The Windows client software supplied by ICC includes some un-documented security to validate itself (ie. let the server know you are using this piece of software and not a 3rd-party client), this is useful for detecting if people are trying to cheat by getting a chess-playing program to automatically play their moves for them.
And finally, I fear that a "robustification" of timestamp, to use accepted open security mechanisms, would end up in greater lag for the players -- either due to greater packet sizes, or greater processing power required by the client or the server (which has to do this for 4000+ connections at once), which is a pity (even 20ms is noticeable in a speed game of chess).
I am certainly no Bushite, but even I, as a New Yorker who lived through 9/11, would find the idea of an international court to try bin Laden patently offensive. He committed a crime against me, in my territory and I deserve to have him tried in a court that follows my laws.
Failing that, you could always invade 2 countries, kill thousands, and infect the rest with uranium poisoning
Maybe it should be www.damnbiglinux.org. This is even bigger than the default install of Debian was a few years ago, and that's saying something. When I heard the name 'damn small' , I envisaged something that is well under 1.44Mb (the size of a floppy), so it would actually be useful for systems with limited resource. If I want a 50Mb version I can just go and get any popular distro and not install Xwindows and development stuff.
It would be good to see these in the shoes of the "50km walk" participants, to detect cheating. TV cameras repeatedly show snapshots of people with both feet in the air (the regulations of the sport are that you must have 1 in contact with the ground at all times). I predict that if this technology came through, the race times would increase by 15%
From the site's FAQ: Q: Why is keyboard based reader support so primitive?
A: Keyboard based readers, while cheap and easy to interface, have several problems. First off, The reader simply decodes each track that is present, from 1 to 3, appending each track to the next. No dividing characters are used, so it very difficult to detrimine where the decode for 1 track ends and the next begins. Not being able to reliably seperate the track data means we can't analyze it using our card database. For now, Keyboard based readers work best with cards that only have 1 track.
The keyboard-based reader I have, has dip-switches on it so you can put start and end markers around each track, and select which track you want. Sounds like the guy hasn't done much research on available card readers (or available card writers).
Also, the mag card format is an ISO standard so it isn't as if there is any mysterious behaviour going on here (apart from the non-standard card he mentioned).
Finally, in case anyone was under the wrong impression, having a mag card writer doesn't mean you can break anyone's bank account (bank cards don't contain security information). The worst you could do would be to copy someone else's card for a building security system, then rob it and try and blame the other guy (somehow I don't think this would be too successful).
Hype is for shitty products that would fall over without it. Eg. MS Windows. How many of us had heard of DOOM 1 before someone chucked us a few floppies? None I'll bet. But it is now one of the alltime classics.
At first I thought it was alright, but the more I've used it the more I loathe it. I find it inconsistant and I find at its core everything that goes against what a well designed language should be.
I'm glad you said that! I thought it was just me. Once the excitement of being able to write a socket-using application in 5 minutes wore off, and the hours of fiddling and adjusting to fix all the little unexpected behaviours set in (not to mention the entire rewrite each time a new PHP version comes out), it sucks. 3 cheers for C++ and portability and reliable behaviour. Now if only there was a good sockets library..
I was replying to an AC, maybe it's below your threshold. He said "int main() is invalid, it should be int main(int argc, char **argv)". Obviously implying that it should not be int main(void) either.
I was pointing out that int main(void) is valid and equally preferable to the longer version, in the eyes of the standard (in the eyes of me, the short version is preferable if you do not intend to use commandline arguments).
Maybe you should read the specs. int main(void) is valid in C and C++. Including stdio.h and calling printf (not std::printf) is valid in C++, although it is deprecated. Using C library functions instead of streams is entirely valid, too.
Calling exit() and returning from 'main' are exactly equivalent. 0, EXIT_SUCCESS, and EXIT_FAILURE must be supported, and 0 must indicate success to the host environment (although it doesn't have to be the same as EXIT_SUCCESS). Otherwise the system doesn't conform to the C standard (for hosted environments). (See ISO 9899:1999 7.20.4.1#5 and 5.1.2.2.3#1)
or equivalent. (See ISO 9899:1999 5.1.2.2.1 for a definition of 'equivalent').
Since yours is different, your program's behaviour is undefined (ie. a bug).
FWIW, your version says that main takes an unspecified number of arguments of unspecified type, cf. the following correct program:
int x();
int main(void)
{
return x(0);
}
Slashdot Mirror
Today's version of DNS is the last thing I would want to inflict on another species
Wasn't the question "What is 6 x 9 ?"
My country is only up to season 8 you insensitive clod!
Jin users are allowed to play rated games now?
Well the human reaction time is about 400ms (eg. this figure is used in drag racing timing -- if your car moves less than 400ms after the light goes green, you are disqualified).
So you can actually move the piece in anticipation that the opponent's move will arrive in the next 300ms or so, and so achieve an actual move time of even as low as 100ms. Obviously this technique is best when your plan isn't affected by what the opponent's move might be.
Incidentally this is a common cause of losing speed games: if you are both down to under 1 second, under perfect net conditions you can each move every 100ms (the server-imposed limit). But if there is a slight bit of lag (causing the opponent's move to not come in that window when you are expecting it), you will make your move too soon (so the client will ignore it), and you have to reposition the mouse and move again, so your move may take 400ms+ to go through, so you lose on time.
Let's say 100ms instead of 20ms then: when I change ISPs and have 400ms lag instead of 300ms, I can really tell the difference (in fact I play worse since I am not used to having to move that bit much faster).
But you're right: on the client end the calculation time would be neglibigle. (In fact I think the existing timestamp is slow: ICMP pings are consistently about 60ms faster than pings over the timestamp connection).
(-5 Lame, for replying to my own post)
Having read the researcher's paper more fully: there are two "network security protocol"s in question:
1) 'timestamp' encrypts its messages to prevent tampering; this is obviously useless if you have already reverse-engineered the timestamp program
2) the Windows client uses some weak security to identify itself and allow credit-card processing.
Obviously the solution to (2) is, as the researchers suggest, only allowing credit card by a secure web-based system (which are known to work as well as possible).
As far as (1) goes, the paper highlights some possible improvements. Also note that this only applies to speed games -- in a long game (eg. 15 minutes per side), a couple of extra seconds won't make a difference, and ICC offers the facility to prevent people from playing games with you if their lag is above a certain limit you can specify.
FWIW the claim by ICC that they don't keep a record of credit cards is FALSE, as one time, I was accused of cheating by an administrator, whose evidence was that I paid my account with the same credit card as my creditcard-less friend's account (and the dumb admin thought that therefore I had 2 accounts).
ICC's game security relies on a program called 'timestamp' that accurately records how much time you used for the move (so that players with more internet latency than others don't get penalised).
This timestamp program is not open source but they publish a binary version for various operating systems.
It sounds as if someone has hacked this (ie. so you can tell it that your move took 0.1 seconds -- the server deliberately does not allow moves to be faster than 0.1 seconds). If you have ever played a timed chess game (especially, one with short times, eg. 1 minute per game), you will know that this represents a huge advantage.
I don't know what the article means about "complete control over the game", the server does not allow illegal moves etc. -- unless they have somehow hacked into the server, or managed to insert packets into the TCP/IP connections between the server and the opponent (which would be a problem with FreeBSD or the opponent's OS).
Also the article mentions 'network security protocol', which is odd given that you can play games there by a plain telnet connection (telnet to chessclub.com:23 or chessclub.com:5080) or any 3rd party clients with no security.
The Windows client software supplied by ICC includes some un-documented security to validate itself (ie. let the server know you are using this piece of software and not a 3rd-party client), this is useful for detecting if people are trying to cheat by getting a chess-playing program to automatically play their moves for them.
And finally, I fear that a "robustification" of timestamp, to use accepted open security mechanisms, would end up in greater lag for the players -- either due to greater packet sizes, or greater processing power required by the client or the server (which has to do this for 4000+ connections at once), which is a pity (even 20ms is noticeable in a speed game of chess).
Anyone have more information?
Failing that, you could always invade 2 countries, kill thousands, and infect the rest with uranium poisoning
It's Romulans that cloak.
Maybe it should be www.damnbiglinux.org. This is even bigger than the default install of Debian was a few years ago, and that's saying something.
When I heard the name 'damn small' , I envisaged something that is well under 1.44Mb (the size of a floppy), so it would actually be useful for systems with limited resource. If I want a 50Mb version I can just go and get any popular distro and not install Xwindows and development stuff.
Fool! Repeat after me.
Why is this a story? Seriously... This is pure BS. You KNOW tomorrow will come and go and nothing will ha
[NO CARRIER]
checkauth("scriptkiddie", "who needs arrays?");
I'm sure there's a Russell's Paradox in there somewhere, but I can't think of it just now..
It would be good to see these in the shoes of the "50km walk" participants, to detect cheating. TV cameras repeatedly show snapshots of people with both feet in the air (the regulations of the sport are that you must have 1 in contact with the ground at all times). I predict that if this technology came through, the race times would increase by 15%
From the site's FAQ:
Q: Why is keyboard based reader support so primitive?
A: Keyboard based readers, while cheap and easy to interface, have several problems. First off, The reader simply decodes each track that is present, from 1 to 3, appending each track to the next. No dividing characters are used, so it very difficult to detrimine where the decode for 1 track ends and the next begins. Not being able to reliably seperate the track data means we can't analyze it using our card database. For now, Keyboard based readers work best with cards that only have 1 track.
The keyboard-based reader I have, has dip-switches on it so you can put start and end markers around each track, and select which track you want. Sounds like the guy hasn't done much research on available card readers (or available card writers).
Also, the mag card format is an ISO standard so it isn't as if there is any mysterious behaviour going on here (apart from the non-standard card he mentioned).
Finally, in case anyone was under the wrong impression, having a mag card writer doesn't mean you can break anyone's bank account (bank cards don't contain security information). The worst you could do would be to copy someone else's card for a building security system, then rob it and try and blame the other guy (somehow I don't think this would be too successful).
Ah well. Fun while it lasted. Time to dig out the Spectrum vs C64 vs Beeb flamewars of the school playground...
:)
The flamewars of the few square metres of school playground beside the library doors, you mean
In your opinion. There's plenty of people who disagree (perhaps even, more who disagree than agree).
Hype is for shitty products that would fall over without it. Eg. MS Windows. How many of us had heard of DOOM 1 before someone chucked us a few floppies? None I'll bet. But it is now one of the alltime classics.
It sure did.
(Note, don't actually buy this book, it is the worst piece of drek ever committed to paper)
You called soviet russia back..
I'm glad you said that! I thought it was just me. Once the excitement of being able to write a socket-using application in 5 minutes wore off, and the hours of fiddling and adjusting to fix all the little unexpected behaviours set in (not to mention the entire rewrite each time a new PHP version comes out), it sucks.
3 cheers for C++ and portability and reliable behaviour. Now if only there was a good sockets library..
I was replying to an AC, maybe it's below your threshold. He said "int main() is invalid, it should be int main(int argc, char **argv)". Obviously implying that it should not be int main(void) either.
I was pointing out that int main(void) is valid and equally preferable to the longer version, in the eyes of the standard (in the eyes of me, the short version is preferable if you do not intend to use commandline arguments).
Maybe you should read the specs.
int main(void) is valid in C and C++.
Including stdio.h and calling printf (not std::printf) is valid in C++, although it is deprecated.
Using C library functions instead of streams is entirely valid, too.
Calling exit() and returning from 'main' are exactly equivalent. 0, EXIT_SUCCESS, and EXIT_FAILURE must be supported, and 0 must indicate success to the host environment (although it doesn't have to be the same as EXIT_SUCCESS). Otherwise the system doesn't conform to the C standard (for hosted environments).
(See ISO 9899:1999 7.20.4.1#5 and 5.1.2.2.3#1)
In C, main must be either:
int main(void)
or
int main(int argc, char *argv[])
or equivalent. (See ISO 9899:1999 5.1.2.2.1 for a definition of 'equivalent').
Since yours is different, your program's behaviour is undefined (ie. a bug).
FWIW, your version says that main takes an unspecified number of arguments of unspecified type, cf. the following correct program:
int x();
int main(void)
{
return x(0);
}
int x(int y) { return y; }