Darren Cook wrote:
It's just a can of worms to require some proprietary binary that people
have to use, trust, and believe is unhackable.
Reverse-engineering the binary itself to then make your own client is
still a risk, but is a specialist skill beyond most go programmers.
I could most
On Sun, 2009-02-08 at 03:15 +0100, Raymond Wold wrote:
Darren Cook wrote:
It's just a can of worms to require some proprietary binary that people
have to use, trust, and believe is unhackable.
Reverse-engineering the binary itself to then make your own client is
still a risk, but is a
In message 669331.97002...@web39802.mail.mud.yahoo.com, terry mcintyre
terrymcint...@yahoo.com writes
- Original Message
From: Gian-Carlo Pascutto g...@sjeng.org
Heikki Levanto wrote:
No amount on crypto-mumbo-jumbo will solve the problem that the server will
have to trust the
On Tue, 2009-02-03 at 10:41 +, Nick Wedd wrote:
Providers of Go servers claim that it would be pointless to try to
implement client-side time, as players would be able to cheat by hacking
their clients and fiddling with the clock. I don't doubt that they
would try to cheat, indeed I
On Tue, Feb 03, 2009 at 10:41:53AM +, Nick Wedd wrote:
Providers of Go servers claim that it would be pointless to try to
implement client-side time, as players would be able to cheat by hacking
their clients and fiddling with the clock. I don't doubt that they
would try to cheat,
I would not want to discourage remote players - some systems are designed to
take advantage of large supercomputers which are not very portable.
However, remote players need to accept the trade-off. They get to avoid the
trouble of packing up and shipping a trailer full of computer gear to the
if it really mattered, remote participants could
use a phone to connect -- it's not like these
are very high-volume transmissions, and the
latency, while high, is still an unimportant
fraction of total time. on the plus side, the
latency is exact. on the minus side, it's a
pretty expensive phone
On Feb 3, 2009, at 2:34 PM, Heikki Levanto wrote:
All in all, I think this is a messy and unreliable solution to a
problem I
have not seen happening.
For what it is worth I vote against client-side time controls.
Maybe you haven't seen it. That doesn't mean it doesn't exist.
I've lost
On Tue, Feb 03, 2009 at 03:51:14PM -0200, Mark Boon wrote:
On Feb 3, 2009, at 2:34 PM, Heikki Levanto wrote:
All in all, I think this is a messy and unreliable solution to a
problem I
have not seen happening.
For what it is worth I vote against client-side time controls.
Maybe you
In a recent posting I used the phrase client side time. Someone has
asked me what I meant. As well as answering him, I am posting my answer
here, for three reasons: (1) to inform those who do not know, (2) to
invite correction from those who know better than me, (3) as a gentle
nag to any
In message 1233686072.20891.9.ca...@acer-debian, Jeff Nowakowski
j...@dilacero.org writes
On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote:
Frankly, I'm baffled that nobody in the online Go world cares about
network lag. Timeseal has been a mature technology on the chess
servers for over a
@computer-go.org
Sent: Tuesday, February 3, 2009 10:34:32 AM
Subject: Re: [computer-go] time measurement
On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote:
Frankly, I'm baffled that nobody in the online Go world cares about
network lag. Timeseal has been a mature technology on the chess
On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote:
Frankly, I'm baffled that nobody in the online Go world cares about
network lag. Timeseal has been a mature technology on the chess
servers for over a decade.
I logged into FICS today for nostalgia and one of the first thing I see
is
- Original Message
From: Gian-Carlo Pascutto g...@sjeng.org
Heikki Levanto wrote:
No amount on crypto-mumbo-jumbo will solve the problem that the server will
have to trust the program, and its author. Signing can provide some little
assurance that the program running today is
On Tue, 2009-02-03 at 18:54 +, Nick Wedd wrote:
What sort of cheating does he complain about? Does he provide evidence
that it happens?
He couldn't flag his opponent when he ran out of time. Of course this
could just be lag, or maybe he killed his process when he was losing.
Once you
there are two solutions.
first, we have the preferred solution: a real time system.
optimally Fischer time, acceptably Byo-Yomi.
second, the Someone Else's Problem solution: tournament organizers
provide connection points on servers they manage, in multiple
countries, with the manager servers
a slightly simpler protocol:
you let me put a machine on your local network that i control,
and you agree to do an ntp-like service with it.
s.
___
computer-go mailing list
computer-go@computer-go.org
Here is a simple protocol:
email your program to me, and I will test it on my local network :-)
All protocols require some trust somewhere, in this case you must trust
me to test it fairly and not distribute your program in the case that
you want to keep it protected.
- Don
On Tue,
It's just a can of worms to require some proprietary binary that people
have to use, trust, and believe is unhackable.
The SSL connectivity part would be reasonably unhackable. (I.e. if you
happened to have a supercomputer to hand to decode the signal you would
probably want to use it for your
The server could also run traceroute before and during the game to get a
fair idea of what is reasonable net lag for that particular client.
Couldn't traceroute also be used with server-side timekeeping? The server
could credit the player for trusted hops in the traceroute.
Probably only the
On Feb 3, 2009, at 7:08 PM, Darren Cook dar...@dcook.org wrote:
The server could also run traceroute before and during the game to
get a
fair idea of what is reasonable net lag for that particular client.
Couldn't traceroute also be used with server-side timekeeping? The
server could
Heikki Levanto wrote:
No amount on crypto-mumbo-jumbo will solve the problem that the server will
have to trust the program, and its author. Signing can provide some little
assurance that the program running today is the same as was running
yesterday, but that's about all. As long as we can
i like how simple ICMP hacking is.
large trunk lines might be the only ones worth trusting as secure, but
it's a good start.
again, i'd rather move away from absolute time, which i find horrendous.
On Tue, Feb 3, 2009 at 4:21 PM, Jason House jason.james.ho...@gmail.com wrote:
On Feb 3, 2009, at
The server could also run traceroute before and during the game to get a
fair idea of what is reasonable net lag for that particular client.
Couldn't traceroute also be used with server-side timekeeping? The
server could credit the player for trusted hops in the traceroute.
Probably only
: Tuesday, February 3, 2009 10:59:12 AM
Subject: Re: [computer-go] time measurement
This is the timeseal web site:
http://www.unix-ag.uni-kl.de/~chess/soft/timeseal/
Looks like an interesting read.
Terry McIntyre
-- Libertarians Do It With Consent!
- Original Message
25 matches
Mail list logo
