
OpenNOP is an open source Linux based network accelerator - hypnotist
http://www.opennop.org
======
hypnotist
OT: I submitted this because, I was just looking for some open source project
in WAN optimization .. and it is really hard to find something, because in
google search there is only one project which is annoyingly dominates search
results(my guess because of SEO).

Another project: <http://wanproxy.org>

But still this space is heavily owned by big corps. I guess smart
developers/startup could find some real market here.

~~~
rogerbinns
Some of those big corps did start out as startups. It is a very hard space to
play in especially if software only. With hardware based approaches you just
put the boxes inline and that is it. Note that the hardware boxes also do
things like have a dual ethernet port card with a relay in it. If the box
loses power then the ports are joined together so it still acts as a
passthrough. (Our box also had a watchdog that had to be tickled every 2ms by
software otherwise the relay would also kick in.)

The network infrastructure needs to be configured to divert traffic to the
boxes which is fiddly and becomes a support load very quickly. If SSL forms
part of the traffic you want to accelerate then there are two approaches
either of which require even more system administration (not network
administration).

Once a customer is non-trivial (eg 3 or more offices) then suddenly the sales
process slows down drastically as the same product has to be used everywhere
and supported by the networking and software people.

What this means is that if you are competing conventionally then it is very
hard against the now entrenched vendors. If you are trying to be open source
then you will find a very long hard and extremely likely to be an unrewarding
slog. Many of the small vendors were out proving the space when the big corps
all realised they needed an offering, and did all the acquisitions. The
changes of being acquired are very slim now.

~~~
hypnotist
Thanks for the extensive comments.

What do you think about Silver Peak virtual WANOP solution ?

~~~
rogerbinns
> What do you think about Silver Peak virtual WANOP solution ?

No idea. However they aren't a small startup/open source solution like you
were originally looking for! Pretty much everyone's solution is written as
software that runs on Linux (sometimes BSD). That then gets packaged up on an
hardware appliance, suitably tested, marked up and sold.

Consequently not much is needed to make a virtual appliance, although testing
is harder as configurations are more diverse. In other words it is likely to
be substantially in behaviour to hardware appliances (unless they deliberately
exclude things to protect hardware appliance sales).

------
bjt
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.

~~~
rogerbinns
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...](http://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28ADS.29)

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.

------
yaplej
Thanks for sharing :)

