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 > >>> > >> > >> > > > >
