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?
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.
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.
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.
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.
music and videos).
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, 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.
Former author of LinuxICE, nghost.
Current author of nobdy.