In a new tutorial from DevShed today, they take a look at some of the "networking" functions that PHP has to offer - basically anything that can make a network connection.
PHP has a great many tools for interacting with a network and also with the Internet. In this article we will look at some of those tools and functions to see how we can use them to make our scripts more useful in a network environment.
In a new post to the ThinkPHP blog today there's a look at combining Comet with PHP to make a simple method for the client to talk back to the server outside the usual methods.
If a couple of users have opened the application there are already some hundred or thousand requests per second. The outcome of this is a big load for your server and a highly increased traffic - your server will in a senseless way be overloaded. In conclusion, our problem is the enormous amount of polling without knowing whether the server really wants to send a new push. Let's turn the initial situation around. And we get the solution to our problem: Comet.
With Coment, the model changes and the request is "cached" on the server-side automatically in a single Comet instance. Coordinate this with another recommendation of theirs, a PHP socket server, and you can do some pretty interesting things.
On the AnyExamples.com website, there's a new little how to on making a whois client in PHP (without just using an exec or similar call to the filesystem).
This article contains PHP implementation of whois client (as a function ae_whois), which may be used to request domain information from specified whois servers.
Their method uses the socket functionality (fsockopen, fwrite, fclose) to make a connection to the remote server for the specified domain's information.
If your shared hosting provider has just turned off (or has had turned off) the allow_url_fopen setting for your PHP hosting, fear not - there are other ways to open outside pages. This new article from Hiveminds gives you two simple ways - one using just the normal socket functions and the other using cURL.
So what do you do when those nasty errors start showing and your scripts no longer work? There are two solutions here.
They give four bits of example code - the first is the raw socket request, the second is the cURL example, and the last two are applications of these to grab the current "threat advisory condition" level from the White House website.
Chris Chabothas posted a PHP package he's worked up that functions as a daemon sitting and listening on a socket.
To deal with 1000's of concurrent, always on (comet aka hanging iframe) http (server) connections, and an equal amount of IRC client connections, plus being able to interpret and parse and delegate all the messages and events, i needed a very fast, stable, flexible and easy to use 'daemon' library for PHP.
He links to the tarball of the release and to the project page as well as including an example of its usage - creating a simple HTTP server with various hooks built in (like on_connect, on_read, and on_timer).
In this new post on the PHP Security Blog, Stefan Esser brings up an interesting issue when dealing with web applications - being able to bind a script/application to a different port on the local machine.
Unfortunately the ability to bind yourself to a port and receive connections is a threat to webapplications installed on different virtual hosts on the same IP, even if other security measures in place, like tight filesystem permissions or executing PHP script with the permission of the owner.
He gives an example in PHP of how this can happen and one of the scary side effects of having it in the same domain - the cookie information is passed in. It's a simple concept that could have very bad consequences in the wrong hands.
Additionally, you don't even have to create it in PHP either. As cyberlot mentions, it could be created in any language that has socket functions. Be sure to check out the comments for more thoughts and comments on the post.
On his blog, Premature Optimization, Shahar Evron has posted some information about work he's done on the Zend_Http_Client package of the Zend Framework - including the push to make it live.
Earlier this week, I finally (after long and hard work) pushed the Zend_Http_Client out of the incubator and into the core of Zend Framework, and it will be released with the 0.6 preview release.
Some of the things introduced in this package include the introduction of "connection adapters", a method of having an adapter object made responsible for handling the networking connection. The default for this is the socket adapter, but work is already being done to create cURL and future ideas for a caching adapter or a pfsockopen-based option for more preferment connection needs.
Shaharalso includes some stats to show off what the new package can do and how many requests per second it can handle.
From UnixReview.com, there's a handy guide to functionality that PHP supports to help you get a handle on things like multiple socket requests - multi-tasking in PHP.
There's quite a bit more to tell, though, about PHP and concurrency. AJAX certainly boasts multi-tasking capabilities, and PHP supports AJAX about as well as the other Web languages support Ajax. An easy conclusion is that, by way of AJAX, therefore, PHP multi-tasks. However, common security, accessibility, and compatibility requirements prevent use of AJAX in many programs.
It's also true that PHP does not "support threads", as many observers put it. Even without AJAX, even without threads, there are still at least two distinct ways to achieve server-side multi-tasking with PHP. Let's look at how the language multi-tasks, and why:
They give an example of one way to fetch information from multiple sources normally (concurrent socket requests) to provide the "low level". They then show an example of how to use pcntl_fork, pcntl_exec, and streams support that can be built into PHP to create a three process function to grab the main pages (and status codes) from each of the sites in an array.
Jim Plush has posted part one of a series of tutorials covering the use of sockets in PHP:
Anyway, here is a link to Part I on my socket programming tutorial. This page is really aimed at getting you up to speed on what socket programming is all about and what all the commands refer to and what the parameters they take are geared to do. I'm planning on adding a section a week so we'll see how that goes.
Jim Plush has an interesting post today (complete with a video) about a project he's worked up for sending messages to remote devices via a web connetion and a JSON encoded message.
I have my PDA resting on my laptop and on my laptop I have firefox open with a local PHP page. The PHP page has a couple checkboxes that when clicked and the submit button pressed will actually open up a socket connection to the IP address I specified in the text field above. The script then sends a JSON encoded event string of data. That string gets read in by a custom minimo/firefox extension I wrote that listens on a particular port for incoming connections, reads in any data sent then forwards that on to user land javascript. By user land javascript I mean javascript written on a regular webpage, not in the extension itself.
The video linked to in the post shows more clearly how this functionality works, and also includes a bit more detail on the whole process, including a graphical representation of how the entire process works. Ajax wasn't actually used to send the message in this particular application - it's all just made with regular sockets.
