Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Moving Socket extension to PECL »

Moving Socket extension to PECL

php.internals

Maurice

19 years ago
Hi there, unfortunately I haven't read your comments some months ago on moving the Socket extension to PECL. I just stumbled upon it yesterday while surfing around on Sara's blog (btw, great book!) and was quite upset about it... I've written a multiplexing connection suite in PHP5 (LGPL, but not yet released) that relies on the Socket extension. What it does? Well, multiplexing asynchronous TCP/UDP connections using socket_select. In my first tests I also included support for streams (using stream_select) in order to support SSL/TLS enabled connections. However, the SSL transport layer in the Stream "extension" is totally screwed up if you use asynchronous socket streams. I know that it is not the easiest thing to implement asynchronous SSL, but the main problem with streams is that the easy-to-use interface is not really suitable for complex things like async. SSL (for those involed: SSL_read may as also write to the connection and SSL_write may also read from it. This logic might be implemented in stream_select, but therefore the stream read/write functions must be a little bit more specific about what happend (SSL_get_error)). That's why I started extending the socket extension with socket_ssl_* functions that use the openssl extension (and thus are only available if PHP is compiled with openssl support). I will provide a patch for that once it's complete and out of beta status. In my opinion one should rather move the stream_socket functionality to the Socket extension (and maybe add a function like stream_create_from_socket()) then moving the Socket extension to PECL. Anyway, the Stream-SSL part has to be fixed _before_ moving the socket extension to PECL. Maurice.

Wez Furlong

19 years ago
On 2/8/07, Maurice <maurice@iceblog.de> wrote:
> In my first tests I also included support for streams (using > stream_select) in order to support SSL/TLS enabled connections. However, > the SSL transport layer in the Stream "extension" is totally screwed up > if you use asynchronous socket streams.
That's the first I've heard about this; I've been using it in this fashion successfully for some time.
> That's why I started extending the socket extension with socket_ssl_* > functions that use the openssl extension (and thus are only available if > PHP is compiled with openssl support). I will provide a patch for that > once it's complete and out of beta status.
The problem with ext/sockets is that it is old, unmaintained, buggy, and is not tied into the streams layer.
> Anyway, the Stream-SSL part has to be fixed _before_ moving the socket > extension to PECL.
The first step is opening a bug report with details on how to reproduce the problems that you've hinted at: http://bugs.php.net --Wez.

Maurice

19 years ago
Hi Wez,
>> In my first tests I also included support for streams (using >> stream_select) in order to support SSL/TLS enabled connections. However, >> the SSL transport layer in the Stream "extension" is totally screwed up >> if you use asynchronous socket streams. > > That's the first I've heard about this; I've been using it in this > fashion successfully > for some time.
Normal (synchronous) connections are working just fine - no problem here. Have you really tried SSL with non-blocking streams? It works _sometimes_ (depends on the timing/server/etc.), but not always. I've checked the source code and openssl SSL_* calls are not used the way they should be in non-blocking mode. I'll prepare a test case later...
>> That's why I started extending the socket extension with socket_ssl_* >> functions that use the openssl extension (and thus are only available if >> PHP is compiled with openssl support). I will provide a patch for that >> once it's complete and out of beta status. > > The problem with ext/sockets is that it is old, unmaintained, buggy, > and is not tied into the streams layer.
Buggy? Well, it used to be really buggy some years ago, but I think it's rather stable now. Sockets are always a little bit problematic because they are not the same on all operating systems, but at least on Linux and Windows I don't have any problems. What if I would start maintaining the sockets extension? I think PHP should have some low-level connection stuff built-in. If you really think of moving ext/sockets to PECL I might as well concentrate on fixing the SSL/crypto problem in non-blocking streams. It's just that streams aren't so talkative regarding error messages...
>> Anyway, the Stream-SSL part has to be fixed _before_ moving the socket >> extension to PECL. > > The first step is opening a bug report with details on how to > reproduce the problems that you've hinted at:
Yeah, I'm going to do that. I started with a bug (crashes PHP on Windows XP) regarding the streams extension in November. It's assigned, but no action has been taken yet: http://bugs.php.net/bug.php?id=39396 I see, it's not a "major" bug, but it crashes PHP and might (_might_) be used to inject code (haven't checked that). Maurice.

Maurice

19 years ago
Hi once again,
>> In my first tests I also included support for streams (using >> stream_select) in order to support SSL/TLS enabled connections. However, >> the SSL transport layer in the Stream "extension" is totally screwed up >> if you use asynchronous socket streams. > > That's the first I've heard about this; I've been using it in this > fashion successfully > for some time.
Don't have time for a test case right now; but I've checked the code and remembered (parts of) the problem: 1) If you're using non-blocking SSL streams then fread sometimes returns int(0) which actually means SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. 2) stream_select() returns write and read arrays for the async. SSL stream even if there's no user data (but SSL protocol data). For a quick example, just have a look at your own code (add SSL): guru-multiplexing.php @http://www.php.net/~wez/guru-multiplexing.tgz (and don't forget STREAM_CLIENT_CONNECT in stream_client_connect ;-) Maurice.