I want to build a game in AS3 and do most of the logic in PHP/MySQL since I'm more experienced in PHP than in any other language that was recommended for it like JAVA.
I've read a lot about that PHP is not a good option for a PHP socket server. The main reason was that it will not manage to handle more than about 1000 clients.
But I never found a good reply why actually it is like that? Is the PHP process crashing after it? Is it an option to set up for example 2 socket servers on different ports? Will it handle about 2000 clients then? Or still not?
If you know AS, I would actually recommend either Java or Node, actually. AS3 is very similar to both Java and JavaScript (some differences), which would make the conversion pretty painless. The magic you have to decide on is how many messages go through each of your clients per second.
If the load is light, prefer Node. If the load is heavy, prefer Java.
If, however, you want to stick to PHP, you will need multiple game instances running from CLI (NOT from Apache). You can then connect to them through standard sockets in any way you like. This is easy to do.
The hard bit is to synchronize all the instances. You can do so by having them all connect to an instance that is solely dedicated to relaying messages to the servers, or have them connect between each other. Game comms theory books and tutorials will come in handy on how to do this.
Your other issues will be, if using PHP, amongst others:
The socket connection limit per daemon
Single-threaded nature of PHP
Caching
Building an evented multi-client socket interface from something that, inherently, does not have this
PHP is at a severe disadvantage compared to Java on this. It is, however, possible.
Related
I've been "recruited" so to speak to help work on a web project that is currently written in PHP with an Apache server. We would like to integrate a real-time (or at least something very close to it) chat feature. Scalability is a definite concern, and this type of work is definitely not my typical.
Everything I've read about creating such a chat feature requires the use of "long-polling" so the servers don't get rapidly overloaded and, well, crash. PHP and Apache are not conducive to implementing such a feature, so I've explored some alternatives, like Twisted Python for example.
The website has roughly ~7,000 lines of PHP (i.e., it'd pretty difficult to just straight switch languages for the entire thing), so my question is how can I manage this situation as far as trying to integrate python and setting up a separate server? Or, is this a very bad way to do this? Are there other alternatives that would be better suited? (Sadly many of the PHP Comet, or even AJAX, solutions I've found don't scale in the slightest. Note, the Apache server is not necessarily required; however, any server used must work with PHP and Python etc, short of having separate servers.)
Thanks for the help!
I would use Tornado on the server to write the chat application. Client server communication can then be over websockets. If you use SockJS on the client side you can also support older browsers via long polling. There are plenty of example chat clients written using Tornado. It's very simple to get started and it is wonderfully scalable. A chat server like this can be serving thousands of clients without showing any appreciable CPU activity.
This is an example, possibly a bit over engineered https://github.com/diggidanne/websocket-chat/blob/master/server.py
I have seen it mentioned in various places around the internet that HTML5 websockets do not work well with PHP, that PHP by it's nature is just suitable for use with them. On the other hand, I see multiple tutorials on using PHP with websockets and Ive noticed some PHP websocket implementation such as http://code.google.com/p/phpwebsocket/
So does anyone have any definitive information on using websockets with PHP. Are they usable with PHP, what are the advantages/disadvantages of using them with PHP as opposed to Java or Python, and why have I read numerous people saying they don't work well together?
The problem is that WebSockets are designed for long running threads/processes which each maintain multiple event-driven connections, whereas PHP (and it's Apache cohort) was designed around the short-lived single process procedural paradigm (eg. max_execution_time is commonly set to 30 seconds, and the session is single threaded).
That's not to say that it's impossible to write a WebSockets server implementation in PHP. I'm aware of at least one project exists that has done exactly this (but note, even this example gets run from the command line, not through mod_php). But it is likely that the PHP implementation of WebSockets is incompatible with the setup of the cheap/shared hosting where PHP is most commonly used.
So while it's possible to it in PHP, you end up having to run a separate server process (from Apache) anyway, and if you're on the sort of hosting that allows separate server processes then it's easier to write WebSockets code in something which is designed for event-driven programming.
If you're not planning to serve tens of thousands of concurrent duplex connections then it's likely you'd be better off using a combination of AJAX and SSE with your PHP back-end.
I recently tried phpwebsocket and it doesn't work at this time (php 5.4 and chrome) the code refers to a secondkey in the handshake that doesn't exist in rev. 13 of the websocket protocol I don't have the time to read the RFC to understand what's the matter.
It's sure that this solution is more elegant and reactive than AJAX with long polling but websockets are not stable at this time I think it would be more interesting to wait that the w3c announce it stable.
I have been searching Google for a while, but the problem I am running into is I am not exactly sure what it is I need to be searching for. (Searching for PHP C++ communication doesn't seem to be what I need) I am basically developing a c++ plugin for a game server, and I would like to create a web interface that can pass/pull data to and from the C++ plugin. The game already uses an RCON port for remote administrative access, but I stumbled across a header for the Network interface they use, so I assume I could use this.
My problem is I am not very familiar with using sockets. I assume I will basically need to open a socket in C++ and leave it listening, and then in the PHP, connect to that socket, pass the data, and close it.
Here is the interface...
http://www.ampaste.net/m2f6b6dbc
I am mostly just going to be pulling information like current list of connected players, names, and scores. And passing commands to restart the server, shut it down, etc.
Any help would be great, thanks!
You could try Thrift. It was written by the engineers at Facebook, and it's now an Apache project.
Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml.
Link: http://incubator.apache.org/thrift/
In a nutshell it does exactly what you're trying to do. It makes it easy for different languages to communicate with each other. Rather than trying to come up with some socket based protocol for communication, you can call a function in PHP like this:
$game->getScores();
And it automatically plugs into a function named getScores in your C/C++ program. The only drawback is it can be a bit of a pain to configure correctly.
I'd dare to recommend to use some standard means of distributed components communication, for example, XML RPC. There are libraries for both PHP and C++: http://en.wikipedia.org/wiki/XML-RPC#Implementations
This approach will keep you from reinventing the wheel during communication protocol implementation, and will make further maintenance cheaper.
I assume I will basically need to open a socket in C++ and leave it listening
err, yes, that's the description I'd give to my 12 year-old daughter - but if you're going to have more than one client connecting its a bit more involved. Especially if you are bolting the code onto an existing server. So have a read of the socket programming FAQ.
You do need to define a protocol of how data will be represented when travelling across the socket. THere are lots of 'standard methods - but sometimes things like CORBA / SOAP etc can just be overkill and more effort than starting from scratch.
If you are bolting code ontp an existing server, life will be a lot simpler if you use the current socket and extend the protocol if necessary.
There are 3 models for writing a socket server - the code snippet you provided does not seem to include details of which you are currently working with:
forking server (may split threads rather than processes)
single-threaded server
socketless server
forking server
An instance of the server is started (call it p1), calling setsid()
p1 starts listening on the relevant socket
a client tries to connect
p1 forks to create p2
p2 then accepts the connection and starts conversing with the client
p1 continues to listen for further connections
p2 exits when the connection closes
There are variations of this - p2 may accept further connections, p1 might fork prior to a connection coming in)
single-threaded
An instance of the server is started, calling setsid()
it starts listening for a connection, and creates an array of the sockets in use (including the initial one)
socket_select() is used to identify activity from any of the sockets
when a client connects, the connection is accepted and added to an array of connections
whenever socket_select() returns activity on one of the sockets, the server generaets an appropriate response / closes the socket / binds the new connection
socketless server
some process (e.g. inetd) handles all the socket stuff
when a client connects, this other server starts an instance of your program and binds the socket I/O to the STDIN/STDOUT of your program
when your program exits, the other process closes the socket (if its still open) and handles the clean up (e.g. if it is implemented as a forking server, then the spawned process may end)
What it appears you want to google is C++ client / server. There are two approaches I could suggest here.
First, would be to make a very basic HTTP protocol server so that your php script can simply go to http://yourip/ and send your commands through the POST variables. You can find an example of a C++ Web Server at: https://stackoverflow.com/questions/175507/c-c-web-server-library
The second approach which allows a lot more flexibility is make up your own basic protocol and use PHP's SOCKETS to connect to the server and send commands. You can find an example of a C++ client / server application at http://www.codeproject.com/KB/IP/client_server_socket.aspx. Keep in mind, for the C++ end, you are only concerned about the Server part. You can find a basic PING client in PHP, using sockets, at the following URL: http://www.planet-source-code.com/vb/scripts/ShowCode.asp?lngWId=8&txtCodeId=1786. There are also classes out there to handle most of the protocol part, though I am not aware of any that work for both languages.
Please note I have not tested any of the codes I linked to. I simply found them on google.
A good place to start would be http://php.net/manual/en/book.sockets.php.
Basically, you're going to create another remote administration port and method for PHP to connect. Naturally, if your going to only be accepting web communication from one IP, that's a good way to secure it (check and allow access to only the one IP which will connect). However, you will need the C++ server to listen on a (secure?) port and have PHP connect to it (as long as host allows it).
So overall, if you already have a server running, this should be simple from the C++ side. All you need to do from the PHP side is really research connecting to different servers and passing information along (which PHP is more than capable of doing efficiently)
But, this is obviously an alternative to the poster up 2. I personally enjoy (in many cases) "reinventing the wheel" so to speak as to be able to manage my own work. But of course, that is not always efficient by cost or otherwise.
Good luck!
So I am thinking about creating a multiplayer game and I was wanting to use php because I already have a php server. Is it possible to make a socket server that will be able to handle a actionscript multiplayer game. The game won't be big. so we wont need any huge amount of data pushing through. just some software that is probably reliable enough to run a multiplayer game.
PHP is clearly not a solution when it comes to socket server. It's simply not meant for that kind of usage.
If you really want to go multiplayer, SmartFox ( http://www.smartfoxserver.com/) offers a professional solution when it comes to Flash. After that developing a small socket server in a proper language is not that complicated, and the possibility are endless (Python, Java, C#, C, C++, Erlang, Go, Erlang, ...). It really depends on what kind of game you're want to do.
PHP could be eligible as a solution in case of turn by turn type game, you could simply handle it as a RESTful service (sending back and forward the game state by http).
You could use PHP, but I wouldn't recommend it. In addition you will need a shell on your server and the ability to execute custom servers, since the PHP socket server will not be running from inside the webserver (Apache etc).
I would recommend one of the many realtime communication servers available for Flash, such as Wowza, ElectroServer, Union, or others (just google for them)
There are some free ones available too, but the quality may not be as good. Some examples I found with a 30 second google serach, I know nothing about them: Oregano, GFS, Palabre
You could use Red5. It's an open source Java implementation of a Flash Media Server that allows for what you want to do:
http://osflash.org/red5
I'm working on a project that involves a database (My SQL), website (PHP) and a custom high performance server application (C++). The C++ application (and its accompanying client application) make up the main bulk of the project, with the database storing long term data for it. The website is primarily for displaying various statistics, and administration.
1) I want the PHP scripts and c++ application to be able to communicate in some way, since the database is only used for persistent data, and additionally the c++ application may cache some things so needs to be told to reload the data in some cases. It is highly likely they will be on different machines, and even possibly different OS's. I've been considering the idea that TCP may be the best option with some simple command - response protocol?
2) What is the best way to write the common database interface code once, and be able to use it from both the PHP website and the c++ applications?
1) Use the database to communicate. The C++ application can
select * from table where some_last_modified_timestamp > '<last time checked>';
2) Use stored procedures in preference to hardcoded queries both in PHP and C++.
You might try not allowing PHP to access the database at all. Make the C++ app do all the database work, and make it serve data to the PHP site. You could run part of the C++ app as a server for the PHP to fetch reports etc from it.
#1: If you're on different OSes, then TCP sounds like a decent idea.
#2: Sounds like you need a C library, and then call that from both C++ (trivial) and PHP. A search on Google returns lots of articles about writing PHP extensions in C, for example:
http://devzone.zend.com/article/1021
http://www.devarticles.com/c/a/Cplusplus/Developing-Custom-PHP-Extensions-Part-1/
1) I would also suggest TCP. Depending on the complexity of request-response I'd probably pick either some ad-hoc text protocol or use XML (especially suitable if responses or requests are structured and more complex). If you use XML you won't need to write your own parsers/generators. You could even try using XML-RPC but I have no practical experience with that yet.
Best way to use the same SQL in both PHP and C++ is prepared statements.
A good way to communicate is for one to host a server (custom/soap/rest) which the other connects to. PHP can easily both host and connect, and since that code is written in C it should be easy in C++ too.
Writing a PHP extension like Eric Seppanen suggest is way beyond the scope and need of your project Id say.
Use Thrift or Protobufs (possibly Avro) to declare a communication protocol and use that over a tcp socket. It'll solve your cross language problems without having to roll a custom protocol, and you end up with actual objects on both sides (statically typed for c++!). I've seen Thrift used like this very successfully.
My approach is to use SWIG. I use it with python, but it supports PHP also.
Then it's very easy to use it from your script.
Other solutions could be some RPC (wich would allow to have the server and the PHP application in different places).
I am a beginner here, so please excuse if my idea is terribly bad.
But why cant we just transfer XML over TCP. Have a C++ TCP server and PHP TCP Client. I think PHP has a pretty powerful socket APIs