> So what's the ultimate goal? Do we want to do try to move away from the > sockets extension? Or should we maintain the status quo (broad support for > standard use-cases with the extension there if you need more)?
After consideration, I think I tend towards the latter - bringing the more complex operations into the streams extension would create a lot of noise that would likely irritate many users (let's be honest, socket programming is not something the average PHP dev regularly does). But I *would* like to see more readily available access to the sockets extension, although I'm not sure what could be done about this - if I were to suggest that they be enabled by default would everyone recoil in horror? I suspect they might, but personally I don't see a solid reason for requiring users to enable them manually. And if that were to happen, or even if not, could we look at deprecating fsockopen()/pfsockopen()? These genuinely are just old, less flexible duplications of stream_socket_client(), which is enabled by default. Cheers, Chris On 6 September 2013 14:03, Daniel Lowrey <rdlow...@gmail.com> wrote: > This is a reasonable point. Personally I'd prefer to have as much socket > functionality as possible available natively without an extension. More > discussion is probably necessary on this point, though. > > So what's the ultimate goal? Do we want to do try to move away from the > sockets extension? Or should we maintain the status quo (broad support for > standard use-cases with the extension there if you need more)? If it's the > latter I'm not sure `stream_socket_listen()` is actually necessary. If we > want to keep ext/sockets around for non-trivial use-cases then adding > one-off stream functions like this might only serve to muddy the waters and > create bloat. > > Also ... > >> For instance, the API is likely to get messy if you start trying to >> set arbitrary options on a socket before binding. > > I'm not sure consistent cross-OS socket support will ever be anything but > messy (internally), which is a big part of why a uniform API would be > useful. > > > On Fri, Sep 6, 2013 at 8:47 AM, Chris Wright <daveran...@php.net> wrote: >> >> I'm generally agreed with everything said below by everyone - but Wez's >> message has >> caused me to wonder whether it might be worth simply creating >> stream_import_socket() >> instead. >> >> Yes, the sockets extension is not always available, but I would suggest >> that >> any >> instance that needs something that streams cannot currently provide is >> likely to be >> an instance over which the developer has more control (anyone trying to >> listen for >> connections on shared hosting is going to run into more roadblocks than >> just >> a lack >> of the sockets ext, for example). >> >> Equally, it's nice to be able to treat a socket as a generic stream, and I >> wouldn't >> want this functionality to disappear or become harder to use. >> >> As it stands, there is currently quite a bit of duplicated functionality - >> I >> think >> that a line needs be drawn that defines which extension is responsible for >> what >> i.e. leave the trivial stuff to streams and anything more advanced - I saw >> multicast being banded about below - to the sockets extension. For >> instance, >> the >> API is likely to get messy if you start trying to set arbitrary options on >> a >> socket before binding. >> >> That said, I'm have no actual objection to Daniel's patch, and I too would >> like to >> see a stream_socket_set_option() or similar. >> >> My $0.02 >> >> Thanks, Chris >> >> -----Original Message----- >> From: Daniel Lowrey [mailto:rdlow...@gmail.com] >> Sent: 06 September 2013 06:24 >> To: Wez Furlong >> Cc: internals@lists.php.net; Sara Golemon >> Subject: [PHP-DEV] Re: New function: stream_socket_listen() >> >> Hi! I'm with you @Wez -- allowances for assigning common socket options >> would be a major win. I'll see what I can do about working on something >> more >> robust than this one-off function PR. >> >> On Friday, September 6, 2013, Wez Furlong wrote: >> >> > I'm not opposed to the idea; the reason that I didn't implement it >> > initially is that I wanted something functional in the core >> > (ext/sockets was often not available) and we didn't have "PHP Spirit" >> > equivalents of the various and murky socket option setting APIs that >> > are present in ext/sockets (it's not the most intuitive interface even >> > for >> C developers). >> > >> > So we got an implementation that does what you want for most cases; >> > bind and listen in one step. >> > >> > I won't block this patch, but it would be /really/ great if you could >> > follow-on with a diff to allow setting the most commonly used socket >> > options (plus SO_REUSEPORT, since you mentioned it) and also a >> > function to allow setting CLOEXEC (perhaps stream_set_cloexec(bool)), >> > which is something I wish I'd added back when I put this stuff together! >> > >> > You win super extra crazy bonus points for allowing something like >> > this >> > >> > https://bitbucket.org/wez/couchshare/src/bcbf02e1a70d0dba86564480c63f5 >> > d6596658815/upnp-srv/couchshare.c?at=default >> > for setting multicast options. >> > >> > Thanks! >> > >> > --Wez. >> > >> > >> > >> > On Thu, Sep 5, 2013 at 12:10 PM, Sara Golemon >> > <poll...@php.net<javascript:_e({}, 'cvml', 'poll...@php.net');> >> > > wrote: >> > >> >> Seems reasonable to me, but Wez should probably weigh in on it. I >> >> vaguely recall a conversation with him when he first implemented >> >> stream_socket_*() and a reason why listen wasn't in the API. >> >> >> >> -Sara >> >> >> >> >> >> On Thu, Sep 5, 2013 at 10:30 AM, Daniel Lowrey >> >> <rdlow...@gmail.com<javascript:_e({}, 'cvml', 'rdlow...@gmail.com');> >> >> > wrote: >> >> >> >>> The stream socket functions are incredibly useful and obviate the >> >>> need for the sockets extension for the vast majority of potential >> >>> use-cases. >> >>> However, it's currently it's not possible bind a socket and listen >> >>> for connections in separate steps using stream_socket_server(). >> >>> >> >>> This _can_ be done with the aid of ext/sockets like so: >> >>> >> >>> $stream = stream_socket_server('tcp://0.0.0.0:0', $errno, $errstr, >> >>> STREAM_SERVER_BIND); $sock = socket_import_stream($stream); >> >>> socket_listen($sock); >> >>> >> >>> Why is this useful? Well, for example, binding to a port in the main >> >>> process and then listening individually in child forks/threads >> >>> trivializes scaling socket servers. By listening on the same bound >> >>> socket in multiple processes you get the advantage of the OS >> >>> distributing new client connections to the individual workers >> >>> instead of routing them in userland. >> >>> Additionally, newer linux kernel versions (3.9x) now support the >> >>> SO_REUSEPORT socket option which only makes this functionality more >> >>> attractive. Admittedly you still need ext/sockets to reap the >> >>> benefits of SO_REUSEPORT, but this may not always be the case. >> >>> >> >>> My proposed patch adds a very simple function so that listening may >> >>> be decoupled from binding without the need for ext/sockets: >> >>> >> >>> $stream = stream_socket_server('tcp://0.0.0.0:0', $errNo, $errStr, >> >>> STREAM_SERVER_BIND); // do stuff, fork, etc. Then in the child >> >>> process: >> >>> stream_socket_listen($server); >> >>> >> >>> Existing functionality is not modified and there are no BC breaks. >> >>> I.E. >> >>> you >> >>> can still bind + listen in a single step like before: >> >>> >> >>> $stream = stream_socket_server('tcp://0.0.0.0:0', $errNo, $errStr, >> >>> STREAM_SERVER_BIND | STREAM_SERVER_LISTEN); >> >>> >> >>> This addition seemed a bit trivial for an RFC, so and I didn't >> >>> bother hitting the wiki. The link to the relevant pull request >> >>> follows. Any thoughts, comments and opinions are welcome: >> >>> >> >>> https://github.com/php/php-src/pull/431 >> >>> >> >> >> >> >> > >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
