I used to work for the company that Riverbed was founded to compete with. My favourite party trick was to show new and interesting ways Riverbed could corrupt your data with their CIFS/SMB implementation.
Essentially their technical problem was they defaulted to passing commands through that there wasn't explicit code to detect (by default assume harmless). For example they claimed to support every CIFS client & server out there rather than only ones that had actually been thoroughly tested. Another example is they didn't detect the commands to zero out sections of a file so any app that did that would end up with the wrong data returned or in the file. (As a contrast we only supported actual client and server combinations that had been tested. On encountering a command not in a whitelist we immediately discarded all cached information.) One week I came up with 5 different corruptions they caused. We published one of them with Riverbed then threatening to sue claiming some violation of their user agreement!
Another example is the code had also been written by a bunch of Linux people which means they didn't work correctly with alternate data streams. These leak into the file name space and again affect caching and similar issues. http://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28...
I would be ashamed to have taken the technical approach they did, and treated customer data integrity as prime importance. Riverbed wanted marketshare and took shortcuts. Of course most people on encountering file issues with Windows end up blaming Windows so they wouldn't realise their WAN optimiser is actually at fault.
In other respects they did make some good choices. They chose to only accelerate TCP instead of IP as we did, which makes setup and auto discovery considerably easier since you can treat each TCP stream in isolation from the others and put your signalling inline into the stream. They also configured their systems to have some swap available. This provides an escape valve should worst case scenarios happen. Our system was RAM based only which meant code had to be very careful to not end up in a scenario where you need more RAM. This was done by being conservative and preallocating RAM. (You have systems at either end of a connection and they will have expectations of each other - eg that data can be decompressed and already exists in a compression dictionary.)
Their marketing was excellent as they correctly realised people would be reluctant to discard something already deployed, and would instead keep adding more of the same (sunk cost issues). They rapidly built up a customer base of many small customers and that was a good foundation for growth.
The company I worked for was acquired by a large company who then mismanaged it into the ground. Riverbed are pretty much the only ones left standing. I wouldn't touch their stuff due to very different technical tastes - but that hasn't affected their customer base and YMMV.
I think you can't compare those two. at least not in fair apples vs apples way, simply because it is free/open source vs quite expensive/proprietary product.
Comments
We use a Riverbed appliance for this at work (http://www.riverbed.com/us/solutions/wan_optimization/). Would love to see a comparison on ease of setup, stability, and optimization benchmarks, if anyone knows of one.
I used to work for the company that Riverbed was founded to compete with. My favourite party trick was to show new and interesting ways Riverbed could corrupt your data with their CIFS/SMB implementation.
Essentially their technical problem was they defaulted to passing commands through that there wasn't explicit code to detect (by default assume harmless). For example they claimed to support every CIFS client & server out there rather than only ones that had actually been thoroughly tested. Another example is they didn't detect the commands to zero out sections of a file so any app that did that would end up with the wrong data returned or in the file. (As a contrast we only supported actual client and server combinations that had been tested. On encountering a command not in a whitelist we immediately discarded all cached information.) One week I came up with 5 different corruptions they caused. We published one of them with Riverbed then threatening to sue claiming some violation of their user agreement!
Another example is the code had also been written by a bunch of Linux people which means they didn't work correctly with alternate data streams. These leak into the file name space and again affect caching and similar issues. http://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28...
I would be ashamed to have taken the technical approach they did, and treated customer data integrity as prime importance. Riverbed wanted marketshare and took shortcuts. Of course most people on encountering file issues with Windows end up blaming Windows so they wouldn't realise their WAN optimiser is actually at fault.
In other respects they did make some good choices. They chose to only accelerate TCP instead of IP as we did, which makes setup and auto discovery considerably easier since you can treat each TCP stream in isolation from the others and put your signalling inline into the stream. They also configured their systems to have some swap available. This provides an escape valve should worst case scenarios happen. Our system was RAM based only which meant code had to be very careful to not end up in a scenario where you need more RAM. This was done by being conservative and preallocating RAM. (You have systems at either end of a connection and they will have expectations of each other - eg that data can be decompressed and already exists in a compression dictionary.)
Their marketing was excellent as they correctly realised people would be reluctant to discard something already deployed, and would instead keep adding more of the same (sunk cost issues). They rapidly built up a customer base of many small customers and that was a good foundation for growth.
The company I worked for was acquired by a large company who then mismanaged it into the ground. Riverbed are pretty much the only ones left standing. I wouldn't touch their stuff due to very different technical tastes - but that hasn't affected their customer base and YMMV.
I think you can't compare those two. at least not in fair apples vs apples way, simply because it is free/open source vs quite expensive/proprietary product.