# Moving Socket extension to PECL - Thread: https://externals.io/message/27906 - Original archive: https://news-web.php.net/php.internals/27906 - Started by Maurice on 2007-02-08T14:02:22+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #27906 — Maurice — 2007-02-08T14:02:22+00:00 URL: https://externals.io/message/27906#27906 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. --- ## #27983 — Wez Furlong — 2007-02-10T14:04:54+00:00 URL: https://externals.io/message/27906#27983 · In reply to: #27906 > 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. --- ## #27992 — Maurice — 2007-02-10T19:59:10+00:00 URL: https://externals.io/message/27906#27992 · In reply to: #27983 Hi Wez, > > […] > > 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... > > […] > > 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... > > […] > > 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. --- ## #27993 — Maurice — 2007-02-10T22:43:30+00:00 URL: https://externals.io/message/27906#27993 · In reply to: #27983 Hi once again, > > […] > > 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.