Re: com php-src: Add SO_REUSEPORT + SO_BROADCAST support via socket stream context option: NEWS UPGRADING ext/ftp/ftp.c main/network.c
main/php_network.h main/streams/xp_socket.c

On Wed, Aug 6, 2014 at 4:13 PM, Daniel Lowrey <rdlowrey@php.net> wrote: > > On Wed, Aug 6, 2014 at 9:13 AM, Julien Pauli <jpauli@php.net> wrote: > >> On Wed, Aug 6, 2014 at 3:07 PM, Daniel Lowrey <rdlowrey@php.net> wrote: >> >>> Sorry about that -- I assumed that since this was a minor option (that >>> should already exist) and not new functionality it was fine. >>> >>> The problem here is that stream_socket_server() binds and listens in the >>> same step. It's currently impossible to assign pre-bind options to a stream >>> socket server for this reason. The existing stream context option approach >>> is well-worn, not a new thing and provides a hook to do things like this >>> right now in a way that maintains BC. >>> >> >> Yes, because stream_socket_server() was designed to hide many of these >> low level technical things from the end user. >> I would say that if you need a BSD-socket-API-like-API with PHP, just use >> ext/socket which is designed for that. >> >> >>> >>> You won't hurt my feelings if it needs to be reverted, though I see >>> little difference between adding this now or adding this in 5.6.1. >>> >> >> Yes, I know ;-) >> But our process is clear here, even if putting that in the actual 5.6 >> branch should not hurt, let's follow strictly our process for 5.6.0 please. >> >> >> >>> I **do** need this functionality, though. It's not just a spurious >>> addition. Right now I have to resort to all sorts of ridiculous >>> pcntl_fork() hackery to reuse the same port number on the same address for >>> non-blocking servers in multiple processes. Further, these socket options >>> are available across all environments (except Solaris for SO_REUSEPORT) and >>> appropriate #ifdefs are in place just in case. Windows is the only >>> environment that does not benefit from SO_REUSEPORT as its sockets exhibit >>> this feature by default. >>> >>> In my humble opinion the lack of this functionality is a bug. Had I >>> realized other people saw it as a feature I would have submitted a >>> full-blown bug report to go along with it. >>> >> >> I tend to agree with you there. >> >> Julien.Pauli >> > > > Sorry for the initial top-post -- gmail makes it easy to forget when you > don't pay attention! > > > But our process is clear here, even if putting that in the actual 5.6 > branch should not hurt, let's follow strictly our process for 5.6.0 please. > > You're definitely correct. Sorry about that :) > > > I would say that if you need a BSD-socket-API-like-API with PHP, just > use ext/socket which is designed for that. > > Well, unfortunately ext/socket is insufficient in this case for a few > reasons: > > 1. It has no support for SO_REUSEPORT at this time, so a patch would be > needed there as well. > Feel free to patch it please. > 2. Stream servers have full access to stream encryption so they're viable > as-is for https:// implementations. You'd need to manually > implement TLS > to do this with ext/sockets. Note that socket_import_stream() is of no use > in such cases because you can't import a stream with encryption enabled for > obvious reasons. > > Most useful socket options could easily be implemented for stream servers > using the context option approach. This approach exposes no additional > complexity to end users as contexts are entirely optional. > > The stream server is a really nice abstraction, but adding just a small > set of low-level configurability here would make it *extremely* useful for > sophisticated server applications. Couple that with the access to the many > server-specific TLS improvements I implemented specifically for this > purpose and it's a really powerful thing. I'd argue it's far more useful > than the sockets extension. > > In any case, I'd like to implement quite a few more socket options this > way but as we're so close to release rushing is a bad idea. > > Again, I understand the release process should be adhered to, so do what > needs to be done on that front. And thanks for putting up with my itchy > merge trigger finger :) > We may have those in 5.6.1 and 5.5.X as well. They are "just" options added to the socket layer. IMO, it is safe to add those in revision versions, as I dont feel this is a "feature" which is added, but just a lack of sense or forgotten options that are fixed (added). In addition to that, it will have a tiny to no impact on our huge codebase. Julien.Pauli