Thursday, December 15, 2005

SLoPIS (sloppies): Slow Loading Pages of Infinite Size

I've sometimes wondered how I'd instantiate and maintain a call-back link between a client and a server on the Internet. That is, I want the server to update the client as and when various events occur without the client having to specifically poll for them. This is very easy to do over an intranet, but seems almost impossible over the Internet because most clients will be behind restrictive firewalls and proxies. Using an arbitrary protocol over a randomly chosen port is not going to work. So is using polling the only way to go?

One way out of this conundrum might be to use something I've christened SLoPIS (pronounced: sloppies) - for Slow LOading Pages of Infinite Size - in a moment of whimsy.

What your client will do is issue a GET command to a particular URL, which will be generating the actual call-backs. The server starts to send back a 'page' with any queued events or a ping every 5 seconds to keep the connection alive. To any entity in the middle, the page simply appears to be very large and very slow loading, but not otherwise unusual in any way.

So lets say I have a REST based file system or something and I want to be informed of any file changes on the server. I can open up a connection to http://some.filesystem.com/SLoPIS/filechanges which is, lets say, a Java Servlet on the server. As part of the request I send my authentication data and the server responds with the any queued events. e.g.

<html>
<body>
DELETION: /mnt/some/file
...

If there's nothing to report for awhile and the connection is in danger of timing out, it'll send a ping, like so:

...
PING
...

to continue the downloading of the 'page'.

Now this isn't a true call-back, because the connection has to be initiated by the client, but for most applications I can think of, this is not really such a problem. To receive, the client just keeps an ear to the sloppy and reacts to any events sent over it.

So no more issues with firewalls or proxies and no need to create a special hole in them to get your application to work! :-) I can see this being very valuable for AJAX based web-apps.

There can be issues with load and running out of ports from a client source IP if there are a lot of NAT'ed users coming in from the same IP, so it's not a perfect solution. However, it may be more appropriate than polling in many situations.

No comments: