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