We have a web application that currently uses polling to handle continuous updates.
While switching to long polling may be a small bandaid to the issue, we wanted to implement a Websockets solution that will be durable and scalable.
My question is: what kind of architecture will be needed for this?
I have done some research myself and have found that the typical setup for an enterprise application is something like this:
The execution flow of a connection then would be something like this:
Initial handshake
Client makes an HTTP Request to Server along with JS to request a Websocket connection
Server responds, Header contains the Upgrade directive and switches protocols for that client
Websocket Server establishes a Websocket connection with client
Client submits a POST/PUT/etc.
Webserver (Apache/Nginx) fetches result from query
Webserver sends result to the MQ where it is added to the queue
Message is sent to Websocket server from MQ
Message is sent back to the client
Is this approach correct? Am I missing anything? Am I understanding something incorrectly?
Try having a look at this: socketo.me
Kinda gives you an idea. From what I can see, this is fairly similar to what you've envisioned in the architecture diagram you posted.
May also be worth looking at this Stackoverflow question's answer.
Have you tried GOS WebSocketBundle ?
I'have used it on production site to handle chat and along with stunnel it works flawlessly over SSL.
Related
For a new project I need to implement remote desktop protocols. The addresses of the remote need to be secured and may never get sent to the client. After a lot of research and some tests I found Guacamole, which also has a Java client. The project is designed as an API though, so I started porting some bits of the Java client example to PHP.
The use case will be the following:
User logs into my service (Laravel application)
WebSocket connection establishes to a constantly running PHP script (using HOA\WebSocket)
Upon authorization a TCP socket needs to be established to the Guacamole Daemon
Commands coming via WebSocket need to be directed to the Guacamole Daemon and vice versa
What makes this complicated is the fact that the application needs to be able to serve multiple clients simultaneously. Multiple TCP sockets need to be established and multiple WebSocket connections need to be managed all at once.
For my simple test I opened the socket via fsockopen and then looped to wait for data. With this I obviously can't listen to multiple sockets at once (at least realistically), but I stumbled upon the React Socket Client library:
Think of this library as an async version of fsockopen() or stream_socket_client().
This sounds like it is what I need, but then again, I'm using HOA and its WeSocket server, which apparently also runs in a loop (when invoking WebsocketConnectionHandler->run()).
Should I even be using React's Socket Client or should I try to use HOA's Socket library instead (seeing as I'm already using WebSocket from that)? Are React and HOA even compatible in their event loop, so could I listen to WebSocket clients and a TCP connection at the same time?
If so, could anyone give me some hints or examples on how to get started with coupling these two? Thanks!
I have an application written in VB.net that runs on a clients pc.
I also have a website written in mostly javascript, http and php.
The thing I want to do is to connect the website to the application, so that when i.e. a certain button is pressed, it connects to the client application and raises an event.
I have tried approaches like TCP socket communication by having a TCP Socket Server running in the background of the client application. I can connect to the server by having a client connection from another vb.net application, but whenever I try to connect through PHP it fails. (I have only tried PHP since server-side scripting seems to make more sense in this case)
Another approach I have tried is to have an HTTP server running in the background of my desktop application and then have a PHP script connect to it, that fails as well.
One thing that I've been thinking about as a last resort is to simply have a textfile on the webserver and a PHP script writing to it after given parameters and then have the client application to read the file every few seconds. But this wouldn't be very efficient with larger amounts of data, would it?
What is the proper way of doing this?
If you have any questions about the code I've been using, feel free to ask.
If you don't get my blurry explanation, try this image: http://i.imgur.com/8njxVFj.png
Thanks in advance.
To have your data more organized i would suggest you to store your data on a database server for example mysql (which is free).
I'm currently developing a PHP application that is going to use websockets for client-server communication. I've heard numerous times that PHP shouldn't be used for server applications because of the lack of threading mechanisms, its memory-management (cyclic references) or the unhandy socket library.
So far, everything is working quite well. I'm using phpws as the websocket library and the Doctrine DBAL to access different database systems; PHP is version 5.3.8 . The server should serve a maximum of 30 clients. Yet especially in the last days I've read several articles stating the ineffectiveness of PHP for long running applications.
Now I'm not aware whether I should continue using websockets with PHP or rebuild the entire serverside application. I've tried Python with Socket.IO, though I did not get the results I expected.
I guess I have the following options:
Keep everything as it is.
Make the application use Ajax in combination with Socket.IO - e.g. run a serverside script that invokes the client's ajax calls when data is submitted to the server.
The last point sounds quite interesting, though it would require some work .. Would it be a problem for servers to execute all the clients requests at one time?
What would you recommend? Is the problem with PHP's memory management (I'm using gc_collect each time a client sends data to the server) still valid? Are there other reasons beside the obvious reasons (no threading, ...) for not using PHP as a server?
You can try running your socket.io on a node server on another port on your server (that is if you are not using a hosting plan like goDaddy).
I am using it and the performances are really satisfying.
I have an apache server on the port 80 serving my php files, and my server-client communications are done using a Node.js server running socket.io on the port 8080 (dev) or 843 (prod).
Node.js is really light and has great performance, but you need to run it as a server. Nodejitsu.com is a hosting solution that has the websocket protocol available and is on beta, so it is still free for now. Just note that you need to listen on the port 80 with socket.io, this is a limitation from theyr network.
If you want your pages all to be accessed on the port 80 then you will need a reverse proxy like varnish .
I hope that helps! Have a nice day.
Are there other reasons beside the obvious reasons (no threading, ...)
for not using PHP as a server?
Yep, lots of socketfunctions are incompatible with each other and it's a hell to debug.
i tried something similar myself and quit frustrated sind every function i thought would make sense didnt do what i expected
I have searched it in Google and here in stackoverflow there are some questions about it.
The problem is that many of them are old, so I guess that they use older and deprecated protocols instead of RFC 6455. I don't know if it is because of that or if I am doing something wrong, but when I try it it doesn't work.
So...
If I understand well, I can implement Websockets with aproppiate client (Javascript) and server (PHP) code, without needing to configure my Apache server. I am right?
Why the hell all examples I have found require me to go to command line and do
php -q C:\path\to\file\Websocket\Server.php
In the implementations I have found, there are a default server and port. Must I change them to the server (localhost) and port which I use for normal webpages? Or should I tell my server to listen to another port and use it for websocket communication?
Where can I find a good PHP implementation of Websockets (RFC 6455)?
Yes, that is correct.
Because the Websocket server doesn't use your web daemon to serve data. In this case, you're writing a server daemon completely in PHP.
You need to choose a port, since you're not using the web daemon to serve your websockets. Any port that's not in use will do.
Try Ratchet (main site here). We've been using the dev-master branch for a couple months in production now and we haven't had any problems. It's the only solution we found that out of the box will work with both Firefox clients and iPhones.
I used to have a small chat app(which was almost working), that uses PHP, jQuery and MySQL. The volume of users is very small (only my friends uses it). I used long polling method for this.
And now, I am thinking about using HTML5 Websockets for this, because it is a lot more efficient. And also most of my friends are using Google Chrome(which already supports HTML5). I have gone through some tutorials that talks about HTML5 websockets. And I have downloaded the phpWebSocket from github. I have gone through the code. But the readme file says that the PHP page that listens to incoming connections should be run using "PHP -q" from commandline. So, I have searched what this "q" flag would do. And I found that it runs the page in quiet mode. So, when I run this in quiet mode what is happened ? It would run endlessly ? Will this running process affect the system resources ?
This PHP page should run the entire time. Then only the connections could be accepted. Isn't it ?
I am having a shared hosting package with HostGator. And they allow cron jobs too. And my present chat app(that uses long polling method) inserts all the messages to database. When the user polls, it would search for any new messages from the database and then output them (if any).
So, I am bit stuck here. :(
It should be run from the command line because as you suspected, it is intended to run endlessly. It binds to a socket on the server and listens for incoming connections. It can't be reliably run from the browser.
The "-q" option tells it not to output any browser headers such as X-Powered-By: PHP or Content-Type: text/html
It will consume as much memory as PHP requires as long as its running. Your memory footprint on startup with no clients will vary between configurations. The more connected clients, the more cpu, memory and socket descriptors you will use. It uses select so it is efficient socket handling.
Also, since you're on shared hosting, you probably won't be able to use it because your user will most likely not have the ability to bind to a port and listen for connections.
As you can see in the demo, the URL to connect the WebSocket to is ws://localhost:12345/websocket/server.php. Unless you have a webserver capable of using WebSockets, you will have to run something like phpWebSocket that acts as a server and listens on a port other than 80.
Hope that helps.
The shared hosting package for HostGator does not allow clients to bind to local ports for incoming. This might be part of the problem.
http://support.hostgator.com/articles/pre-sales-policies/socket-connections