SitePoint Sponsor

User Tag List

Results 1 to 10 of 10
  1. #1
    SitePoint Wizard Dean C's Avatar
    Join Date
    Mar 2003
    Location
    England, UK
    Posts
    2,906
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Simulating threading

    Hi folks,

    At the moment I'm working on a fairly large project involving a Player Vs CPU game. This is how the game should work:


    1. Player A makes a move via AJAX
    2. Server tells the player if their move was successful, and Player A's display is updated
    3. It is then the CPU's turn to make their move. This is a fairly resource intensive process and make take 5-10 seconds. When the CPU is ready to make their move it leaves a notification in an inbox for Player A.
    4. Player A, pings the server every 10s to see if they have any new messages in their inbox. Upon picking up a new message, their client is updated.


    The problem with this methodology is that I want to return whether a players move is successful or not straight away, and then fire off another process in the background. If I were to do the following the client would sit their waiting until the process_CPU_move() were complete:

    PHP Code:
    echo $players_response;
    $game->process_CPU_move(); 
    I suppose one way to to get around this would be to flush the output, but I presume the AJAX request would sit there running until the CPU's move was done. Essentially what I'm trying to do is fire off the CPU's processing at the same time as sending the players response, but in the background.

    Any ideas on how I can approach this problem ?

  2. #2
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's an idea. Don't use PHP :3. PHP is not an ideal solution to your problem. Realistically, you want to bypass apache completely because it will be far too slow. You might want to consider using python or better yet C++.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  3. #3
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    Here's an idea. Don't use PHP :3. PHP is not an ideal solution to your problem.
    What? Game programming is basically the poster child for dynamic languages. Php is a good choice - Especially if you know it already.

    Quote Originally Posted by imaginethis View Post
    Realistically, you want to bypass apache completely because it will be far too slow.
    How does Apache make php slower? And why do you think that you need Apache to run php? I'm confused.

    Quote Originally Posted by imaginethis View Post
    You might want to consider using python or better yet C++.
    C++ and Python are pretty much at opposite end of the language spectrum. Since you don't say which attributes of these languages that you find essential to the problem at hand, I can't really comment much on that. Expect perhaps that Python and php are very similar, and C++ is a bad choice for the problem domain.

    Quote Originally Posted by Dean C View Post
    Any ideas on how I can approach this problem ?
    Have a processing script run in the background - either as a daemon or as a cronjob. You frontend scripts can talk to the client in one of two ways:

    One is to use a pull-strategy; Let a javascript create a request back to the server and ask if there are any updates. Repeat this with a few seconds between. This is the simplest solution, so you'll probably start with this. It's also fairly inefficient though.

    The other option is to use a push strategy. Since it's usually not feasible to establish a connection from server to client, you can use a technique known as "comet". The idea is that the client makes a request to the server (as with a pull strategy), but the server doesn't respond immediately. Instead, it waits until there is something new to send back to the client - Then it completes the request. Not only does this reduce the number of futile requests, but it also allows for a more responsive application, because the request will complete immediately when there is something new happening. You don't have to change anything at the client side to introduce this, so you can add it on later.

  4. #4
    SitePoint Evangelist praetor's Avatar
    Join Date
    Aug 2005
    Posts
    479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you can change the platform (not PHP, maybe for the frontend only though) asp.net (mono) is much better suited for this kind of task. Here's why

    1. You'll have an application (your game) who stays in memory just like a real desktop game, processing requests and Cpu moves.
    1.a. This will save you resources since you can keep in memory what's required for the game to work.
    1.b. you'll need db only to persist changes, savepoints

    2. .net supports multithreading without any problems

    3. you can still use mysql/postgres

    4. Linq - to Objects, toXml - (no mono afaik) will make your life MUCH easier.

    5. Of course, it's compiled code vs interpreted

    1+4+5 will make your game perform much faster since the things you need are already in memory (in the application) so you'll hit the db much less.

  5. #5
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    How does Apache make php slower
    Slower by comparison. If all you want to do is send a string to a server and get a response Apache is simply a semaphore.

    Quote Originally Posted by kyberfabrikken View Post
    And why do you think that you need Apache to run php? I'm confused.
    Why would you use PHP without Apache? Now I'm confused...

    Quote Originally Posted by kyberfabrikken View Post
    C++ and Python are pretty much at opposite end of the language spectrum. Since you don't say which attributes of these languages that you find essential to the problem at hand, I can't really comment much on that.
    It was more a response to the OP's Thread title "simulating threading". Since you can thread in C++ and python, specifically stackless python, they would be better suited for the job, if threading is what he wants.

    Quote Originally Posted by kyberfabrikken View Post
    Expect perhaps that Python and php are very similar, and C++ is a bad choice for the problem domain.
    How exactly is C++ a bad choice?

    I must say though, the only game programming I've ever done was in C++, so I might some what slanted.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  6. #6
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    It was more a response to the OP's Thread title "simulating threading". Since you can thread in C++ and python, specifically stackless python, they would be better suited for the job, if threading is what he wants.
    Ah .. That's what you meant. I ignored the title and assumed that what the OP wanted was a background task, since that's what he described.
    If indeed he needs threading, then php is obviously not a possibility, and Python is a good candidate.

    Quote Originally Posted by imaginethis View Post
    Slower by comparison. If all you want to do is send a string to a server and get a response Apache is simply a semaphore.
    But Apache handles the http-interaction. Once it gives control to php, there is no overhead. If you want to talk over http, then Apache is pretty much as good as it gets. If you want to implement the backend in a different language, you would still need a webserver in front - most likely Apache anyway.

    Quote Originally Posted by imaginethis View Post
    Why would you use PHP without Apache? Now I'm confused...
    To run a background task. You wouldn't use mod_php for this, but rather the cli version of php.

    Quote Originally Posted by imaginethis View Post
    How exactly is C++ a bad choice?

    I must say though, the only game programming I've ever done was in C++, so I might some what slanted.
    I'll take a wild swing here and assume that your game rendered graphics of some kind? In that case, C++ is probably a good choice. For things like keeping track of a world and ai stuff, I would much prefer a higher level language. Perhaps php isn't the best language for these things either, but C++ is a way complicated tool. Unless you really master it, you can do much more damage than good.

  7. #7
    SitePoint Addict reboltutorial's Avatar
    Join Date
    Jan 2009
    Posts
    309
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Maybe you could use this for php:
    http://www.sics.se/~adam/phpstack/

    As for me I would use PHP as front end and Rebol, Java or .Net as Backend.

  8. #8
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dean C View Post
    The problem with this methodology is that I want to return whether a players move is successful or not straight away, and then fire off another process in the background.
    Your main problem here is that you're dealing with Web here, which is stateless. Most briefly, you need to make two requests -- one to return the result of the player's move and the other to initiate the server move process. You can do it simultaneously from Javascript, hoping that the first one will return before the second one; but nothing guarantees that happening.

    The better option is that you fire your first request, display the results and only then fire off the second one.

  9. #9
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    But Apache handles the http-interaction. Once it gives control to php, there is no overhead. If you want to talk over http, then Apache is pretty much as good as it gets. If you want to implement the backend in a different language, you would still need a webserver in front - most likely Apache anyway.
    True, HTTP is stateless. I wouldn't want to use it for data dissemination if I were building a game. But if it's a web based game where the client is built in javascript, I don't know if you have any other viable options. I guess its something to look into.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  10. #10
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP does not have multi threading, you can fake it by running a new instance of the script every time you need to, and let the OS multi thread it, but then you pay the overhead of starting your app up for every "thread", with might make it slower.

    Your approach can't really work...

    You need to do something like this:

    Part A
    -----------------
    - Use your AJAX like your using it now (untill you decide to use sockets for the communication and fit 100 times the players per server than ajax)
    - When the player made their move, add an entry in a queue table that will let your server know that the player made his move.
    -----------------

    At this point you have the "client" part done. Users can do their moves, and let the server do his magic.
    Also, since you have that queue, you can use anything to calculate the response.
    Also, since the CPU moves are heavy, you can't keep them on the same machine as the player's requests (you need a good CPU machine for the AI, and a webserver for the players)


    Part B
    -----------------
    You have a script to read that queue, and for each entry in the queue, do the magic.
    This script would work like this:
    - Read queue table record that is "opened".
    - Update queue table record to "processing".
    - Process the data.
    - Delete the queue record that was just processed.
    This script could be working 24/7 (in an endless loop, with a sleep in there)
    OR
    You can run it every minute via a cronjob (it could have an endless loop in there and keep it running for 1-2 min)
    -----------------

    Once your done with part B, if you see that your CPU/RAM is not used, and need to process the data faster, you could use Perl to process your data.
    (You can code pretty much like php with it, and it supports multi-threading)


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •