Inner workings of DutchPIPE

How Does DutchPIPE Work?

DutchPIPE is technically based on two core concepts: a PHP server which runs all the time, handling a "universe" of objects, and an AJAX engine to handle the communication between the server and the browser of someone on a DutchPIPE enabled site. When someone enters a page, the page retrieval system looks like this on a file/class level:

User/Browser ←→ public/dpclient.php ←→ DpServer ←→ DpUniverse

When a browser makes a connection to the DutchPIPE site, a page is fetched from the dpuniverse/ directory based on the 'location' part in the URL:

http://dutchpipe.org/dpclient.php?location=/page/index.html

/page/index.html is also the default if no or an invalid location is given. public/dpclient.php now makes a socket connection to the DpServer object (which is created from the class in lib/dpserver.php), to retrieve the page and return it to the browser.

Figure 1: Old style PHP page generation


Figure 2: DutchPIPE style

The DpServer object is created from a PHP script that runs all the time, allowing DpServer to wait for connections from public/dpclient.php. This hardly uses resources when no one is around. By running all the time, objects such as users and pages are stored in memory, even after the http request of our example user has long finished, allowing for a universe to be constructed.

When DpServer and public/dpclient.php connect, public/dpclient.php first passes PHP variables such as $_GET, $_PUT and $_SERVER to DpServer, then DpServer passes the request on to the DpUniverse object, created from the class in lib/dpuniverse.php, where all objects reside.

In the first DutchPIPE versions, there was no separation between DpServer and DpUniverse, and DpServer was one big class. Logic was separated so that DpServer handles connections with public/dpclient.php, and DpUniverse handles all objects we're creating and storing.

DpUniverse returns the HTML to DpServer, representing the page the user is requesting, the home page in the example. DpServer passes it to public/dpclient.php, which returns it to the browser.

In the meantime, DpUniverse created a user object and a page object, and because the script keeps running, they remain in memory. If another user enters that page, DpUniverse notices the previous user object and page, and returns HTML which also contains the avatar of the other user.

AJAX Engine

The AJAX system looks like this:

public/dpclient-js.php ←→ public/dpclient.php ←→ DpServer ←→ DpUniverse

The two users we now have, both have public/dpclient-js.php running in their browsers. This javascript makes a connection every 2 seconds (depending on your settings) to public/dpclient.php, to ask if anything happened. If nothing happened, '1' is returned.

But in the example another user entered the page, so public/dpclient.php passes some XML over to the browser running public/dpclient-js.php, and the original user gets the message the other user enters the page, and sees his avatar.

public/dpclient-js.php does a couple of things:

• It passes actions from the user to public/dpclient.php.
• It asks public/dpclient.php for updates.
• It parses the response from actions and updates, and inserts, updates or deletes elements in the page.

It will retrieve responses in XML format to show messages, pop up those yellow windows, add or delete avatars and objects, and so on. In other words, it makes and inserts, or updates <div>'s and HTML on the fly, based on the XML it obtained.

If you perform an action, public/dpclient-js.php gets a response immediately. But to retrieve updates caused by external events, public/dpclient-js.php performs periodic checks.

By default, the AJAX engine checks for updates every two seconds. If this value is increased, this obviously makes communication faster, but has a penalty on your server. DutchPIPE is surprisingly lightweight, but if you have many users performing AJAX requests all the time, you must understand that DutchPIPE can be a strain for your server.

Note that two seconds is the maximum time it takes for stuff to be communicated. For example, if another user chats a message to you, it will be sent to your browser on your next AJAX request, which could be in 0.1 seconds if the last one was 1.9 seconds ago. It depends on the moment within the 2 second interval the update, caused by an external event, took place. This all means that on average, the delay is 1 second for waiting XML messages to be communicated.