http://www.freerice.com

For all intents and purposes, the Internet is a unicast (one to one) environment. Which brings me to my first grievance… it’s missing true multicast. Yes, some ISPs support multicast and the MBONE project is in existence, but neither really solve the problem. I’m certainly not the first one to touch on this, but it’s worth repeating because it is currently the most obvious and important deficiency of the Internet. It can be a serious drain on bandwidth and creates awkward architecture decisions for both large and small applications.

This has presented a particularly difficult problem for video distributors. It’s no secret that the major television networks are having a difficult time monetizing video distribution on the internet. Cost is at least partly to blame. Up until recently, television broadcasts were just that… broadcasts. As I understand it, cable or satellite companies send out one signal that that everyone taps into. Not one signal for every subscriber. Paying for an infrastructure for all subscribers once has a very different value proposition than having to pay for a scalable infrastructure with greater incremental costs for adding new subscribers.

My next grievance is a protocol related one. HTTP is a great technology, but it is intended to support polling for a single user. You open a TCP/IP connection, send in an HTTP request for specific information, receive the information, and close the connection. This was great when the web was a group of html documents, images, and other assorted downloads. Times have changed and we have more interaction on our web sites and web applications. It’s time to adopt new protocols and stop using existing ones inappropriately.

There are two good examples of this. I’ll start with Soap / Web Services. The idea of SOA (Service Oriented Architecture) on the Internet is great. To have access to a variety of free and commercial services on a public network presents many great possibilities and encourages innovation. Unfortunately the reality is less satisfying than the dream. SOAP, aside from being bulky as described here, suffers from HTTP limitations. This means that without really hacking it, you are stuck with a system that at it’s best can do remote method calls, but at it’s worst is required to poll for updates. For some applications this is ok, but for many applications realtime interchange of data would decrease latency for users and simultaneously decrease load on machines that previously had to handle polling.

RSS suffers from similar problems. In this case I feel XML is less of an issue due it’s purpose, but polling remains a problem. It’s time for a standard publish / subscribe protocol. RSS is not the only technology that could benefit from this type of protocol, but it makes for a compelling case. Let’s pretend for a moment this protocol exists and RSS has it’s basis in it. You immediately reduce all the issues of RSS readers polling often and downloading stale data. From a user perspective you see new entries more immediately. Let’s pretend one more time and say multicast is widely available. Feeds could then be broadcast which would also save bandwidth. So we’ve gone from every user downloading the same stale data over and over again to a system where one broadcast is made to active interested parties and offline parties can sync when they come online. In my eyes this seems like a huge improvement.

Ok, now for the coup de grâce. BitTorrent. If you were to tap any Internet backbone, it’s safe to say you’d see a lot of BitTorrent traffic. Here’s where it gets interesting. I think you can apply the changes above to increase BitTorrent performance. What if each BitTorrent client broadcast packets instead of sending them multiple times to different parties. I’m sure with some algorithm finagling, you could see some serious improvements in download times and bandwidth utilization. The hardest part would be bridging the gap between different sized connections, but this could surely be solved by partitioning data broadcasts in similar ways to what BitTorrent does now. With the standard publish / subscribe protocol there would be an obvious technology to manage the packet distribution and reduce the barrier for application developers to create new clients. Who knows, maybe with some commercial modifications this could even be a way to distribute videos in a cost effective way.

Technorati Tags: Internet, Performance, Unicast, Multicast, Publish, Subscribe, RSS, HTTP, SOAP, Bandwidth, BitTorrent

With the above in mind, it’s easy to see why the world adopted XML as a primary form of data exchange. To many it seemed like a panacea. Any time I want to exchange information, XML must be the right answer because that’s what it’s built for. The problem with XML is that the community doesn’t seem as aware of it’s shortcomings as it’s benefits. There in lies the rub. It’s now being used in situations that it is not appropriate for. What if you don’t need data tools, self described data, hierarchical structures, and human readable formats. Each of those features comes at a serious cost to performance and resource utilization.

The reality of XML is that it’s a drain on performance and doesn’t scale well as a transport. Every XML message comes with a degree of bloat that is taxing on message encoding, message transmission / storage, and message decoding. Let’s take a normal XML message and compare it to some alternatives. The examples below are of a simple stock quote. I know the first three can be compressed further, but they exist to make a general point.

Standard XML - 98 Bytes w/ Tabs & UTF 8

<?xml version=”1.0″?>
<quote>
    <symbol>MSFT</symbol>
    <side>B</side>
    <price>10.00</price>
</quote>

Compressed XML  - 84 Bytes w/ Tabs & UTF 8

<?xml version=”1.0″?>
<quote>
    <data symbol=”MSFT” side=”B” price=”10.00″/>
</quote>

Tag Based - 30 Bytes

symbol=MSFT&side=B&price=10.00

Binary - 10 Bytes

A = ASCII | F = Float | B = Boolean  (Each Character Represents a Byte)

AAAAABFFFF
Note there are 5 ASCII bytes for “MSFT” because strings are variable length and require a delimiter.

So what does the above mean for real world applications. Let’s use an equities trading platform as our example application. To give you an idea of scale, message rates for market data can exceed 100,000 messages a second. Lets be conservative and say real world quotes (more complex than above) are 100 bytes each in XML, and that we have an average rate of 20,000 messages a second. Again being conservative, let’s say we can achieve a 50% reduction in message size by using an alternative format. This equates to a savings of 1,000,000 bytes a second… 58,583.75KB a minute… and 3,433.23MB an hour.

This savings in message size means reduced latency caused by message processing, reduced risk of network packet collision / retransmission, better utilization of user / kernel buffers, increased limits for services that queue unprocessed messages, and less garbage collection in Java. If you were recording incoming messages to disk, it would also decrease the amount of disk IO. Two other items to keep in mind are XML messages are hierarchical and require more complex and cpu intensive parsing and validation. This also leads to increased response latency.

Obviously not all applications are equities trading platforms, but everyone wants their application to be faster, more scalable, and cheaper. XML standards like SOAP and RSS are becoming more ubiquitous on the web and internal networks. The implications are a slower user experience, increased probability of outages, increased hardware budgets, and higher saturation of the internet and internal networks. Some companies will try to solve this problem with band aids like XML processing appliances, but I think it’s time to recognize it’s benefits and shortcomings and design our applications accordingly.

Technorati Tags: XML, Performance, Web Services, SOAP, Protocol

For the few of you wondering who I am, I’ll give you a brief run down. I started in technology at a relatively young age (around 9) with a focus on web and graphic design. I eventually moved to engineering which is where I currently spend most of my time. I’ve been a partner in two companies, one being web hosting / web development company and the other algorithmic trading in currency and equities. The rest of my time has been spent consulting or working in an engineer or business role for other companies.

I started this blog (after some peer pressure) to share some ideas on system architecture and a bit of industry commentary. I’ll do my best to keep the posts fresh and substantive. Thanks for tuning in. Good luck, good health, and Üdvözöljük.