I have a websocket server, implemented using PHP's socket library, and all works well... provided you are using the ws:// protocol.
However, we now need to upgrade the library to work over SSL, i.e. to support the wss:// protocol.
Is it possible to implement wss:// (or more generally, I suppose, SSL connections) using the PHP socket functions, or will we need to rewrite the code to use the stream_socket functions?
(Note that there may be other good reasons to switch to stream_socket, so regardless of the answer we may consider doing that anyway. However, before I spend time evaluating the two options, I want to confirm that sticking with socket is even an option for us.)
I'm submitting an answer on behalf of #BA_Webimax who posted what is probably the correct answer in a comment, but hasn't returned to make that into an answer that I can accept.
So as a direct answer to the question "Is it possible?":
It is possible to do but requires you to implement a lot of things that are already done for you when using stream_socket functions.
-- #BA_Webimax
To flesh that out a bit further, it would mean handling all of the SSL negotiation and encryption manually. This would be a fair amount of work, require a lot of testing and runs the risk of introducing security holes if not implemented exactly right.
Rewriting the code to use the stream_socket functions is likely to be quicker, safer and more robust.
So, whilst the technical answer is yes, it is possible, the pragmatic answer is probably no, it is not.
Related
I have a PHP websocket server, written using the socket module (socket_bind(), socket_accept(), socket_recv(), etc.).
It was written and tested and is working well on Linux. However, the implementation needs to be cross-platform.
I have done a quick test running it on Windows, and there were no immediate errors, but I would like a bit more certainty that my implementation is sound rather than just assuming it is OK because I haven't yet spotted any errors (which would be the case even after more in-depth testing, as sockets have a lot of edge-cases).
To what extent do these PHP functions abstract the underlying architecture (Unix sockets vs. Winsock)? For example,
Are there differences in the effect/availability of various flags or options?
Do the error codes differ, and if so is there a way of mapping them across?
Are there architectural differences that mean similar functions may behave differently (e.g. different rules about blocking)?
I'm not looking for a specific analysis of my code, as there is far too much of it, but more for a general idea of what differences I need to be aware of in order to make this code portable.
Note that, for the purposes of this question, I am only really interested in TCP/IP sockets (though more general answers are also fine).
I'm starting to consider websockets as a solution to replace long polling in a new build PHP app I am commissioning.
I have a few questions which I wonder if people could help me out with.
Can a Nodejs server call PHP and if it did wouldn't it suffer the same shortcomings as just going through Apache in terms of the connections? We all know nodejs is non blocking and Apache etc isn't but if Nodejs is just making a call to a PHP server in it's own procedure would that not bottle neck in a similar way?
Are PHP and websockets a good match?
Are there any good js libraries besides socketio which apparently only works with Nodejs?
Has anyone found a good tutorial which uses websockets and a PHP backend maybe using something like that Ratchet PHP library which might help me get on my way?
Thoughts would be muchly appreciated.
Please excuse my paraphrasing of your questions.
1: Can Node.js call PHP, and wouldn't that have the same shortcomings as Apache?
Calling a run-once PHP script will have the same general shortcomings as calling a web page, except that you are removing an extra layer of processing. Apache or any web server itself is such a thin layer that, while you'll save some time, the savings will be insignificant.
If PHP is more effective at gathering data for your clients than Node.js, for whatever reason, then it might be wise to include PHP in your application.
2: Are PHP and WebSockets a good match?
Traditional PHP scripts are normally intended to be run once per request. The vast majority of PHP developers are unfamiliar with event driven development, and PHP itself does not (yet) have support for asynchronous processing.
PHP is a fast, mature scripting language that is only getting faster, even with all of its many warts and shortcomings. (Some say that its weak typing is a shortcoming. Others say that it's a shortcoming that its typing isn't weak enough.)
That said, the minimum that any language needs in order to implement WebSockets is the ability to open up a basic TCP port and listen for requests. For PHP, it is implemented as a thin wrapper around the C sockets library, and there are additional extensions and frameworks available that can also change the feel of working in TCP sockets with PHP.
PHP's garbage collector has also matured. Memory leaks come either from gross disregard for the memory space (I'm looking at you, Zend Framework) or from intentional sabotage of the garbage collection system by developers who think they're clever or want to prove how easy it is to defeat the GC. (Spoiler: It's easy in every language, if you know the details!)
It is quite possible and very easy to set up a daemon (long running background process) in PHP. It's even possible to make it well behaved enough to gracefully restart and hand its connections off to a new version of the same script, or even the same script on the same server running different versions of PHP, though this is treading out of scope just a tiny little bit.
As for whether it's a good match, that is completely up to the developer. Are you willing, able, and happy to work with PHP to write a WebSockets server, or to use one of the existing servers? Yes? Then you're a good match for PHP and WebSockets.
3: JS Libraries for WebSockets
I honestly haven't researched them.
4: Tutorials for using PHP and Websockets
I'm personally fond of this tutorial: http://www.phpbuilder.com/articles/application-architecture/optimization/creating-real-time-applications-with-php-and-websockets.html
Although I have it on good authority that the specifics of that tutorial will soon be obsolete for that specific WebSockets server. (There will still be an actively maintained legacy branch for that server, though.)
In case of link rot:
Using the PHP-Websockets server (available on Github, will be homed soon), extend the base WebSocketServer abstract class and implement the abstract methods process(), connected(), and closed().
There's much better information at the link above, though, so follow it as long as the link exists.
It would hit the same bottleneck if you go through apache. This can be remedied by using a different web server, such as lighthttpd or nginx. You won't even need node at all.
PHP does not have decent shared memory making the biggest advantages of a WebSockets irrelevent. It should be decent enough if you don't want interaction between users, but even then I would have to frown upon the usage of PHP. PHP is great for a lot of things, but real-time communication is not one of them.
You might want to look at https://github.com/einaros/ws.
PHP is not a good back-end. Anything with an execution model that isn't run-and-forget in its own sandbox, such as Node, .NET, C/C++ and Java are good matches. PHP is suited for short running executions, such as actual web sites and even web services -- but not real time connections.
It's evident that the cURL functions are very widely used. But why is that? Is it really only because the extension is mostly enabled per default?
While I can certainly relate to not introducing 3rd party libraries over builtins (DOMDocument vs phpQuery), using curl appears somewhat odd to me. There are heaps of HTTP libraries like Zend_Http or PEAR Http_Request. And despite my disdain for needless object-oriented interfaces, the pull-parameter-procedural API of curl strikes me as less legible in comparison.
There is of course a reason for that. But I'm wondering if most PHP developers realize what else libcurl can actually be used for, and that it's not just a HTTP library?
Do you have examples or actual code which utilizes cURL for <any other things> it was made for?
Or if you just use it for HTTP, what are the reasons. Why are real PHP HTTP libraries seemingly avoided nowadays?
I think this would be related to why do people use the mysql functions instead of mysqli (more object oriented interface) or take a step further and use a data abstraction layer or PDOs.
HTTP_Request2 says that there is a cURL adapter available to wrap around PHP's cURL functions.
Personally a lot of the PEAR extensions I have tried out, I haven't been that impressed with (and I feel less confident with PEAR libraries that are sitting in alpha that haven't been updated in a long time). Whereas the HTTP_Request2 Library does look quite nice
I for one would have used cURL without thinking of looking at a possible PEAR library to use. So thanks for raising my awareness.
The libraries you mentioned aren't default, and from my experience in PHP, I prefer to use less of such libraries; they enable a broader attack surface, decrease reliability, open to future modification/deprecation more than PHP itself.
Then, there's the sockets functionality which, although I've used some times, I prefer to rely on a higher level approach whenever possible.
What have I used CURL for?
As some may know, I'm currently working on a PHP framework. The communication core extension (appropriately called "connect") makes use of CURL as it's base.
I've used it widely, from extracting favicons form websites (together with parser utilities and stuff) to standard API calls over HTTP as well as the FTP layer when PHP's FTP is disabled (through stream wrappers) - and we all know native PHP FTP ain't that reliable.
Functional reasons as mentioned in the comments:
It's very old, [widely used and] well tested code, works reliably
is usually enabled by default
allows very fine grained control over the details of the request.
This might need expanding. By nature of the common-denominator protocol API cURL might provide features that plain HTTP libraries in PHP can't...
Historic reasons:
curl used to be the only thing that could handle cookies, POST, file uploads...
A lot of curl use probably comes from tutorials that pre-date PHP 5.
I want to make the most lightweight possible HTTP server in C that supports PHP and possibly FastCGI if it will make a huge difference.
I'm not sure how to implement PHP support. Does it just call PHP.exe with the path to a .php file and read the output? What about things like header () in PHP? How are those handled by the server?
And another question, is it ideal to use separate threads for each request? I don't expect a very heavy load, but I'm not 100% sure on the design aspect of this...
I'm still pretty new to C and C++ and this is a learning experience.
Firstly let me say that if the goal is a lightweight HTTP server that serves PHP pages, this has already been done. Have a look at nginx.
As for a learning experience, you've chosen something that's actually fairly tough.
Multithreaded is hard at the best of times. On C/C++ (anything with manual memory allocation really) it's an order of magnitude harder.
Added to this is network communication. There are quirks to deal with, different versions of HTTP (mostly a non-issue now), all sorts of HTTP headers to deal with and so on.
The most intuitive solution to this problem is to have a process that listens to a port. When it receives a request, it spawns a process, which may exec to a PHP process if required.
This however does not scale. The first (obvious) optimization is to use threads instead of processes and some form of interthread communication. While this helps, it will still only scale so far.
Go beyond that and you're looking at async socket handling, which is fairly low level.
All of these however are fairly big projects.
Is there any particular reason you're doing this in C/C++? Or any particular reason you're learning one or both of those languages? These languages certainly have their place but they're increasingly becoming niche languages. Managed (garbage collected) languages/platforms have almost completely taken over. Joel argues that garbage collection is about the only huge productivity increase in programming in about the last 20 years and I tend to agree.
For a learning experience regarding HTTP code written in C you may also take a look at:
http://hping.org/wbox/
To make your own HTTP server, I reccomend to get inspiration from other peoples code. The programmer ry famous for the node.js framework has written simple elegant code regarding this matter.
Check out his libebb library, it has a parser generated with Raegel using the easy yet powerful PEG (it's based on Zed Shaw's mongrel parser). Also check the example usage. It is really clean and usable code.
libebb is a lightweight HTTP server library for C.
It lays the foundation for writing a web server
by providing the socket juggling and request parsing.
By implementing the HTTP/1.1 grammar provided
in RFC2612, libebb understands most most valid HTTP/1.1
connections (persistent, pipelined, and
chunked requests included) and rejects invalid or
malicious requests. libebb supports SSL over HTTP.
Regarding PHP-Server coupling, the easiest way is CGI but if you feel adventurous dig into php source code under SAPI (Server API) modules to see how to do it.
Similar to libebb, see http://www.gnu.org/software/libmicrohttpd/. It too uses GnuTLS for optional SSL.
I am writing a client / server based program, Server side is with Php and Client is with Python, and I need to make sure the transfer data is safe both way.
So, My question is
What encryption algorithm would be best for data transfer between Python and Php?
I couldn't use Https
Need to decrypt/encrypt with key on both Python and Php
I would't need to have shared public key, key could be set in both Python and Php manually
Since I don't know how to implement algorithm myself, examples on both language would be great.
My data are not serious like banking site, but just want to encrypt to be safe on the wire from sniffing
I've tried to check this question but I couldn't find suitable answer for me
Compatible encryption between C# and PHP, ColdFusion, Ruby, Python
Thanks in advance.
Do not attempt to invent an encryption scheme yourself. This is extremely difficult to get right (even professionals can't do this correctly on a regular basis). The SSL suite of security protocols embodies literally decades of research and implementation experience that you will not be able to reinvent.
For protection of private data over HTTP, the only correct answer is SSL. Anything else is doing yourself a disservice.
The answer is usually "it depends". If all you're looking for is symmetric encryption of sufficient quantities of data you'll probably want something like AES. There are however many ways in which you could use encryption that can turn out to be insecure in the end, which is why using https is a good idea since it's a bit higher level and harder to get badly wrong. I am not a security researcher, but this is just going on general advice I've been given in regard to security.
Anyways, there's a python library (edit: link removed, see comments) and you can apparently use mcrypt to handle encryption/decryption in PHP itself.
Greg Hewgill is correct and has the best advice. I tried to invent my own token system, while somewhat successful, it is not what it could be. So i believe SSL is the best way to go.
PHP has openssl built into it and such you can easily use that, which is what i am currently using. If you phone your hosting provider and ask them to enable openssl that shouldn't be difficult, that is if it is not activated already.
As for Python, im not 100% about what is available, but just to encrypt with a public key will be sufficient as your server will decrypt this data with a private key.
Public and private keys can be generated using your command line. Here is a link to that:
http://travistidwell.com/blog/2013/02/15/a-better-library-for-javascript-asymmetrical-rsa-encryption/
He does use a javascript library for client side encryption, however there should be options for Python.