Security and resource restrictions

This forum is for all things Hold 'Em, including bot strategy, bug reports, and anything else.

7/8/2011 6:21:16 AM
View user profile for Jeroen
Total Posts 3

Security and resource restrictions

In the documentation on the Hold 'Em competition, some security and resource restrictions are mentioned, for instance memory restrictions and execution time restrictions. However i can't seem to find any mention of the actual numbers. How much memory is the maximum allowed, and how long per turn can the bot execute before being terminated?

Also, is it possible to make webservice calls from the Bot? I don't think the security restrictions would prohibit it, but i can imagine the box running the games might not have full internet access.

7/8/2011 1:36:14 PM
View user profile for Ed Kaim
Total Posts 35

Re: Security and resource restrictions

We’re still fine-tuning the details of resource restrictions, but for the Hold ‘Em competition they’re currently set at:

  1. Your constructor must complete within 1 second. We don’t recommend you do anything beyond controlled initialization in there since this is purely to get your bot up and running.
  2. Your bot gets a matchup lifetime allotment of 10 world seconds of execution time of your code, which is the sum of all the times the GetBet methods are called for your bot. For example, you could spend 9 seconds on any given call as long as all your remaining calls use less than 1 second of world time. Also note that these are “world seconds” and are unrelated to your CPU usage during those seconds. The actual amount of execution cycles will vary based on CPU and other system resources, but we haven’t standardized on hardware, so there’s no guaranteed minimum. However, all bots in a given matchup run on the same hardware.
  3. There is an off-turn execution tolerance of 100 milliseconds of CPU time. This simply means that your bot should not be executing when it’s not your turn. The primary scenario for this is if you’ve spawned a thread that continues to use cycles after you return from GetBet. Unfortunately, sometimes there is a little extra CPU usage beyond the control of the bot due to the CLI, so we provide this tolerance, which is more than anything we’ve seen arise in testing.
  4. Your bot gets a lifetime RAM allocation allotment of 100MB per bot. It’s critical to understand that this is an “allocation” allotment and not a straight-up “allotment”. That means that every time you allocate memory it adds to your total, regardless of what memory has been released. Based on our use of AppDomains to isolate bots, the only metric we have to work with is the total number of bytes allocated over the course of the bot’s AppDomain’s lifetime. We don’t have any way to get a pure snapshot of how much RAM your bot is using on its own, or even how to separate the RAM allocated by your bot vs. the other things in the AppDomain that might be allocating their own. We picked the 100MB limit for Hold ‘Em as a ceiling high enough that it would detect bots trying to hog memory as a tactic while still giving plenty of space for legit bots to compete.

These resource restrictions are not intended to make it hard to write a good bot, but rather to cut off malbots that get stuck in loops, sleep for long periods, hog memory, etc. If there’s a reasonable case for expanding any of these, please let us know and we’ll do our best to keep things fair.

As for the permissions sandbox, we only include the Execute permission for bot AppDomains. There isn’t really a good explanation of what’s included in this permission except that it allows for everything that doesn’t require additional permissions. For example, accessing the network for Web service calls would require additional permissions, so that functionality is unavailable. Since the documentation isn’t always thorough regarding what permissions are required, the easiest way to test your bot is to run it in the Windows test client, which includes the same permission set as the production tournament environment.

We're very open to any feedback on these restrictions, so please let us know. Also, if you're aware of a security risk or other issue that impacts competition quality, please don't hesitate to post or email us at support@finalbot.com.

7/10/2011 2:05:58 PM
View user profile for Jeroen
Total Posts 3

Re: Security and resource restrictions

Thanks for the detailed explanation Ed. I seem to have come across a bug in the test client of some sort. When creating an odd calculation algorithm, i seemed to be getting TimedOut problems for my bot. At first the algorithm was indeed way too slow and not fitting into 10 seconds for even one call. But now i dumbed it down a bit and it completes far faster, easily under a second. But still the TimedOut message appears in the test client log files the very first time the algorithm gets called.

Is it possible the test client shows this message for any other reason?

7/10/2011 2:38:44 PM
View user profile for Ed Kaim
Total Posts 35

Re: Security and resource restrictions

TimedOut shows up when the bot times out or the engine thinks it has violated one of the resource restrictions. If the time elapsed before the TimedOut occurs is clearly less than 10 seconds of execution, then it’s almost surely due to a resource issue. If it seems like the engine is being too aggressive and you have some code we could use to repro, feel free to send it over to support@finalbot.com and we’ll look into it. It doesn’t need to be your bot’s logic, but even something generic that triggers the TimedOut.