3 ms·

Sorry, but you're massively underestimating the problem here. There's a whole lot more to it than "they could all keep their own copy." Reliable distributed co

by kentonv 10y ago

Sorry, but you're massively underestimating the problem here. There's a whole lot more to it than "they could all keep their own copy." Reliable distributed consensus without a "master" node is one of the hardest problems in computer science even when all the computers are always-on servers located on the same network. When we're talking about random laptops and phones all over the world that flicker in and out of connectivity -- and you want real-time collaborative responsiveness, and you have users who are not allowed to see the whole data set -- you're deep in unsolved problem territory. If and when someone builds a real system that can handle this, performs well in real-world network scenarios, and is easy enough for typical application developers to use... then we can start the arduous process of rewriting all of our applications to use this model. Instead of all this, Sandstorm aims to make it easy for everyone to have their own general-purpose server (maybe by using their own physical machine, maybe by paying a hosting service). This way we can keep using our existing code and existing application development practices.

jessaustin 10y ago
All true, except you're really just hiding the problem behind an abstraction. If you want to have a reliable server instead of just a server, then you want more than one server. And now you're back to your massively complicated problem, if you insist that all servers are equal. Of course, you don't have to make that assumption, neither on the server side nor in the peer model. Just say that the peer who created the document is the "server" (or use any other reasonable way to determine this), and when other peers have a copy that disagrees, then they update their copy. Now it's just like talking to a real server, except it happens to be another peer. Go ahead and use If-Match, 412, etc. (...or the equivalents in whatever protocol makes sense, of course) Such an immediate jump to a massive-scale solution for a few to at most a dozen hosts talking amongst themselves is a classic YAGNI.
- kentonv 10y ago
  You are equating the reliability of a server machine with the reliability of a user's client machine, when in reality these are not remotely similar. Laptops are regularly suspended and move between networks, losing connectivity. Phones even more so. Consumer internet is unreliable, usually with poor outgoing bandwidth. Mobile networks even more so. Etc. When I share a document with five coworkers then close my laptop, the others need to be able to keep working. Under your model, that means they'd need to choose a new server. Guess what? This means you now need a consensus protocol. One where partitions happen 1000x more often, it is regularly necessary to operate without a quorum, latency is high and totally unpredictable, and all kinds of other properties that make the problem exponentially harder.
- ZoF 10y ago
  Entirely disagree with you here: -Nowhere was it insisted that all servers are equal. -Most people would prefer a hosted solution to hosting one locally(not constantly using their local machines resources) -For many apps the performance and uptime of a server is of enough importance that this simply wouldn't work. -A hosted solution provides a stable controlled and relatively unchanging environment, depending on what else you use that box for. -Unless there's guaranteed uptime(which there isn't in this case) you have even more merging headaches. (read 4 slave-peers(not really even 'peers' in this context) all have different diffs after a week of the master being offline) -Putting an app on a box somewhere isn't a 'massive scale solution'. >If you want to have a reliable server instead of just a server, then you want more than one server. No. Not for a personal or small app you don't. You can have 'reliable hosting' (say one of the many VM providers backed by solid hardware and a RAID tolerant to multiple drive failures). Reliable doesn't mean completely immune to failure, and you're underestimating the reliability if you think this is a regular occurrence. Your average hosting provider offers orders of magnitude more reliability than any users local PC or mobile(even if we're talking a constantly online desktop with wired ethernet). It's just a ridiculously complicated thing your asking for here while simultaneously dismissing the parent comment as 'hiding the problem behind an abstraction'.
- jessaustin 10y ago
  Hahaha thanks everyone there's lots here for me to consider. The peer model is probably better suited to ephemeral stuff like gaming than to document collaboration. What I'm wondering now is, where is sandstorm going to run? If it's on AWS like everything else, I guess I misunderstood the point...
  - kentonv 10y ago
    Sandstorm runs wherever you want it to. You can run it on your own physical machine -- even your desktop, if it's always-on. A lot of people run Sandstorm on Digital Ocean. The company also provides Sandstorm Oasis (oasis.sandstorm.io) which is provided as a service. Wherever you run Sandstorm (including Oasis), you as a user can upload and install any package, including ones you built yourself. Thus it accomplishes the goals in the blog post, even if physically the servers are "centralized".
  - reitanqild 10y ago
    > What I'm wondering now is, where is sandstorm going to run? It already runs and has been running in production for months, both as a hosted server and in various basements etc. Source: small-time backer, ran it on my desktop almost without a hitch for a few weeks or months from the start until I could get a hosted account.
    - kentonv 10y ago
      > It already runs and has been running in production for months Actually 2.5 years now. :) (And Oasis has been up for a little over a year.) Time flies...

by kentonv 10y ago

jessaustin 10y ago

All true, except you're really just hiding the problem behind an abstraction. If you want to have a reliable server instead of just a server, then you want more than one server. And now you're back to your massively complicated problem, if you insist that all servers are equal. Of course, you don't have to make that assumption, neither on the server side nor in the peer model. Just say that the peer who created the document is the "server" (or use any other reasonable way to determine this), and when other peers have a copy that disagrees, then they update their copy. Now it's just like talking to a real server, except it happens to be another peer. Go ahead and use If-Match, 412, etc. (...or the equivalents in whatever protocol makes sense, of course) Such an immediate jump to a massive-scale solution for a few to at most a dozen hosts talking amongst themselves is a classic YAGNI.

kentonv 10y ago
You are equating the reliability of a server machine with the reliability of a user's client machine, when in reality these are not remotely similar. Laptops are regularly suspended and move between networks, losing connectivity. Phones even more so. Consumer internet is unreliable, usually with poor outgoing bandwidth. Mobile networks even more so. Etc. When I share a document with five coworkers then close my laptop, the others need to be able to keep working. Under your model, that means they'd need to choose a new server. Guess what? This means you now need a consensus protocol. One where partitions happen 1000x more often, it is regularly necessary to operate without a quorum, latency is high and totally unpredictable, and all kinds of other properties that make the problem exponentially harder.
ZoF 10y ago
Entirely disagree with you here: -Nowhere was it insisted that all servers are equal. -Most people would prefer a hosted solution to hosting one locally(not constantly using their local machines resources) -For many apps the performance and uptime of a server is of enough importance that this simply wouldn't work. -A hosted solution provides a stable controlled and relatively unchanging environment, depending on what else you use that box for. -Unless there's guaranteed uptime(which there isn't in this case) you have even more merging headaches. (read 4 slave-peers(not really even 'peers' in this context) all have different diffs after a week of the master being offline) -Putting an app on a box somewhere isn't a 'massive scale solution'. >If you want to have a reliable server instead of just a server, then you want more than one server. No. Not for a personal or small app you don't. You can have 'reliable hosting' (say one of the many VM providers backed by solid hardware and a RAID tolerant to multiple drive failures). Reliable doesn't mean completely immune to failure, and you're underestimating the reliability if you think this is a regular occurrence. Your average hosting provider offers orders of magnitude more reliability than any users local PC or mobile(even if we're talking a constantly online desktop with wired ethernet). It's just a ridiculously complicated thing your asking for here while simultaneously dismissing the parent comment as 'hiding the problem behind an abstraction'.
jessaustin 10y ago
Hahaha thanks everyone there's lots here for me to consider. The peer model is probably better suited to ephemeral stuff like gaming than to document collaboration. What I'm wondering now is, where is sandstorm going to run? If it's on AWS like everything else, I guess I misunderstood the point...
- kentonv 10y ago
  Sandstorm runs wherever you want it to. You can run it on your own physical machine -- even your desktop, if it's always-on. A lot of people run Sandstorm on Digital Ocean. The company also provides Sandstorm Oasis (oasis.sandstorm.io) which is provided as a service. Wherever you run Sandstorm (including Oasis), you as a user can upload and install any package, including ones you built yourself. Thus it accomplishes the goals in the blog post, even if physically the servers are "centralized".
- reitanqild 10y ago
  > What I'm wondering now is, where is sandstorm going to run? It already runs and has been running in production for months, both as a hosted server and in various basements etc. Source: small-time backer, ran it on my desktop almost without a hitch for a few weeks or months from the start until I could get a hosted account.
  - kentonv 10y ago
    > It already runs and has been running in production for months Actually 2.5 years now. :) (And Oasis has been up for a little over a year.) Time flies...