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:
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
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 usingstream_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_REUSEPORTsocket 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:
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/bcbf02e1a70d0dba86564480c63f5d6596658815/upnp-srv/couchshare.c?at=default
for setting multicast options.
Thanks!
--Wez.
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
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 usingstream_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_REUSEPORTsocket 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:
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.
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/bcbf02e1a70d0dba86564480c63f5d6596658815/upnp-srv/couchshare.c?at=default
for setting multicast options.Thanks!
--Wez.
On Thu, Sep 5, 2013 at 12:10 PM, Sara Golemon <pollita@php.net<javascript:_e({}, 'cvml', 'pollita@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 <rdlowrey@gmail.com<javascript:_e({}, 'cvml', 'rdlowrey@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 usingstream_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_REUSEPORTsocket 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:
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:rdlowrey@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.
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
thishttps://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
<pollita@php.net<javascript:_e({}, 'cvml', 'pollita@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
<rdlowrey@gmail.com<javascript:_e({}, 'cvml', 'rdlowrey@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 usingstream_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_REUSEPORTsocket 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:
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.
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:rdlowrey@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.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
thishttps://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
<pollita@php.net<javascript:_e({}, 'cvml', 'pollita@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
<rdlowrey@gmail.com<javascript:_e({}, 'cvml', 'rdlowrey@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 usingstream_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_REUSEPORTsocket 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:
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
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 surestream_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.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:rdlowrey@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.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
thishttps://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
<pollita@php.net<javascript:_e({}, 'cvml', 'pollita@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
<rdlowrey@gmail.com<javascript:_e({}, 'cvml', 'rdlowrey@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 usingstream_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_REUSEPORTsocket 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:
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
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 surestream_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.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:rdlowrey@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.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
thishttps://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
<pollita@php.net<javascript:_e({}, 'cvml', 'pollita@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
<rdlowrey@gmail.com<javascript:_e({}, 'cvml', 'rdlowrey@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 usingstream_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_REUSEPORTsocket 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:
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.
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 ofstream_socket_client(), which is enabled by default.Cheers, Chris
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 surestream_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.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:rdlowrey@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.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
thishttps://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
<pollita@php.net<javascript:_e({}, 'cvml', 'pollita@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
<rdlowrey@gmail.com<javascript:_e({}, 'cvml', 'rdlowrey@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 usingstream_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_REUSEPORTsocket 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: