I want to use web sockets rather than Ajax to update a web page . I can’t figure out where to start. Do I need to use Python on the server? How do I integrate this with my existing PHP code? I’ve seen documentation on the API from the Javascript/client side but I don’t even know where to start looking for an example on the server side.
Keep in mind that WebSockets is still highly experimental, and is only supported by a few bleeding-edge browsers.
The second thing to keep in mind is that socket-type programming is completely different from writing a web application. You’ve got a persistent, bidirectional connection to deal with and not the convenient, stateless request/response cycle of HTTP.
The server-side of a web-sockets app is a simple TCP server. You will need to educate yourself on how to write sockets applications, such as by using a select-loop, pre-fork model, etc.
Here is the documentation for Python’s raw socket interface. The Twisted library is supposed to be a pretty good networking library for Python, though I’ve never used it.
Don’t do network programming in PHP if you want to retain your sanity.
ETA: There is also the matter of the WebSockets protocol handshake that has to be implemented by your web server in order to upgrade the connection. An example implementation for Python is the pywebsocket Apache module.
Pay attention to which version of the websocket protocol is being used on each side. There was a new (76) one as of May, and you may have trouble with version incompatibility (76 on the server should in theory be backward compatible with a 75 client, but not vice versa).
Ok, this is beginning to make sense. Basically, I write an application that listens to web sockets and responds. It could then interact with MySQL and thus I can keep my PHP code in sync with the web socket app by sharing the database. Is that right? Or should I have the Python server app use web-based GET/POST to localhost and do the database manipulation in PHP? I used to use sockets in my old Unix programming days, so it won’t be all new to me.
Web sockets are the browser-based alternative to GET/POST etc request/response systems.
Basically, it’s a way to open up a persistent and more low-level connection to a server when you need to. If you don’t need to send data from the server to the client (browser) without the client asking for it, or if your system is running fine right now you probably don’t need it, and you’re just opening up a can of worms for no really good reason.
All the persistence stuff is just icing on the cake.
“It could then interact with MySQL and thus I can keep my PHP code in sync with the web socket app by sharing the database.”
I don’t know what this means, and I suspect you don’t either.
Do you really need to be that obnoxious? I’m not a moron, I’m just learning new stuff after years of writing low-level C code. If you really want to compare dick sizes I’ll match my resume up against yours.
In case you actually want to be useful, I have a PHP-based web application which now uses Ajax initiated POST methods. This works great when the client knows that it needs to get or push data from the server. I don’t want to use Ajax to just poll the server looking for new data, I want to be able to initiate updates from the server. Presumably web sockets is the right method for this. I have a MySQL database that I currently access from my PHP code. This works great for normal refresh or Ajax requests. If I am using a web socket based application on the server I need to share the database with my PHP code. What I was asking is whether it is better to call MySQL from the web socket based application, or have it initiate a request to the local Apache service and continue to do the MySQL access through PHP.
I apologize. That was unnecessarily dickish. I still don’t really understand what you meant, though.
With you so far.
Ah, ok. You want to connect to the database directly via web sockets, right? That’s possible (with a proxy) but AFAICS it won’t really gain you anything. Standard MySQL connections will still only do request/response actions. To do any asynchronous updates, you will probably* have to use some other data sharing system to really make use of this efficiently.
I’m also fairly sure that doing it the way you propose way will be more work, and much less secure than using a PHP server as a mediator (since you can then use PHP as a fully controlled guard. Letting in client connections directly to the database will mean anyone with some experience will be able to mess with the database).
I’d recommend you take a look at some JavaScript and PHP friendly messaging systems/protocols like STOMP (which IIRC has JS and PHP - or at least Ruby, Perl and Python - libraries already written), and try working with that for a bit. It should at least give you some ideas about what a simple asynchronous system can and cannot do. But take note that these systems really don’t seem to match traditional relational databases very well.
- the MySQL cluster solutions can in theory send updates back to peers, and you might, possibly, be able to hack into that for asynchronous communication with the database, but from my limited experiences with MySQL cluster code, I’d really not rely on it. Especially not when you’re dealing with multitudes of clients.
And I apologize as well for my snarky response. I’m still not being clear, I’m afraid. I don’t want the client app to talk directly to the database, I just want software on the server side to do that. I’ve got a good grasp on PHP and accessing MySQL through it, I just haven’t quite figured out how a web socket app written in something like Python fits into the picture. Would I start a service/daemon running on the server, independent from Apache, that communicates to the clients over sockets? If so, I could either have that service access MySQL directly or I could issue local HTTP requests to my PHP code and have it do the queries.
The reason you probably need a separate server for web sockets is that basic apache isn’t really designed to handle long-living connections (though in theory Apache 2 can do this sort of thing, most people I think go for a specialized server that runs either a message queue, like STOMP, or an HTTP/Comet style server that can run against browsers that don’t support Web Sockets).
Taking STOMP as an example, generally you run a generic STOMP server that mediates between the web clients and the server clients. So, both sides only implement a STOMP client, and communication is done over “channels” that either side can subscribe (meaning they get alerted when new messages arrive on that channel) and send messages to.
You can then on the server side translate those messages back into “simple HTTP requests” to PHP, but then the question really becomes; what’s the point? It’s far easier to just do an Ajax request directly to the PHP side.
This sort of thing is most useful if your whole system is based on messaging and you don’t have to query a database to see if any updates need to be spread around. Though I can imagine a system where you’ve got one or a few “update checker” processes that query the database and other systems every X seconds and then sends out those updates to many subscribed clients. That is pretty easy to do with a message queue, and could relieve a lot of load from the web server and the database:
Client 1 <-\
Client 2 <--- subscription <- STOMP server <- update checker <-> database (or PHP page)
Client 3 <-/
Thanks, that’s been really helpful.