Life In 19x19

yakcyll wrote:

atarihuana wrote:i think they should first clarify what caused the timeout. i think it would help to adress the general problem with such situations apart from this specific occaision.

This is the most difficult part of the whole ordeal - since it was a transient error in network transmission, there's no proof of what happened other than Mateusz's and the proctor's statements.

No proof of what happened?

Pardon my ignorance, by why doesn't the software record the time between receipt of the opponent's move from the server and the time the player's move is submitted? Net lag has always been with us, so I would have thought that for timed events the local time taken would be the proper record.

Marcel Grünauer wrote:

Bill Spight wrote:Pardon my ignorance, by why doesn't the software record the time between receipt of the opponent's move from the server and the time the player's move is submitted? Net lag has always been with us, so I would have thought that for timed events the local time taken would be the proper record.

Presumably for the same reason that they don't use the client's timestamp to begin with: It's possible to forge the timestamp. Although it would take quite a bit of effort to forge it and it probably would not be worth it in the context of a game. So maybe KGS considers the server to be the single point of truth and if a client has a problem, then so be it.

Because KGS was written 20 years ago by 1 guy as a hobby, rather than as a serious piece of software for business critical real time operations. And as Marcel says there's a question of trust between server and client so it's not trivial.

I would like to add a couple of facts to this discussion. First, Eric never resigned, that rumor simply needs to end.

Second, the people in the room with the players are NOT referees, they are proctors. They have two jobs - first, to observe the player and make certain no help of any kind AI or otherwise is happening, and to keep the communication open with the broadcast team. The proctor was NOT instructed to monitor any lag issues or to make any refereeing decisions outside of that mandate.

HKA wrote:Second, the people in the room with the players are NOT referees, they are proctors. They have two jobs - first, to observe the player and make certain no help of any kind AI or otherwise is happening, and to keep the communication open with the broadcast team. The proctor was NOT instructed to monitor any lag issues or to make any refereeing decisions outside of that mandate.

well do you trust the proctor to be true to his word on his job? if yes, it doesn't matter if it was his job to monitor lag issues. there are 3 possibilities:

he saw mateusz time out because he forgot about time while reading: eric wins on time.
he saw mateusz try to play the move in time, but for what ever reason the move did not register: continue playing the game.
he can not in good faith confirm either of the cases. thats the tough case. as sad as it is, you would have to give eric the timewin, unless the parties agree upon another compromise.

notice he is not makeing a refereeing decision here: he is reporting to the tournament officials what happend and they make the decision. and i repeat again: it is important to swallow the pill in this special case and strictly seperate it from the general case for future handling of such matters.

Marcel Grünauer wrote:

Bill Spight wrote:Pardon my ignorance, by why doesn't the software record the time between receipt of the opponent's move from the server and the time the player's move is submitted? Net lag has always been with us, so I would have thought that for timed events the local time taken would be the proper record.

Presumably for the same reason that they don't use the client's timestamp to begin with: It's possible to forge the timestamp. Although it would take quite a bit of effort to forge it and it probably would not be worth it in the context of a game. So maybe KGS considers the server to be the single point of truth and if a client has a problem, then so be it.

I'm not talking about KGS, I'm talking about the tournament organizers.

HKA wrote:Second, the people in the room with the players are NOT referees, they are proctors. They have two jobs - first, to observe the player and make certain no help of any kind AI or otherwise is happening, and to keep the communication open with the broadcast team. The proctor was NOT instructed to monitor any lag issues or to make any refereeing decisions outside of that mandate.

Oh, but making sure that the local timestamp is not forged would fall under the heading of making sure that no help of any kind is happening.

Bill Spight wrote:

HKA wrote:Second, the people in the room with the players are NOT referees, they are proctors. They have two jobs - first, to observe the player and make certain no help of any kind AI or otherwise is happening, and to keep the communication open with the broadcast team. The proctor was NOT instructed to monitor any lag issues or to make any refereeing decisions outside of that mandate.

Oh, but making sure that the local timestamp is not forged would fall under the heading of making sure that no help of any kind is happening.

Truth be told, you could reduce the possibility of tampering with this mechanism, by introducing a procedure of delivering a trusted client onto a trusted system inside a virtual machine or something along these lines, to an "acceptable" margin; whatever "acceptable" means is another matter, but whatever words we would use to define it, one of them would be some form of "practical". However, this would require: a) a custom trusted client, b) a trusted source, c) a trusted system and a trusted machine (in case of a virtual machine, it's a matter of transmitting an image from the trusted source to the player, possibly along with the client). All these points add some technical difficulty into the mix, but when we're talking about a professional grade tournament, a bit of technical preparation beforehand won't hurt. Of course, this won't truly and clearly prevent timestamp cheating (without getting into details, the evil maid is always an inherent threat), but here we can go back to the pre-established definition of "acceptable".

If some new client software for KGS was devised now, it would surely draw from the experiences in network protocol design of popular gaming titles, old and new, which had and have to make sure not necessarily that everybody sees the same thing at once, but that eventually everybody will see the same thing, regardless of network quality, and the moments of inconsistencies will not lead to desynchronizations. After all, the server is the ultimate authority here and if inconsistencies do arise, it's much easier to enforce corrective or punitive action.

As a German I say "was für eine verfickte Scheiße, der Rotz geht einem echt nur auf den Sack", I won´t translate, but all can be sure, it doesn´t show any happiness.
I think every participant should have a camera in the on his monitor, keyboard and mouse, so all can see, if he did something or not.

Nethertheless is there a decision already? I didn´t hear anything, but first it was said we should look today. In the end, even if it´s decision against Mateusz, we could know, which pairing is next and we are still ahead in the EGF.

If go clients work in a different way this sort of problem would not happen.
IE if time was counted locally, starting from receive of opponent's move, and ending upon playing of your move. On this way, all lag and delay would not be counted on player's time.
Also adjusting byoyomi reading style would be useful.

I know that some might say that someone vozld use flaw in this system, and disconnect from internet in order to get more thinking time on opponent's turn, but it is easy to monitor such activity.

I don't understand what the fuss is all about. Mateuz was clearly ahead, there were what 10 moves, basically dame remaining? And he claims he played with a 10 sec margin. Give him the win already and next time plan more carefully the tournament.

I think we probably all agree that in a game played with clocks it should be possible to lose on time (e.g. it is late endgame and despite being safely ahead you get lost in thought trying to find the optimal semedori so you win by 11 not 10 points and don't play in time), but also that in some situations the clock can be overruled (e.g. there is a power cut at your home so you disappear from the internet for 10 minutes, or do strict time limits people think this should also be a loss?). The question is where does this situation (assuming we believe Mateusz's statement) of playing before the end of the period in local time but network troubles meaning it gets to the server too late lie on that spectrum?

Also something to bear in mind for those unfamiliar with KGS's handling of disonnects and lag: if you purposefully close your game window whilst still having a good connection then the clock pauses until you rejoin the game (and you are marked as an 'escaper'). So a conscious decision to leave the game and attend to a family emergency for example will not result in a time loss so long as you remember to close the game first. However, if network lag delays the transmission of your move (made before clock ends) to the server (arriving after clock ends) then you lose on time. However, there is a complication in that the KGS server appears to periodically/randomly poll the client for connectivity and if it finds the connection has dropped then you can enter the paused clock and marked as escaper state. I have not managed to reverse engineer the exact rules for this process, but is entirely plausible that it did not happen in the ~10 seconds window of Mateusz's case (it sometimes takes minutes in my experience).

dsatkas wrote:I don't understand what the fuss is all about. Mateuz was clearly ahead, there were what 10 moves, basically dame remaining? And he claims he played with a 10 sec margin. Give him the win already and next time plan more carefully the tournament.

The problem is not so much for this game, but for future games if disconnections occur earlier. Clear rules have to be written.

I think this comes down to whether we believe Mateusz’s statement. If he ran out of time, it should be his loss. If we believe that he played in time, but lag prevented the move, it seems appropriate to resume the game from that position.

I’m saying this, because when I asked about the rules for this tournament, I saw that there was a time limit, but no information about lag. So in the future, we should specifically define the rules for apparent lag.

Kirby wrote:I think this comes down to whether we believe Mateusz’s statement. If he ran out of time, it should be his loss. If we believe that he played in time, but lag prevented the move, it seems appropriate to resume the game from that position.

I’m saying this, because when I asked about the rules for this tournament, I saw that there was a time limit, but no information about lag. So in the future, we should specifically define the rules for apparent lag.

i believe Mateusz wholeheartedly, but i think the opposite.

if there is no specific rule about lag or disconnection in place, i think the cleanest solution is to accept the loss (unless Eric wants to decline his victory). and afterwards to put in place quite any rule concerning future similar scenarios. and as much as i like KGS, to consider if it is the best venue for this event. because according to KGS, Mateusz just lost on time, like any other player any other time. as far as i am aware, there are not even means to easily resume the game there if the referees decide to do so.