The PHP Town Hall podcast has posted a new episode - Episode #7: "Web Sockets Are Fast".

Chris Boden joins us to talk about a Ratchet and React. The conversation is basically Ben and Phil asking a bunch of questions about how Ratchet works, pretending we know what is going on while Chris uses lots of words like "concurrency" and "non-blocking". We decide that PHP is web-scale, event-driven programming is not just for NodeJS hipsters, we all take the "Are You a Brogrammer" test and Michael Wales crashes the show half way through like a ninja.

You can listen to this latest episode either through the in-page player or by downloading the episode directly. You can also subscribe to their feed if you'd like the latest shows as they're released.

The latest issue of the Web and PHP Magazine has been published - issue #12, "Don't get in a PECL". This latest issue includes articles like:

• "The Power of PECL" by Simon Holywell
• "Be 'ready' if you want to be done!" by Steffan Surdek
• "All Data is Relational" by Cory Isaacson
• "Fixing PHP Production Problems with APM" by Dan Delany and Chris Kelly
• "Trust" by Sebastian Bergmann

You can download your copy for free from their site and catch up on back issues.

James Morris has an interesting new post to his site about the creation of a real-time web service that could be used for iOS applications via Websockets. He chose Ratchet for the handling (a PHP-based websocket tool) combined with Redis and Silex.

I was approached by a betting/gambling development company who potentially needed a middleware building that would pull from an existing gambling web service and basically transmit to connected iPhone clients the changes from the web service. At first, the obvious answer might be to create another REST web service that the iPhone clients could just ping for changes. However, one of the devs explained that this wouldn't be fast enough, or scale - they'd need changes to be transmitted as soon as possible, as the app would be a real-time betting app and there'd be thousands of connections to the server.

His solution involved hooking together Ratchet, Redis, Silex and Predis-async to create this sample tool for handling the websocket requests. it uses the "pubsub" mechanism of Redis to push the updates out to listening clients.

On Pivory.com there's a new topic (tutorial) showing you a simple example of using WebSockets with the Ratchet PHP library, complete with sample code.

WebSocket is the modern way for realtime two-way communications between server and browser. In the beginning we have Ajax calls [...] and with WS in picture the logic becomes [different]. [There] is a separate WS server, say listening on xxx.xxx.xxx.xxx:8080, and it can send messages to connected clients in realtime at any moment. The WS server can be in any language (such as node.js + socket.io) and on any machine or even in a cloud service. I use PHP (try http://socketo.me for Ratchet) because I am lazy.

The example shows a basic PHP Web Socket server running on a port with methods for "on connect", "on close", "on error" and "on message send". There's an example of the Javascript code to connect to this socket, showing how to convert it over from Ajax usage.

On NetTuts.com today there's a new tutorial showing you how to implement the Pusher service that gives you real-time messaging for your application. Their backend for the project is written in PHP using Pusher's library.

Do you want to spice up your web applications by making them real-time - but don't want to create new infrastructures for the sole purpose of getting web sockets to work? In this article, we'll explore how to use and implement Pusher, an HTML5 WebSocket-powered real-time messaging service for your applications.

Pusher uses HTML5 WebSockets to handle the messaging, so you'll need a browser that supports it to follow along with the tutorial. The Pusher API provides and endpoint for authorization and the push and pull of messages. In the tutorial, they create a simple chat application that gives a "Who's Online" and a window with the latest messages. You can download the full source (Javascript and PHP) here or view a demo here.

Gonzalo Ayuso has a new post to his blog today looking at a method you can use for real-time monitoring of your PHP applications with a combination of websockets and Node.js. The trick is to handle the PHP errors and send them over to a Node.js server for processing.

The inspection of the error logs is a common way to detect errors and bugs. We also can show errors on-screen within our developement server, or we even can use great tools like firePHP to show our PHP errors and warnings inside our firebug console. That's cool, but we only can see our session errors/warnings. If we want to see another's errors we need to inspect the error log. tail -f is our friend, but we need to surf against all the warnings of all sessions to see our desired ones. Because of that I want to build a tool to monitor my PHP applications in real-time.

The service will work similar to a chat server, sending messages one at a time to the remote server via a web client (HTML5-based) and some backend PHP. He includes all the code you'll need to create the HTTP and web socket server as well as the web client (with some Javascript) and some example server-side PHP. It throws an exception and catches it to send to the waiting Node.js server. A screencast is also included showing the full process. You can get the complete code for this example in this repository on Gonzalo's github account.

Michael Feichtinger has as recent post to his blog talking about HTML5 WebSockets including an example he's created.

HTML5 WebSockets makes it possible to open a persistent connection to a server within a web-browser via javascript. Websockets works already in the latest Webkit-browsers like Safari 5 and Chrome 5. Firefox 4 Beta 1 knows the Websocket-Object but it can't open the connection.

His sample script lets you control the cursors of the other visitors of the page via some Javascript that runs a "mousemove" event on the current page. You can get the source for both the WebSocketServer and server.