Hi internals,
The goal of this patch is to allow user handling of low level socket
options for stream sockets created with stream_socket_*() or fsockopen()
functions.
I choose to extend the socket_get_options() and socket_set_options()
functions and keep the functionality inside the sockets extension so
this won't add seldom used "bloat" to streams if built without it.
With the patch, these two functions check if their first argument is a
stream, and then attempt to cast it to php_sock before trying to fetch
it as a socket resource.
Patch is here: http://si.kz/php-sockets-stream-options.diff.txt
Anyone with karma care to comment / commit ? :)
Regards,
Vincent
On Sat, 05 Mar 2011 15:19:31 -0000, Vincent NEGRIER
vnegrier@optilian.com wrote:
The goal of this patch is to allow user handling of low level socket
options for stream sockets created with stream_socket_*() orfsockopen()
functions.I choose to extend the socket_get_options() and socket_set_options()
functions and keep the functionality inside the sockets extension so
this won't add seldom used "bloat" to streams if built without it.With the patch, these two functions check if their first argument is a
stream, and then attempt to cast it to php_sock before trying to fetch
it as a socket resource.Patch is here: http://si.kz/php-sockets-stream-options.diff.txt
Anyone with karma care to comment / commit ? :)
I think a better option would be a function to convert a php socket stream
into a socket resource. That would avoid limiting this to
socket_get_options/socket_set_options and polluting the socket ext
functions prologue with these conversions.
And of course, in the long run, the socket streams should support all the
operations the socket extension currently does.
As to your patch, just by a quick glance, you ought to at least check if
the stream represents a socket (see php_stream_is). You also seem to be
leaking php_sock and should add some tests. But again, I see this as a
more inconsistent and limited approach.
--
Gustavo Lopes
Hi!
I think a better option would be a function to convert a php socket stream
into a socket resource. That would avoid limiting this to
socket_get_options/socket_set_options and polluting the socket ext
functions prologue with these conversions.
I think we already have PHP_STREAM_AS_SOCKETD, which should be
appropriate here, not?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Em Mon, 07 Mar 2011 01:37:44 -0000, Stas Malyshev smalyshev@sugarcrm.com
escreveu:
I think a better option would be a function to convert a php socket
stream into a socket resource. That would avoid limiting this to
socket_get_options/socket_set_options and polluting the socket ext
functions prologue with these conversions.I think we already have PHP_STREAM_AS_SOCKETD, which should be
appropriate here, not?
That will indeed give you a socket descriptor, but
- it's not directly available to user-space.
- you still have to create a socket extension resource in order to pass
it to functions of that extension.
--
Gustavo Lopes
Hi!
I think we already have PHP_STREAM_AS_SOCKETD, which should be
appropriate here, not?That will indeed give you a socket descriptor, but
- it's not directly available to user-space.
- you still have to create a socket extension resource in order to pass
it to functions of that extension.
Let socket functions deal with it - just see if it's a stream, use
AS_SOCKETD on it. They don't really need resource, they just need FD -
they'll get it one way or another.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Em Mon, 07 Mar 2011 09:18:24 -0000, Stas Malyshev smalyshev@sugarcrm.com
escreveu:
I think we already have PHP_STREAM_AS_SOCKETD, which should be
appropriate here, not?That will indeed give you a socket descriptor, but
- it's not directly available to user-space.
- you still have to create a socket extension resource in order to pass
it to functions of that extension.Let socket functions deal with it - just see if it's a stream, use
AS_SOCKETD on it. They don't really need resource, they just need FD -
they'll get it one way or another.
That was indeed the original proposal, except it was limited to
socket_get_option and socket_set_option.
In fact, the socket extension doesn't just need the file descriptor. Some
functions also need to know whether the socket is in blocking mode and its
type (AF_INET/AF_INET6/AF_UNIX/etc); see
http://lxr.php.net/opengrok/xref/PHP_TRUNK/ext/sockets/php_sockets.h#82 .
I suppose this information could be queried, but would you want to do the
cast and retrieve this data in every call say in a socket_read loop?
I also don't think magically mixing PHP streams and socket resources is a
good idea, users may start to think PHP streams and socket resources are
interchangeable and will be (even more) confused when they can't use
socket resources with the stream functions.
--
Gustavo Lopes
Hi!
I suppose this information could be queried, but would you want to do the
cast and retrieve this data in every call say in a socket_read loop?
I'd ask why you need socket_read and not just fread if you use streams?
If you need deeper semantics, then yes, either you use resources or you
convert. I'm not against the conversion function, per se, but the
regular API shouldn't force it's use (see below).
I also don't think magically mixing PHP streams and socket resources is a
good idea, users may start to think PHP streams and socket resources are
interchangeable and will be (even more) confused when they can't use
socket resources with the stream functions.
We don't have alternative to setting socket options on a stream. Neither
we want one - why have two functions for doing the same thing?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Em Mon, 07 Mar 2011 09:51:31 -0000, Stas Malyshev smalyshev@sugarcrm.com
escreveu:
I suppose this information could be queried, but would you want to do
the cast and retrieve this data in every call say in a socket_read loop?I'd ask why you need socket_read and not just fread if you use streams?
If you need deeper semantics, then yes, either you use resources or you
convert. I'm not against the conversion function, per se, but the
regular API shouldn't force it's use (see below).
That's a misleading argument. I could write a function that expects a
socket resource and it would still work if passed a stream, but with
degraded performance and functionality.
The degraded functionality comes from the fact socket_last_error() could
no longer be used to retrieve the last error on the socket as PHP streams
don't save this information. There may be other issues I'm not aware of.
We don't have alternative to setting socket options on a stream. Neither
we want one - why have two functions for doing the same thing?
Because the sockets extension is not enabled by default and it has a
different design -- it provides a low-level interface that closely follows
the C interface. Compelling functionality should still be added to the
streams, hopefully with a friendlier interface than socket_set_option.
--
Gustavo Lopes