# [patch] allow socket_[gs]et_options() to work on streams - Thread: https://externals.io/message/51577 - Original archive: https://news-web.php.net/php.internals/51577 - Started by Vincent NEGRIER on 2011-03-05T15:19:31+00:00 - Messages: 8 - 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 --- ## #51577 — Vincent NEGRIER — 2011-03-05T15:19:31+00:00 URL: https://externals.io/message/51577#51577 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 --- ## #51578 — Gustavo Lopes — 2011-03-05T20:35:36+00:00 URL: https://externals.io/message/51577#51578 · In reply to: #51577 On Sat, 05 Mar 2011 15:19:31 -0000, Vincent NEGRIER wrote: > 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 ? :) > 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 --- ## #51583 — Stas Malyshev — 2011-03-07T01:37:44+00:00 URL: https://externals.io/message/51577#51583 · In reply to: #51578 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 --- ## #51587 — Gustavo Lopes — 2011-03-07T09:15:08+00:00 URL: https://externals.io/message/51577#51587 · In reply to: #51583 Em Mon, 07 Mar 2011 01:37:44 -0000, Stas Malyshev 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 1) it's not directly available to user-space. 2) you still have to create a socket extension resource in order to pass it to functions of that extension. -- Gustavo Lopes --- ## #51588 — Stas Malyshev — 2011-03-07T09:18:24+00:00 URL: https://externals.io/message/51577#51588 · In reply to: #51587 Hi! > > […] > > That will indeed give you a socket descriptor, but > 1) it's not directly available to user-space. > 2) 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 --- ## #51591 — Gustavo Lopes — 2011-03-07T09:40:11+00:00 URL: https://externals.io/message/51577#51591 · In reply to: #51588 Em Mon, 07 Mar 2011 09:18:24 -0000, Stas Malyshev escreveu: > > […] > > 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 --- ## #51594 — Stas Malyshev — 2011-03-07T09:51:31+00:00 URL: https://externals.io/message/51577#51594 · In reply to: #51591 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 --- ## #51597 — Gustavo Lopes — 2011-03-07T10:06:47+00:00 URL: https://externals.io/message/51577#51597 · In reply to: #51594 Em Mon, 07 Mar 2011 09:51:31 -0000, Stas Malyshev escreveu: > > […] > > 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