Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68906
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain metrodigi.com from 74.125.82.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAH8Mpnk3bUm4JgAEAeMH1BcQhYbSdVtqDPL14chLz8XsiGmE4g@mail.gmail.com>
References: <CAH8MpnmPv1GLR=Dz63_NxqJwNmJi-Gr5PdGor1RBpm3px=q00w@mail.gmail.com>
	<CAESVnVpd+EpS=TcOceaDn8G1nkE54_b1erYp3h2-k1GA+rusfg@mail.gmail.com>
	<CAGRvqCyn8Lfh_L380m=GTAxiXAFcV-50=rA1DKgi4sx8rSfWHQ@mail.gmail.com>
	<CAH8MpnkpuvuRT1SFs+qwSGoj3hTbH7TJr7KoiJ+FSY9sSuGyhw@mail.gmail.com>
	<002501ceaaff$30fc3320$92f49960$@net>
	<CAH8Mpnk3bUm4JgAEAeMH1BcQhYbSdVtqDPL14chLz8XsiGmE4g@mail.gmail.com>
Date: Fri, 6 Sep 2013 06:11:37 -0700
Message-ID: <CAMSgVDLuq3XasPmgGEXHw5XK=1_=tLRqreA+_oU-NF8Zo62TdA@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: Chris Wright <daverandom@php.net>, Wez Furlong <wez@wezfurlong.org>, 
	"internals@lists.php.net" <internals@lists.php.net>, Sara Golemon <pollita@php.net>
Content-Type: multipart/alternative; boundary=047d7b66f9074a11a304e5b6c75d
Subject: Re: [PHP-DEV] Re: New function: stream_socket_listen()
From: smckinney@metrodigi.com (Steve McKinney)

--047d7b66f9074a11a304e5b6c75d
Content-Type: text/plain; charset=ISO-8859-1

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



On Fri, Sep 6, 2013 at 6:03 AM, Daniel Lowrey <rdlowrey@gmail.com> 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 <daverandom@php.net> 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: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.
> >
> > 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
> > > <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 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
> > >>>
> > >>
> > >>
> > >
> >
> >
>

--047d7b66f9074a11a304e5b6c75d--