On 1/26/2020 2:31 PM, Rowan Tommins wrote:
On 25/01/2020 22:03, Mike Schinkel wrote:
I'm not following the discussion 100% – more like 85% — but it seems
like what we might be saying is the need for a user-land
implementation of a long-running PHP request, one that does not timeout?
It's not about timing out, as such, it's about starting with a fresh
state each time a request comes in from the web server. So the
long-running script can't just "opt out of time outs", it's got to be
launched by something other than a request - in existing
implementations, it's basically started as a command-line script, and
then handles the networking itself.
Then we could look to prior art with GoLang channels where they
"Communicate to share memory" and do not "Share memory to
communicate." IOW, add an API that allows a regular PHP page to
communicate with a long-running page. This would decouple and allow
for better testing, and hopefully fewer hard to track down bugs.
In general, though, this is an interesting concept: keep each request
separate, but have a "master process" (initialised when the server
starts, or by something similar to a fork() call in a normal request)
that all requests can explicitly share things with. I'm not sure that
would work well for Web Sockets, because it still relies on the
traditional request-response cycle, but I've never really used them, so
don't know what kind of architectural patterns make sense for them.
Regards,
WebSocket is a framing protocol over TCP/IP for long-lived (potentially
hours), mostly quiet, two-way connections to a web server usually from a
compliant web browser that tends to slowly use more and more RAM on the
client for whatever reason. My favorite example of WebSocket usage is
lightningmaps.org - accurately triangulates lightning strikes using
ground-based sensor stations thousands of miles apart.
People tend to write WebSocket servers in NodeJS partly because they
don't realize that PHP can already do the same. Example:
https://github.com/cubiclesoft/php-drc
In recent years, I've used PHP for a lot of non-web things. In fact, a
lot of my real PHP work these days is CLI-based usually running either
as cron jobs or as installable at-boot system services via Service Manager.
I recommend reading libev's documentation regarding various "special
problems." PHP would be implicitly taking on a lot of complicated
issues that even the authors of libev and libuv (NodeJS uses libuv)
haven't entirely solved and then passing those issues onto users. It
would be important to at least point the various issues out to users in
documentation.
I personally prefer to use userland isolated libraries even though it
takes me slightly further away from the metal. From my experience,
libev and subsequently PECL ev are a more natural transition for
existing socket code whereas Swoole/libuv basically demand a rewrite for
little gain. The only downside to using PECL ev is that its support for
Windows is actually non-functional despite PECL generating DLLs.
WebSocket generally introduces network and processing overhead - HTTP
headers and parsing for setup + framing protocol handling. In many
cases, a simpler "JSON blob per newline" approach works just as well (if
not better) and can afford better isolation and performance models (i.e.
not everything has to be WebSocket). There are plenty of flaws inherent
to the design of the WebSocket protocol itself (some are
security-oriented) and so anything built on it shares those flaws.
WebSocket and WebRTC SAPIs could be an interesting direction to go in.
I'm not opposed to the idea. I do think though that people need to be
far more reserved when it comes to writing TCP/IP servers than they are
right now. A lot of careful thought needs to happen prior to writing
bind(). Network code is quite notably hard to get right and complexity
multiplies with multi-OS/platform support.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
http://cubiclesoft.com/
And once you find my software useful:
http://cubiclesoft.com/donate/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
