Support for black_listing users

[bihonglu]

This is not really an issue to be reported. It just a code contribution by me on this issue. My bot was invited and played by one user excessively, which I suspect to be an undeclared bot taking off my precious computer resource, I had to resort this to maintain sanity. Here is my code by
diff 2 DGSQBot.pm between mine and your original code:
163c163,167
< if ($self->check_board($m)) {

  if (&black_list($m->sender)) {
  $m->reject_game("reject excessive game invitation");
  $self->message("reject excessive game invitation from " .$m->sender."\n");
  }
        elsif ($self->check_board($m)) {

262a267,286

}

sub black_list {
my $senderid = shift;
my $bool = 0 ;
my %blacklist_hash;
if ( -f "black.lst") {
open (BLACKLST, "black.lst") || die " can not open black list file";
while() {
chomp;
if (/^(\d+)\s*$/) {
my $id = $1;
$blacklist_hash{$id} = 1 ;
}
}
close(BLACKLST);
}
$bool = 1 if ($blacklist_hash{$senderid});

return $bool ;

A file "black.lst" is created to have black_list senderid , one per line to be rejected by bots.

[jug]

Rejecting users with the specific cause "excessive game invitation" would be too specific for a general blacklist. There could be other reasons.

But BTW, if there are excessive invitations this can be controlled in the "board_ok" condition on the field "opp_started_games". For example see https://github.com/yrutschle/DGSLib/blob/master/qrobot line #55:

($_[0]->opp_started_games <= 5) and [...]

It's recommended anyway to restrict the started games with the same opponent to a few games (or 1).

With this condition, the blacklist might not be required ... unless you want to block the user permanently.

I've also hinted to that in the DGS forums: http://www.dragongoserver.net/forum/read.php?forum=6&thread=48798&xterm=opp_started_games#48915

[yrutschle]

I didn't realise there was a flurry of bots on DGS and that some used my code. Cool :-)

I'll have the same objection as Jug on your code though; also if we were to implement a total blacklist, it'd be better to use read_list() (what you're doing is essentially slurping a file to check if something is in it, and we already to this in several instances)

[bihonglu]

I still think at least in my case, black list solution is better solution than <= 5 games limitation. The abuse is mostly bot vs bot, potentially distorting the rating system. Bot vs human is unlikely to cause such waste of resource, I would say even 10 to 20 simultaneous games by human at DGS may still be considered reasonable.

In fact, for my case the opponent actually mostly did not violate 5 maximum simultaneous game limit. I think the vj2303 user is robot, I PM with warning about excessive games and fake resignation with no response many days ago.

For fake resignation distortion caused by a undeclared bot, you can see the rating of redrobot,
the big jump
http://www.dragongoserver.net/ratinggraph.php?uid=97563

from 4 kyu to 1 kyu in a couple of days was caused by fake resignation by vj2303 user.

Excessive game is one matter, faking resignation is another, not sure why. But a black list will solve this.

Cheers,
Shoreline

[yrutschle]

On Mon, Feb 20, 2017 at 12:29:40PM -0800, Hong Lu wrote: I still think at least in my case, black list solution is better solution than <= 5 games limitation.

I did not test this, but why not try to limit to 0 games? That would achieve the same result with no additional code at all.

[bihonglu]

JUG PMed me that he thinks vj2303 is a human player. I never thought it was possible for that kind of heavy player to be human.

Any way, I think my solution is not ideal. The ideal solution would be a restrict list, and impose restriction to a list of users to be limited to certain small manageable amount and still allow human players to play against bots, which are the whole purpose of bot anyway.

I had to do this in last couple of days to free up my resource for a coming a bot, Rayon, or rn-3.9, which is strongest open source AI software today.

[yrutschle]

On Mon, Feb 20, 2017 at 02:06:56PM -0800, Hong Lu wrote: JUG PMed me that he thinks vj2303 is a human player. I never thought it was possible for that kind of heavy player to be human.

Many years ago at the beginnings of my robot (2007?), we had a player that was definitely human who was playing 2000 games at once... I never totally understood how he did that but I suspect a lot of random playing (he was still 25k after finishing thousands of games, which isn't right either).

Any way, I think my solution is not ideal. The ideal solution would be a restrict list, and impose restriction to a list of users to be limited to certain small manageable amount and still allow human players to play against bots, which are the whole purpose of bot anyway.

Well, let's do that then. I'm not clear on the specification: - We want a list of restricted players - What do we restrict? The number of games? The frequency of moves? Both? Y.

[bihonglu]

I would say limit a list of users to have:
games - No more than 20 games
frequency - no more than certain amount , say 20 moves per hour,

The more important restriction is the frequency restriction, which is real burden on resource. I would still place 20 games total as sanity upper limit.

[bihonglu]

I changed my mind on the restriction spec based on past several days of robot operations. There is easier way to manage this the issue using similar idea from jug In fact, I have been using the "new game" restriction feature of DGS and worked well. The restriction should be implemented in this way at DGSlib:
-- Yes, a list of restricted players,
-- no need on restriction of frequency, too much of work, not necessary
-- restriction on total starting games (same used in DGSlib new game SOS[1] in waiting list), only
one game total allowed for the users in the restricted list.

So far, I have observed that with this restriction by using new games invitation, the load on my bots is very manageable by vj2303 user, and the distortion of ranking is also minimal because only one game per user is allowed at one time.

Robot serves two purposes, allowing playing with human, and as anchor for the ranking system in order to avoid rank distortion. My bots did 2nd job very well. In fact we can see that the ranking of vj2303 was dropped suddenly from dan level to 2 kyu to 4 kyu level because of matches with 3 of my robots. My manual checking of game records between bots and vj2303 also let me to believe that the 3 kyu level should be the reasonable fair ranking for him and his previous dan level ranking was distortion. With this restriction on any heavy players, the DGS ranking distortion should also be removed if that person play heavily with bots.

[bihonglu]

All in all, bots impact on whole ranking system has been very positive by my observation. The advantage of DGS ranking system compared to other servers have been strengthened by robots.

Another human player's rank was heavily impacted by my various bots is Kostyan. Kostyan's rank dropped suddenly recently from 2 dan to 5 kyu. In fact, Kostyan never played a game with my bots, only played heavily with vj2303. Because vj2303's rank collapsed due to games with bots, indirectly Kostyan 's dan level rank collapsed by 6 stones. Obviously the dan level rank of Kostyan was not real, was a distortion. The distortion was fixed by mainly bots.

In fact, games among redrobot, vj2303 and greenrobot can illustrate this. vj seemed to be stronger and won more even games against redrobot, while lost more to greenrobot. Their current ranks refect that, redrobot at 7 kyu, vj at 6 kyu, greenrobot at 5 kyu.

[yrutschle]

I totally forgot about this feature request :-)

What we could do is have a configuration file that looks like:

whiterabbit: 5 10
redrabbit: 10 20

whiterabbit is limited to 5 games, 10 moves an hour; redrabbit is limited to 10 games, 20 moves an hour.

Or maybe something a little more explicit:

whiterabbit:
     games: 5
     frequency: 10
redrabbit:
    games: 10
    frequency: 20

which is more verbose but allows for future extension. The syntax here is an example only, I'll go with YAML for file parsing.

The downside of all this is that it requires managing a lot of internal states, so we'll basically need to have some sort of database and add complexity, when currently the bot is very simple and keeps almost no state.