What is Vsync and why would I even consider using it?

Vsync is a software library for building cloud computing solutions that use data replication in various ways. It can also be used in wide area networks or on computer clusters. However, it can only be used in settings where you won't need availability on both sides of a partitioned network link. This is really our main limitation and is basic to the "model" we support, namely virtual synchrony.

Because Vsync is really a renamed version of a system we used to call Isis2 (sometimes Isis2 if superscripts weren't available), it may take a while for us to eliminate all mention of Isis from the documentation, videos and examples. We'll do that but meanwhile, some mental editing may be needed. If you notice Isis anywhere, just say to yourself "now that would be Vsync" and that should do the trick!

Our Introduction to Vsync is old, but is still a good place to start if you are new to the topic. Also valuable and perhaps even better is the Introductory video, but it isn't short (if you like videos but want them to be short, there are a few on the introduction page too . But those are a bit old now and won't mention some of the recent features in the system).

What's new?

If you click to our What's new? page, you'll find a summary of the main recent developments.

Instructional videos for Vsync

Early in 2014, we created about 10 hours of video materials showing how the system works and how to use it, step by step, with accompanying slides. This is perhaps the best documentation for new users of the system; we recommend it highly. Click here for the Video materials.

Traditional written materials

  1. Basic written documentation and materials Download our user manual, and our online "man" pages (the usual per-API documentation, auto-generated by C# from our code and comments).
  2. A short set of notes aimed at people who plan to work with Python. Cannot resolve file macro, invalid file name or id.
  3. A short set of notes aimed at Linux users. Cannot resolve file macro, invalid file name or id.
  4. Vsync works well from a version of C++ with a few extensions to talk to .NET; this explains how that works. Using Vsync from C++/CLI on .NET

Project Suggestions

We've placed suggestions for projects of various sizes here: Project suggestions


Vsync works well on Mono, but there are some magic incantations required to set it up on that platform. Learn about them on the Mono suggestions page.

Computers with multiple network interfaces.

If you use Vsync on a computer that interfaces to multiple network devices, you should read this page, which offers suggestions about how to tell Vsync how to configure itself.

Short Video highlights about the system

The short video highlights page is probably outmoded by the newer Video materials page. But we've presented it for you anyhow.

Graphical API for Vsync

Our Live Distributed Objects platform is a great match to Vsync and can be used to create mashups with live content that updates in a replicated way as events occur. The original Live Distributed Objects code doesn't compile on the most recent .Net releases, but you can find a version that does compile on Live Distributed Objects for GridCloud.

Release status:

Vsync is available for public use now, and very stable. While the system should not be used out of the box in safety-critical settings, we have no hestitation in recommending that people consider it for less sensitive purposes. With further Q/A, which you would need to undertake at your own expense, it should also be possible to apply it even in more demanding settings.

But we do want to stress that although Vsync is aimed at high-assurance use cases, our testing process at Cornell isn't as rigorous as we would recommend for uses that are safety or life-critical. While our Isis Toolkit did make it to a QA level at which it could be used in air traffic control and similar settings, that was an expensive process and would need to be repeated for Vsync before it could be deployed in similar settings.

Ronald Reagan once remarked "trust, but verify" in connection with an arms agreement. We recommend that you view our system that way, too. We did our best when implementing it and even testing it, yet we simply didn't have the resources to test at the level needed for life or safety critical uses. Thus we don't rule out use of Vsync in such settings, but the key to safety is for you to carry out a Q/A process of your own, covering all elements of your solution. Feel free to contact Ken at Cornell for help designing this sort of application-specific quality assurance testing procedures.

If your team has the resources to do the needed exhaustive testing, we for our part will be happy to fix any problems you uncover, and your system should then be as safe as any other mission critical computing system.

If this sounds like a qualified guarantee, and it should, my point is that no amount of testing can really achieve perfect reliability, security or fault-tolerance. After all, there is the FLP theorem to think about, which proves that there will always be conditions (perhaps rare) under which progress cannot be guaranteed if a system must tolerate faults but also preserve consistency. Vsync is subject to such limits just as would be any product or system of this kind. We've tried to make those conditions as rare as possible, of course, but one can't circumvent a hard limit. For us, FLP would manifest during certain patterns of partitioning failure, which are unlikely in data center settings but might be more easily provoked in a WAN environment (this is one reason we haven't focused on using Vsync in WAN settings).

This is why any safety or life-critical system must be designed to be failsafe, in the sense that if your application experiences too many failures, or one of these "impossible to work around" patterns of network connectivity disruption, the application should come to a halt, and that halt shouldn't endanger the health or safety of human users or expensive equipment. This is how one approaches the design of complex systems for air traffic control or electric power grid management: with extensive, exhaustive testing of the entire system (Vsync included), and even then, by designing the solution to be failsafe. And let's face it: we're working with hardware; it needs power and cooling and has components like storage systems that can also fail. Anyone who pretends they can build a perfectly reliable system without testing and without thinking through these last-resort safety arguments would be lying to you!

Last edited Nov 14, 2015 at 2:11 PM by birman, version 1