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 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. 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 :)