> if I were to suggest that they be enabled by default would everyone recoil
> in horror?
I'd certainly be up for this as it would make my life easier and eliminate
the need for changes to the streams API. Environments like shared hosting
could easily pass a --disable-sockets configure option or something. To me,
socket functionality deserves a first-class place at the language table.
But I'm also not sure if hardcore socket functionality is 100% in line with
the "PHP mission" to accommodate as many programmers as possible.
On Fri, Sep 6, 2013 at 9:58 AM, Chris Wright <[email protected]> wrote:
> > 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 <[email protected]> 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 <[email protected]> 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:[email protected]]
> >> Sent: 06 September 2013 06:24
> >> To: Wez Furlong
> >> Cc: [email protected]; 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
> >> > <[email protected]<javascript:_e({}, 'cvml',
> >> > '[email protected]');>
> >> > > 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
> >> >> <[email protected]<javascript:_e({}, 'cvml',
> >> >> '[email protected]
> ');>
> >> >> > 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
> >> >>>
> >> >>
> >> >>
> >> >
> >>
> >
>