WebSocket Support Investigation
With Comet technology dying out and HTML5 around the corner, WebSocket support is becoming a very hot topic on the edge of the new Push Button Web revolution.
I set out to discover how viable that technology is right now.
Client Side
HTML5 Compliant Technologies
HTML5 compliance includes a WebSocket object that can be used to make persistent streaming tcp connections to a WebSocket server (cross-domain).
The only browsers currently supporting this technology is Google Chrome and Safari. (Webkit implementors). Firefox is planning on including WebSocket support in their 3.7 release. IE is quiet on the matter (we're used to this by now).
I have tested HTML5 WebSocket implementation using Chrome as client and PHP for the WebSocket server. It was blazingly fast, reliable and robust when I intentionally disrupted network availability.
WebSocket using Flash
For browsers not offering native WebSocket support, the standard workaround is to use Flash socket connections. I implemented a few of these methods, and even though I eventually got it to work, I found it not very robust (when it broke, I had to refresh the page to get the connection back up and running) and definitely not very friendly (Flash TCP connections require a security policy file to be rendered from the same server on port 843 before the socket connection is allowed)
This is an awkward solution, and feels mostly like a hack. It is also dependent on client-side variables like whether Flash is supported on the client and what version is running.
Server Side
The server side implementation of WebSocket is well supported. Most server side programming languages provide an implementation of CURL, which is quite enough to support WebSockets.
The main challenges on this end is configuring your hosting platform to open the chosen port for traffic.
Zend Server 5.0 Beta Code Tracing
Zend Server 5.0 Beta is promising an awesome bug-tracking method that will help find and solve problems much easier. Whenever an error is encountered, the new tracing feature will automatically log full error tracing information – even when in production mode.
Just as cool, one can manually run the trace to profile the execution of your code in real time. This will allow you to find bottlenecks, see the function tree for the entire execution of your script and use that information to optimize execution.
Take a look at Zend
