While this will be included as part of an OpenMobile plugin, it is fully open source and is designed to be used stand alone with any operating system or front end.
What is it:
Open Sync is a protocol, a server and a client library. All of which are open source and fully documented. It is designed to sync files between a "sync server" and a carPC. This server can be located on a local network, a remote network or even across the internet.
- Fully extensible -can have extensions and functionality added without any change to its design
- Secure - The protocol supports salted password exchange and optionally even SSL transactions to ensure your data remains safe even when traveling through unprotected connections.
- Zero Configuration - This entire setup can be deployed with no end user configuration required. The client automatically finds the server on the network and syncs files without any setup required. It uses a variety of methods including UPnP and UDP broadcasts to ensure this works locally, over wifi, through firewalls and even over the internet. No mapping drives or editing config files required.
- Platform Neutral - The server and client library are written in C# to ensure they can be run on Windows, Linux or OSX. The protocol is open source to allow anyone to create platform specific implementations in their favorite language.
- Fast - the protocol automatically scales to the capabilities of the current connection. While on wifi, files are transferred with no overhead to ensure maximum transfer speed. Over a cellular connection, various compression algorithms (including gzip and LZMA) are used to minimize bandwidth usage and maximize transfer speed. The LZMA extension for example, can transmit ~500kb/s over a 100kb/s connection.
Expected public release: Dec 1, 2010
Anyone interested in developing their own implementations or helping with the design are welcome to contribute.
It has to be asked, but why would this protocol be a choice for developers over any of the already mature open source file sync protocols?
Name some and I can tell you the exact differences but mainly, none of them can do what this can.
Originally Posted by malcom2073
CarPCs are a special use case... you could be using a local wifi connection or you could be using a tethered cell phone. A bloated language like syncML would not only destroy your transfer cap it would be very very slow. Other alternatives like KDEs OpenSync are not designed for binary transfer (like music). Even LDAP suffers from being too generic, unstandardized and most importantly it doesn't support compression.
I guess I'm curious as to what it can do that unison or rsync cannot?
SSL is a plus, but I'm never scared that someone is watching me and/or sniffing packets of music I'm transferring. Good for others I guess.
rsync seems like a sensible mature tool that does all this, but better.
Among other things, it also does differential file copying as well as compression; for the initial copy, rsync will be roughly the same speed as anything else. For subsequent copies, it would blow this out of the water, surely? This is PhD thesis material, analyzed in massive depth beyond "I anticipate a five times compression ratio"...
Password exchange is so passe. For that matter, passwords are so passe :-(
You can also use public key authentication with rsync, meaning passwords are unnecessary. VNC has fallen from grace in the circles I travel in, thanks in large part to difficult-to-verify password trust - you're implementing something like VNC's password mechanism, but weaker.
I'll give you server-discovery, but bonjour and friends are open [hell, even nmbd can do that part], so you could do that trivially. Also it would presumably make more sense to have the car automatically pull rather than to try to push to it, which I assume would be the point of discovery.
I also do not entirely concur that C# is platform-neutral right now. RSync runs on *anything*. C# and mono, not so much. But we've had that argument before and I suspect neither of us is going to budge viewpoint.
I mean, overall... I always think it's good to try and implement this stuff. But at some point, if you really want to use this for practical stuff rather than academic implementing interest, just use the existing mature tools.
First 4 that come to mind:
Originally Posted by Tidder
- require no configuration (instead of batch scripts you have to edit anytime the server ip changes)
- safely works over the internet
- Work on systems other then unix (windows syncing with a linux server)
- Can be extended with optional extensions like playlist syncing or FE plugin updates
So I can load it on two computers and sync things without *any* configuration? Impressive, how does it know what I want synced?
rsync and unison both have windows, mac, and linux builds, and some nice GUIs. (DeltaCopy for rsync under windows, linux there are a handful, mac I don't know; unison has it's own)
Interested in the extensions and plugins.
The only thing rsynx does that I haven't done yet is differential compression. Its actually not as difficult as you would think (especially since the rsync algorithm can be used) it just is phd level material to optimize. In either case it would have little value here since file changes will be rare and files added or removed will be far more common (unless you plan on editing your pictures, music and videos).
Originally Posted by chunkyks
Salted password exchange is the basis for the linux password algorithm so I would hardly call it weak or passe. Untrusted public keys are just as insecure as untrusted passwords... in either case generating a public key and generating a password are just as easy to do...the difference is public key exchange requires either manually copying it to the client (which makes it exactly the same as a password) or insecurely grabbing it from the server. If implemented in the latter fashion preshared keys (passwords) are actually more secure.
Yea great bonjour can discover services but not this service. Implementing all of bonjour for something that can be done in a few lines adds bloat without value. Not to mention the protocol would have to be modified to support this which would rule out existing libraries. We use UPnP for network discovery which is a far more prevalent protocol (yes i realize different use cases).
C# and mono runs on anything rsyanc runs on - unix and its variants (including osx) and windows. I know of no rsync implementation for any other platform. Regardless, its an open protocol that can be implemented on whatever platform in whatever language you want.
Basically, not all of us run a linux console in our cars and operate our cars via keyboard. The goal here is a system that just works and adapts to the conditions a carPC faces. Combinations of scripts and various programs not designed for this use case is just taking the riderunner approach to things. If you have to leave your favorite front end because your server ip changed or wifi dropped and you need to tether a phone-the carPC concept has failed.
i love this idea. If possible can you allow maximum size allowed over non wifi connections?
ie. allow maximum 500MB over 3g connection per month, or something like that?
So that you won't go totally over your connection limit.
So what I gather is, existing sync protocol XYZ doesn't have a discovery ability so that is why the world needs OpenSync? I like the idea of no configuration and works-out-of-the-box. I'm just worried this little side project will go the way of OpenOBD... It's fun having a diverse number of side-projects but eventually, you realize that you are just one man and one man can only do so much before he's overwhelmed.
Originally Posted by justchat_1
So, with that in mind... I'd just write a frontend to rsync that uses the SDP of the UPNP spec and be done.
Also, there are a lot of reasons why a system wouldn't want to use mono. I like mono, but OEMs are likely thinking twice about it after that whole thing with Tomtom and Fat32. Also there also is the size excuse which Fedora now uses as an excuse not to include mono or anything that uses mono in its default installation.