Protocol rfc

Intro

The constraints on our system:

• Fast
• Secure
• Easily accessible for third parties to build clients around

Here we'll examine a Poker protocol by means of bots on IRC. We will refer to it as pokprot.

• Fast. IRC is a very barebones simple protocol.
• Secure.
  • Years of IRC networks has hardened the protocol against many attacks which you'd otherwise get by rolling your own protocol.
  • IRC has SSL support.
• Easy to implement.
  • You can find lots of basic tutorials on the IRC protocol. There are many clients for this popular protocol.
  • Our protocol is visible in any common IRC client exposing the workings.

Prerequisite

Server-side dependencies may include IRCd, python and iroffer (XDCC software).

Notice: This is subject to change as gamerbot and dealerbot will soon be merged in the spec.

The user configures their Poker client like any IRC software but with the added options for pokprot. We will use example names for reference here.

• Game listing channel: #gamelist
• Game listing bot: gamerbot
• Dealer bot: dealerbot

Connecting from the Poker client software

1. The user in the poker software now connects to irc.MyPokerServer.net through IRC. Network authentication is unimportant since IRC specifies no single method for logging in, and servers vary widely (Freenode sets +e on IDENTed users for example).
2. Client auto-joins #gamelist
3. gamerbot resides on that channel and is announcing new games starting up, and games shutting down (i.e no players seated). The client is storing these changes.

# format is listed below, example on last line
# newgame    table/chan-name   UNIX-timestamp   user-defined-string   NL|PL|L/cash|tourney   num-seats(2 - 10 only)    SB  BB  ante minBB maxBB
dealerbot> #jonathon 1288572618 "come join us donks and play!" nlcash 6 2 5 0.1 50 250

4. To get the remaining list of games running, the client must initiate an XDCC request to dealerbot.

genjix> /msg gamerbot xdcc send #1

This file contains a listing of all running games in the same format as the announcements above. Receiving a 5000 line text file took XDCC 6 seconds on Rizon.net.

#blaablaa 1289000022 "sdjkdsk" plcash 10 1 2 0 20 80
#game3  1289000010 "our game lol" ltourney  (... not yet undefined)
... and so on

For now we are only concerned with NL cash games. The API will solely focus on them with a view to later extending to NL SNGs, NL MTTs, PLO cash. 5. Player can authenticate with gamerbot by /msg gamerbot identify password

All channel interaction with bots is done as though we were interacting with shell programs taking GNU-style options. A command has required options (comand fails otherwise) and optional arguments.

# interaction with gamerbot
genjix> @help
genjix> @somecommand requiredA requiredB -s 10 --optional abc
# interaction with dealerbot

A game-type (nlcash, plotourney, ..) is a template loaded by dealerbot when running the game. In terms of implementation it is a script that runs the game.

class TemplateScript:
    def addPlayer(self, player):
    # ...

The template actions are all the actions that a user can do in their client (open the table, buyin, ...). The overrided methods give responses that the bot should execute in the channel. Before creating a new table, the script will evaluate the input passed from gamerbot.

1. Player registers new game with gamerbot
2. gamerbot checks game type exists.
3. Verifies validity of arguments.
4. Instructs dealerbot to start a new game in that channel.
5. dealerbot joins the channel.
6. dealerbot constructs new GameTypeScript and announces success to gamerbot
7. gamerbot publicly announces game in the channel.

... When a player buys in, the money is deducted from dealerbot.

Action at the Tables

dealerbot is responsible for chaperoning the players. Messages are sent to the channel in the form a JSON. JSON's were chosen for the ability to convey lots of info in an easily accessible manner while not being excessively verbose (take note Xml). The class of action taken is indicated by the existence of one unique key in the JSON. Each different action must always have one unique key for indicating it's type.

{
    "fold": []
    "call": [50]
    "raise": [90, 500]
    "sitout": []
}

That's a typical JSON request for a player action. We know it's prompting for player action by the unique existence of "fold", "call", and "raise" keys which don't exist in any other action types. Conversely "sitout" is non-unique and can exist in other types (like posting blinds).