There are a lot of examples of implementing a TCP/IP-WS stack in all kinds of languages, also in PHP/CLI. But that is not what I'm looking for.
For http protocol there is Apache webserver software. It listens on default http port 80 for incoming requests. On shared hosting servers it can host an array of domain names and the incoming request url is mapped to the right served directory/file in the "hostAccountDir/domainName/docRoot/".
In this model each PHP script is a "specialized HTTP/application level" server; and does not need to invent/implement the TCP/IP-HTTP stack. Fortunately Apache does that for all PHP scripts.
Is there such a thing for Websockets, listening on port 9000(?), forking to the served directory/file... etc?
Apache powers more than 70% of websites today, but new alternatives are gaining market share. Apache is a reliable server, but it takes considerable memory to run. In some situations other web servers can perform better. The best-known alternative open source HTTP servers are lighttpd, nginx, and Cherokee.
PHP-FPM can listen on multiple sockets. It also listen on Unix sockets, or TCP sockets.
nginx is an HTTP server and mail proxy server. It has been running for more than two years on many heavily loaded Russian sites, and it has become more popular in the rest of the world, to the point where today it’s used by 6.5% of all websites.
For more details refer to the links below.
https://serversforhackers.com/video/php-fpm-configuration-the-listen-directive
https://linuxaria.com/article/apache-alternatives-for-serving-php
Related
Let me clarify
I played with phpwebsockets and see that it requires a websocket server to run forever/constantly to keep the states etc in the memory is there any way to run websockets when there is no way of running a server on the server side?
You can used a hosted realtime service, such as Pusher who I work for. Here's comprehensive list of realtime hosted services.
There will always have to be a server of some sort listening constantly. For example, HTTP traffic is delivered by a web server (Apache, Nginx, Lighttpd, etc.) that is running constantly.
It is possible for a web server to spawn a new PHP based process, then hand the client's connection over to the new process. However, none of the major web servers currently do this, and the paradigm for web server modules that route WebSocket traffic is to send the connection over to an existing, constantly running server.
You would have to write your own custom web server in order to keep from running a WebSocket server constantly... and then, really, what's the point, since you're still writing your own constantly running server?
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
I have Apache server serving several PHP driven websites. I'm developing a websites in Python/Pyramid and want to host it on the same server. What options do I have available?
You have mod_wsgi, and you have running it as a separate daemon on a different port or interface.
Apacehe and mod_wsgi
Nginx and gunicorn
These are the two ways I've done it in the past.
I am experimenting with several languages (Python, Ruby...), and I would like to know if there is a way to optimize my Apache Server to load
certain modules only in certain VirtualHost, for instance:
http://myapp1 <- just with Ruby support
http://myapp2 <- just with Python support
http://myapp3 <- just with Php support
...
Thanks.
Each Apache worker loads every module, so it's not possible to do within Apache itself.
What you need to do is move your language modules to processes external to Apache workers.
This is done for your languages with the following modules:
PHP: mod_fastcgi. More info: Apache+Chroot+FastCGI.
Python: mod_wsgi in daemon mode.
Ruby: passenger/mod_rack
I dont think thats possible as,
The same thread/forked process might be serving pages from different Virtualhosts. So if it has loaded only python, what happens when it needs to serve ruby?
For reason 1, certain directives are web server only, and not virtualhost specific. MaxRequestsPerChild, LoadModule etc are such.
I think the only way is to have a "proxy" web server that dispatches requests to the real servers ...
The proxy server has a list of domain names -> Server Side language, and does nothing else but transparently redirecting to the correct real server
There are N real server, each one with a specific configuration and a single language supported and loaded ... each server will listen on a different port of course and eventually only on the loopback device
Apache mod_proxy should do the job
My 2 cents
My Idea is several apache processes (each one with different config) listening on different addresses and/or ports and a http proxy (squid or apache) in the front redirecting to respective server. This has a possible added advantage of caching.
I'm trying to implement a socket server that will run in most shared PHP hosting.
The requirements are that the Socket server can be installed, started and stopped from PHP automatically without the user doing anything. It doesn't matter what language the socket server is written in, as long as it will run on the majority of shared hosting globally.
Currently, I've written a Socket Server with PHP that implements an Object Cache:
http://code.google.com/p/php-object-cache/
source: http://code.google.com/p/php-object-cache/source/browse/trunk/socket.class.php
However, PHP has to be compiled with sockets support, and not many servers run with PHP sockets support.
My real question is: What language should I implement the socket server in, and have maximum platform support and be invokable from within PHP.
In other words, what scripting language is the most common on PHP enabled Servers?
Or do I have to write the socket server in a compiled language to have it works across all servers?
Lets leave IIS out of the picture at the moment, just Linux servers. I don't think many PHP sites are running on IIS...
edit:
Sorry I think my question is not clear.
I'd like to know, what languages is best suited for creating a socket server given the following requirements:
The language must exist in shared hosting, alongside PHP running in Apache (not CLI).
The sockets support must be enabled natively, not via a required extension.
PHP must be able to write the deamon to file as well as start and stop the deamon.
I'm not asking for a solution for a single server. It has to run natively on the majority of shared hosting servers.
Any server can be stopped or started by PHP under Linux. Of course, if you are running a server which accepts sockets from the internet, then you can just connect directly to the server and tell it to shutdown. No need to go via PHP!
As for "starting a server from PHP", well, under Linux, anything can be started from pretty much anything. Just shell out to start the process and have it drop into daemon mode.
I'm a Perl fan myself. Not surprisingly, there's a
Perl Daemon library available.
If your hosting provider offers Perl script support, then you probably have permission to use "system" or backticks command. Then you can very likely start a daemon. However, you will need to use a non-privileged port (over 1024). Also, you should ASK THEM FIRST! They may not appreciate you tying up ports on their server. This is very definitely something you should discuss with your hosting provider.
It really depends on what the install requirements are. Often the easiest and most standard way to write a socket server is to write an inet.d service. This is a standard daemon on my unix machines, and it will fork a process and handle the socket level details. If you want your service to run on port below 1024 on Unix, this is one of the easier ways to get it done. However, the initial install requires root to configure inet.d.
If you shared hosting allows PHP to do an exec call, then you could start the daemon that way. Keep in mind though, it'll need to run above port 1024. You next need to decide if your program is going to be multi-threaded or multi-process. Typically Java programs are multi-threaded, while an Apache instance is normally multi-process.
Lastly, the host may have a firewall in place. This helps prevent shared hosting accounts from becoming part of a bot-net. If the firewall rules don't allow connections to other ports, you won't be able to connect to it remotely.