Image Image Image




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: XML - Specification Idea
PostPosted: Mon Nov 05, 2007 6:55 am 
Offline
New member
User avatar

Posts: 1
Favourite Bot: My own
Quote:
Each request message of the protocol provides all information available to the frontend about the current poker hand [This has to be defined in details, as part of the working group]:
* Session ID (64 bits)
* Game description (String, any optional information)
* Game type
* Game ID
* Bet size / Limits
* Button
* Position (of the "hero" - the player to act)
* Number of players
* For each player: Player name and bankroll at start of the hand
* Hero's hole cards
* Community cards (Flop, Turn, River cards)
* List of Actions since the beginning of the hand (each action in the list contains Player Name, Action Type and Action Amount


From what you say I gather You want to draft a spec for transferring information about poker any type of poker.

Perhaps you should consider XML as debated http://forumserver.twoplustwo.com/showf ... art=2&vc=1
using a similar XML scheme to what many programs are going to use for saving hand histories for analysis has other benefits also obviously.

eg you would receive this:

Code:
<session sessioncode="225295281">
- <general>
<nickname>lolourgay</nickname>
<gametype>Holdem NL 1/2</gametype>
<tablename>Sand Pit (6 max)</tablename>
<bets>$678.7</bets>
<wins>$790.78</wins>
<duration>01:43</duration>
<gamecount>147</gamecount>
<chipsin>200</chipsin>
<chipsout>312.08</chipsout>
<startdate>2007-01-02 10:44:32</startdate>
<ipoints>505.25</ipoints>
</general>
- <game gamecode="468785388">
- <general>
<startdate>2007-01-02 10:47:42</startdate>
- <players>
<player seat="1" name="tribaciNP" chips="$138.7" dealer="0" win="$0" bet="$1" />
<player seat="3" name="lolourgay" chips="$200" dealer="0" win="$0" bet="$2" />
<player seat="5" name="piedeljere" chips="$181.98" dealer="0" win="$8.65" bet="$4" />
<player seat="6" name="Agalont" chips="$399.08" dealer="0" win="$0" bet="$2" />
<player seat="8" name="didier68" chips="$234.25" dealer="0" win="$0" bet="$0" />
<player seat="10" name="Tjocksomfan" chips="$168" dealer="1" win="$0" bet="$0" />
</players>
</general>
- <round no="0">
<action no="1" player="tribaciNP" type="1" sum="$1" />
<action no="2" player="lolourgay" type="2" sum="$2" />


and respond with

Code:
<action type="fold" />


All modern languages have XML parsers. So that would also help.


Top
 Profile E-mail  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Mon Nov 05, 2007 10:50 am 
Offline
Junior member
User avatar

Posts: 21
XML is the 'flavour of the decade' for information transfer. It makes a lot of sense to use it.

Regards
M.


Top
 Profile E-mail  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Mon Nov 05, 2007 11:18 am 
Offline
PokerAI fellow
User avatar

Posts: 7731
Favourite Bot: V12
OK, this is a good question.

You are absolutely right about the value of XML for interoperabillity.
I have however several concerns here:

1) Performance (as usual)
Do you guys think this is a valid concern? I'm thinking about the backend (bot). How much such load can come over there? Eventually, if there is too much load (so that the protocol overhead is visible) this will mean a lot of money already for the botter (so not really a concern).
On the other hand, this has applications beyond "bot as a service" idea (when I was pushed to think of). For other applications (like web site front end offering free or very cheap service, hence working with not so good backends), or even bot-fight, having a 3rd party digital dealer, this may cause some overhead.
The straightforward argumentation is that the time the AI will take for a decision is usually much higher than the performance overhead of the protocol.

2) Complexity
Now this is again arguable.
XML is well known, there are parsers existings, I think in java that's no problem but i wonder about the C/C++ space.
Having some opensource whuser.dll that supports the protocol would be very important for it's adoption, and my concern is if switching to XML will make this (and such implementations in general) more complex.

3) Obfuscation
Obviously, XML is much easier to read than a binary protocol. This is another minor concern, as if someone does network spoofing, he would be able to handle both binary and XML protocol the same

This is a fundamental topic to decide on: going for binary, or XML protocol.

Obviously, choosing a binary protocol will allow mapping to XML (i.e. you may have binary to XML mapper, but this would be language dependant, hence will not make a lot of sense, as you'll directly use the available APIs).

I very slightly tend to vote for a binary protocol, for all of the above (minor) reasons plus some more, e.g. that the backend bot developer will in many cases work with some established de-facto strandard language specific APIs (hence for him the protocol itself might not be visible).

But I would leave this open for discussion (for now), feel free to express your opinion. If we reach a vivid community working on this, where topics are discussed extensively and reliably we can also switch to some voting.

This is however one of the most important things to decide faster, so that it allow to start the actual specification work (the only more important thing except that is eventually expanding on all concepts that need clarification).

_________________
indiana


Top
 Profile E-mail  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Mon Nov 05, 2007 12:39 pm 
Offline
Senior member
User avatar

Posts: 247
I'm voting for a binary one. But I wouldn't have any problems (or significant performance loss) adapting to XML.

Concerning obfuscation: Any thoughts about some kind of encryption? What ever the protocol uses binary or XML at least I wouldn't feel very comfortable sending away my holecards with an unencrypted protocol.


Top
 Profile E-mail  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Mon Nov 26, 2007 1:12 pm 
Offline
Regular member
User avatar

Posts: 85
I know .net has some built in security for transferring xml.
I can provide one of my last semester's projects which was to demonstrate transferring XML to a webservice use DES encryption. It's dead simple to do in .net


Top
 Profile E-mail  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Mon Jan 07, 2008 10:07 am 
Offline
Regular member
User avatar

Posts: 74
Favourite Bot: ...
With regards to binary vs XML, have a look at Fast Infoset, which is binary encoding for XML.

It's meant to be faster and smaller than plain XML. It's already implemented in Java, has open source C/C++ versions, C# (Commercial), and I believe Delphi (who cares, lol).

-acidie

_________________
I'm back... well almost, no, no I'm gone again.
I'm in ya shitz, haxoring ya boxz!
Nothing is secure, everything is permitted.


Top
 Profile  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Thu May 15, 2008 6:19 am 
Offline
Junior member
User avatar

Posts: 13
Favourite Bot: None for now
Very interesting initiative. I would vote for XML.

1) Performance
Not much of a concern IMO. The load will not be on the parsing or request handling but more on the AI. The Protocol / AI load ratio would be pretty low in most cases. I guess it depends on how data is updated too: continuous stream of events / chunks of cached data until a decision is needed...

2) Complexity
Parsers already exist in most, if not all languages. C/C++ has xerces from the Apache project. A binary protocol would make unrecoverable errors much more likely. With XML we benefit from easy debugging and hand crafting of test data among others advantages.

3) Obfuscation
Well chosen word :) I don't belive in obfuscation. Either we make a very complicated binary protocol and it will be as obfuscated for us than for any potential attacker, or we make a plain readable protocol and use it over SSL. Easy to implement too, it is widespread as it is needed for all languages wanting to be able to access HTTPS websites. If you add in the fact that we're talking about an open spec, i definitely don't believe in obfuscation. False sense of security is sometime worse than no security at all.

On a personal note, i'm working on this same problem with my teammate. By chance we landed on exactly the same question independently of this project. Same architecture... We were going to use JSON over HTTP for easy remote control from web interfaces (understand: the browser). XML is just as capable and we would be more than happy to contribute and use this solution. We don't know yet exactly what has to be sent, when, and in which direction, and i'd like to hear your opinions (especially the "which direction" part). If it has been discussed elsewhere on this board don't bother to answer, i havn't read much yet and will find it by myself.

Thanks :)


Top
 Profile E-mail  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Thu May 15, 2008 9:38 pm 
Offline
PokerAI fellow
User avatar

Posts: 808
Favourite Bot: Lego Mindstorms
Hi,

I think I would also vote XML.

My primary reason would be to ensure easy version compatibility. ie we can imagine in the future there may many versions of the protocol in use at once - and we would want to be able to add new features without breaking existing clients or services.

Of course - all thats possible with binary formats if done carefully - but its more natural with an XML format.

- PeppaPig


Top
 Profile  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Wed Jul 09, 2008 1:24 am 
Offline
Senior member
User avatar

Posts: 468
Favourite Bot: Custom
There are some potential performance issues with XML even for "normal" botting. For example let's say that before I made a decision, I want to analyse my last 500 hand histories with each of the players at a full ring table. That means I would have to parse potentially 5000 hand histories per hand per table. Performance could definitely be an issue...which is not to say that XML should not be used...it just depends on the performance hit relative to binary.


Top
 Profile E-mail  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Thu Jul 10, 2008 1:46 pm 
Offline
Senior member
User avatar

Posts: 247
casey999 wrote:
There are some potential performance issues with XML even for "normal" botting. For example let's say that before I made a decision, I want to analyse my last 500 hand histories with each of the players at a full ring table. That means I would have to parse potentially 5000 hand histories per hand per table. Performance could definitely be an issue...which is not to say that XML should not be used...it just depends on the performance hit relative to binary.

XML is only used to transfer the clients current state to the server (the bot). Every hand is transfered once. If you would like to analyse the last 500 hands then that should already be stored in some kind of a database on the server. How you decide to store the hands up to you.


Top
 Profile E-mail  
 
 Post subject: Re: XML - Specification Idea
PostPosted: Sun Jul 20, 2008 4:55 pm 
Offline
PokerAI fellow
User avatar

Posts: 2342
Favourite Bot: My next one
I really think there's a good argument around XML too. CPUtime-wise it's negligeable in 2008, even with a full blown XML parser. XML makes a lot of sense for interoperability and opening the protocol for other variants of the game (Omaha, etc). It also makes development of the communication components quite easy, including debuging.

There's a small overhead (in number of additional bytes) on the network side but that should be negligeable nowadays too anyway. I'm not sure there would be a need to binarying the XML. It could be defined as optional should anyone really require it, yet I'm not sure it would be worth it.

Like Dionysos, I really don't believe in obfuscation. I would go too for SSL encoding of the sockets (should be made optional to make sure ppl can use the protocol too on their local network to build client/server architectures) which has already been tested in many other applications.


Top
 Profile E-mail  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: