Poker/Casino Programming

[kalfu]

I'm going to write some poker software and then probably expand it to general gambling with bitcoins, and I had some general questions which you don't have to be a programmer to answer.  I write in a number of languages, and I'm trying to determine which one I should use. 

PHP/AJAX would be for absolute ease and fast development, while not necessarily being efficient (or arguable robust) which may become a concern if a considerably large amount of people start playing there.  Also, my basic tests so far on local ajax client->server->clients type of events is not that great; it's fairly quick, but not particularly great.

C or C++ would be for speed, both on the server end and the client end.  Everything would be over UDP.  I think it is possible to put http over UDP, and there are probably already some examples or something of that nature that outline this; still, I think if I went that route, I might as well do it in C/C++.  The only reason I have against using native binaries is that it requires installation or at least running of the binary on the system, whereas PHP requires no download -- there is something to be said about ease of use to the end-user.

Last one on my list of candidates is Java (I'd probably write the server in C/C++, though).  I personally am not an advocate of java, but only having to load an applet seems simpler.

If I follow the large poker site's examples, I should just write it as a program and have the user download.  This is where I'm leaning.

Aside from the question of language, I have a question regarding transactions.  I've read somewhere on these forums at one point that I should be 1) backing up the wallet on every transaction (and storing the backups in multiple locations of course), and 2) generate a new wallet for each transaction (not sure if that's correct).  What are your thoughts on this?

Regarding initial deposits, I know it's in the wiki that there could be some sort of escrow service that could allow the user to instantly be credited; lacking that, should I just make the user wait until it's been validated by X keys (excuse me if I am not using the proper bitcoin-centered terminology)?

Thanks for the input.

[bitlotto]

Back up the wallet every so often. And you probably mean generate a new address for each transaction. Although I'm sure you could just make a unique address for each player then you can keep track of money put in by each player.

[malditonuke]

If I follow the large poker site's examples, I should just write it as a program and have the user download.  This is where I'm leaning.

I haven't been making millions off the industry like those large poker sites, but my gut tells me that potential customers would be more willing to try a no-download version, e.g. an in-browser java, html5, or flash setup.  Especially since bitcoin users are less willing to download exe files than the common PC user.

[kalfu]

Back up the wallet every so often. And you probably mean generate a new address for each transaction. Although I'm sure you could just make a unique address for each player then you can keep track of money put in by each player.

Wallets are small enough that I might as well back them up every transaction, but I do like the idea of just using one address per user.

I haven't been making millions off the industry like those large poker sites, but my gut tells me that potential customers would be more willing to try a no-download version, e.g. an in-browser java, html5, or flash setup.  Especially since bitcoin users are less willing to download exe files than the common PC user.

That's my main concern with a binary.  I suppose I could open source it to quell the doubt, but my concern with that is having someone decide to find any flaws in the software (probably will encounter this with it closed, but it's at least not as easy).  My motto on code security is that it is only possible with 0 lines or infinite lines of code (i.e. every possibility possible).

Java may be the best route to go for client speed and ease on the end-user (it does require people to DL java, and personally if a site requires java, I typically just leave).

[theymos]

I hate Java applets. They freeze my browser for a few seconds and screw up the page.

I would prefer AJAX.

[kalfu]

Well, you learn something new everyday.  PHP does have some UDP functionality, although because it's a server side scripting language, I'd still have to figure out a way to have the client's requests not go through the standard http overhead.  I'll figure it out.  malditonuke's response answers my question enough that I know which direction I should probably go in.

[theymos]

Why would you use UDP? It's not going to give you any speed improvements if you're just going to replicate the reliability/stream functionality (which you'll probably need to do). You just need to have all actions go over a single TCP stream so you don't have to keep opening new connections. I don't know if you can do this with Javascript.

PHP can use raw sockets, so you can do anything with it. I wrote a basic Bitcoin network client in PHP.

[Alex Beckenham]

If I follow the large poker site's examples...

...then you'll have your domain seized by the FBI.

http://www.internet-poker.co.uk/Poker-News/Poker-Sites/PokerStars-Site-Shut-Down-by-FBI~4109.html

[kalfu]

Why would you use UDP? It's not going to give you any speed improvements if you're just going to replicate the reliability/stream functionality (which you'll probably need to do). You just need to have all actions go over a single TCP stream so you don't have to keep opening new connections. I don't know if you can do this with Javascript.

PHP can use raw sockets, so you can do anything with it. I wrote a basic Bitcoin network client in PHP.

I understand your point, but I disagree that I'd have to make UDP do all the same things TCP does.  It's easier to send duplicate packets (use more bandwidth without increasing latency) and handle it at the server end.  We're also talking about very small amounts of data.  The client will need very little information to be sent.  I should have mentioned that the deposit and withdraw functionality will be handled in a php website, so we're only talking about basic commands: bet, check, etc + game state updates.  Even with 10 duplicate packets for every packet, the consumed bandwidth would still be minute.  I suppose the problem with that would be for people using tor or jap that have greatly reduced bandwidth and have to get the packets intact through that.

The php sockets idea is a dead-end, since the php socket code/client would have to be run on the user's machine (I doubt people would want to have to install a webserver to run the php).  Of course that would mean the code would have to be open to again address the concern of executing code on the client's machine.  I have not found any method (currently) to do sockets from the client side.  WebSockets (used to be part of HTML5 specs) is something that will eventually be available which can keep a connection between the client and the server; that would need to be finalised and supported by the browsers first, though.

Regardless, I've already decided to do the code in PHP and AJAX.  It's easy, it doesn't require people to do anything except visit the site (with JS enabled, though), and it's probably fast enough.  As you rightly pointed out, the main issue with speed is not the fact that it is TCP but that each action using PHP/Ajax would be a new HTTP request.  Since browsers are built around TCP, perhaps there's a way to use a single TCP connection.  My main concern was the "turn time" or whatever you want to call it and the fluidity of the gaming experience.

...then you'll have your domain seized by the FBI.

http://www.internet-poker.co.uk/Poker-News/Poker-Sites/PokerStars-Site-Shut-Down-by-FBI~4109.html

I did see that post, and I wouldn't put it past them, but I would hope that because it's in a bitcoins that it would be grey enough that they'd tie themselves in red tape.  However, I suppose it's more likely they'd "act first" and then tie me up in red tape

[kalfu]

It seems that the only secure way to do it is with js talking to a java applet: http://sly.w3m.hu/socketjs.  There is a way to do this with flash, but the method seems insecure on the server side; plus, I hate flash and want it to die, which hopefully will happen when HTML5 is widespread.

[fornit]

the main issue with speed is not the fact that it is TCP but that each action using PHP/Ajax would be a new HTTP request.

use websockets and hope that they will be activated in the major browsers soon?

edit: i think trusting the binary is a non-issue with c/c++. the user already trusts you enough to give you some bitcoin. so its very likely that he also trusts you enough not to spread malware.

[FreeMoney]

the main issue with speed is not the fact that it is TCP but that each action using PHP/Ajax would be a new HTTP request.

use websockets and hope that they will be activated in the major browsers soon?

edit: i think trusting the binary is a non-issue with c/c++. the user already trusts you enough to give you some bitcoin. so its very likely that he also trusts you enough not to spread malware.

This is pretty bad logic. People are going to want to try the software before they trust and pay you anything and even then they will start small. There are lots of sites I'd send 5BTC to, but not install their software.

I'm not saying trust can't be built, but it's a process and at least a little harder to get people to download.

[kalfu]

The only most recent version of major browsers that doesn't have Web Sockets is IE9.  I'm pretty sure all other major browsers have support (although I think some need it enabled first).

I most likely will write the server code in C or C++ and have the first version of the client in PHP/Ajax but have the script connect via the PHP socket code.  This way, it'll be easier to add a C++ client down the line as optional for a better experience. 

[Raoul Duke]

Well, you learn something new everyday.  PHP does have some UDP functionality, although because it's a server side scripting language, I'd still have to figure out a way to have the client's requests not go through the standard http overhead.

are you talking about php-cli? http://www.php-cli.com/php-cli-cgi.shtml

[kalfu]

No, I was referring to http://www.php.net/manual/en/function.socket-create.php. 

[Raoul Duke]

No, I was referring to http://www.php.net/manual/en/function.socket-create.php. 

Yes, i understood you, but i think that for what you are looking for you should use php-cli instead of cgi because cli mode doesn't create so much overhead with http headers, etc...

Sorry if you misunderstood what i meant to say. I'm no expert in this, in fact i'm not even a programmer, I'm just a curious guy, nothing more.

[kalfu]

PHP is server side scripting.  CLI (command line interface) is just the ability to run it from the command line.  You could use this to run a console client, but again it falls on having the user install software (they at least need the php client) + run the script on their local machine.  If I choose to encrypt the client code, then they'd have to trust me.

PHP CLI is mostly just for running offline scripts (like perl or bash).  Most people use the PHP apache module.  I'd be running the PHP-FPM and fastcgi on nginx.

Also, I doubt most people would have any interest in playing with a command line poker client.

[Raoul Duke]

PHP is server side scripting.  CLI (command line interface) is just the ability to run it from the command line.  You could use this to run a console client, but again it falls on having the user install software (they at least need the php client) + run the script on their local machine.  If I choose to encrypt the client code, then they'd have to trust me.

PHP CLI is mostly just for running offline scripts (like perl or bash).  Most people use the PHP apache module.  I'd be running the PHP-FPM and fastcgi on nginx.

Also, I doubt most people would have any interest in playing with a command line poker client. <--WTF

By your confused words i can see that you, even being a programmer, know less about php than I do...  
Choose another language! It's for the best...

But yes, you are right, no php/ajax for desktop clients. Use it for the website only, if you can't find something better, ofcourse

[kalfu]

I guess that's some kind of joke?  Hard to determine the difference between sarcasm and sincerity in text.  If there's a serious question in there, I guess just let me know...

[fornit]

The only most recent version of major browsers that doesn't have Web Sockets is IE9.  I'm pretty sure all other major browsers have support (although I think some need it enabled first).

right now its only enabled in chrome and safari afaik

I most likely will write the server code in C or C++ and have the first version of the client in PHP/Ajax but have the script connect via the PHP socket code.  This way, it'll be easier to add a C++ client down the line as optional for a better experience. 

that sounds like a plan.