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.
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:
--Wez.
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.
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:
-
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. -
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.