Hi, all - Not sure why the domain @metrodigi.com is on this working group's list. I did not sign up for it.
Since I have to "put up" with the email noise, I might as well get something out of it so here goes: We are a well funded, rapidly growing tech company working near San Francisco that is looking for senior PHP developers. Awesome work environment, super good salary and benefits and very cool cloud/mobile growth market. Check us out: http://www.metrodigi.com/jobs HIRING 4-5 DEVELOPERS IMMEDIATELY. Cheers, Steve Steven McKinney *metrodigi | CEO* tel: 415.578.2926 | cell: 415.806-8654 | fax: 415.785.3421 | www.metrodigi.com On Fri, Sep 6, 2013 at 6:03 AM, 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 > > >>> > > >> > > >> > > > > > > > >
