oops there's a typo in there.
"manager servers" -> "managed servers"

to clarify, the tournament organizer launches a cloud service
instantiated in multiple countries.  this could be a separate web
service.

the managed "edge" servers, each of which appears to clients like
the main tournament server, talk between each other using a
protocol that does lag math, like timeseal (but not needing its
secrecy).  a "central" master tounament server collects
responses, and understands the pseudo-timeseal well enough to
assign time correctly.

clients are responsible for lag between themselves and the
nearest edge server.  there is no recourse for dropout, crashing,
or disconnect, when it occurs between the client and the managed
server.

changes would be required to existing systems.  clients must
trust the time reported by the edge servers.  the central server
must have some protocol for working with time math between it and
the edge servers.

On Tue, Feb 3, 2009 at 12:57 PM, Ryan Grant <rgr...@rgrant.org> wrote:
> 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 implementing timeseal.  edge cloud
> points are now available, and this would be a small matter of
> programming.
>
> thanks for opening the thread Nick, and thanks Ian for pointing the
> way to an answer.
>
> On Tue, Feb 3, 2009 at 10:16 AM, Ian Osgood <i...@quirkster.com> wrote:
>>
>> On Feb 3, 2009, at 8:34 AM, Heikki Levanto wrote:
>>
>>> On Tue, Feb 03, 2009 at 10:41:53AM +0000, 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 know that they would;  but providers of
>>>> chess servers have been able to prevent cheating.  As I understand it,
>>>> their clients perform CRC checks on themselves to ensure that they have
>>>> not been hacked, and the packets they send are CRC-checked by the server
>>>> to ensure that the packets have not been hacked.
>>>
>>> Sorry, I don't buy that. It may work with an audience of human players who
>>> are not good programmers. But for a person who is already writing a
>>> go-playing program, and the whole time management in it, adding what ever
>>> cheats sounds trivial.
>>>
>>> Besides, this would add an extra layer of complexity to be programmed,
>>> with
>>> new chances for mistakes.
>>>
>>> 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.
>>>
>>>  - Heikki
>>>    who admittedly doesn't even have a functional program at the moment
>>>
>>>
>>> --
>>> Heikki Levanto   "In Murphy We Turst"     heikki (at) lsd (dot) dk
>>
>> Perhaps you misunderstand how this is implemented for the chess servers.
>>  The server authors themselves provide the client authentication service. It
>> acts as a filter between any go client and remote server. On ICS, this was
>> called "timeseal".  Instead of your go client connecting to the server
>> directly, it connects via pipe or local socket to timeseal, and timeseal
>> makes the authenticated connection to the remote server. In the past, this
>> timeseal component was distributed as an opaque binary for various hosts as
>> a means of hampering reverse engineering.
>>
>> In other words, the burden is on the Go server author to implement both the
>> client and server sides of the timeseal protocol. Individual Go program
>> authors simply download the timeseal client and configure their program to
>> connect to it. No extra coding required.
>>
>> 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.
>>
>> Ian
>>
>> _______________________________________________
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>
>
>
> --
> - Ryan
>



-- 
- Ryan
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Reply via email to