9 ms·

Dop: Distributed Object Protocol

86 points by creamyhorror 8y ago

0xfffafaCrash 8y ago
This looks really pretty but the protocol seems not to be well-thought-out from a cursory glance. The example itself shows a case where the non-owning nodes are out of sync with the owner node (and sitting happily in a stable state!!!) and yet actions taken (possibly based off of the out-of-sync data...) are designed to propagate into mutations for the owned state which might be completely different to begin with! Instead of discarding alterations that are made on potentially bad/stale information, the system is designed to just accept any and all changes. There isn't even a rudimentary attempt at versioning to deal with conflicts and race conditions. Instead of dealing with errors from conflicts, they're swept under the rug and mutations are applied. Anything goes! For a simple example of why that's a big problem imagine you have a state which has some boolean and an rcp that toggles that boolean which you fire based on that state (where both just want to turn it off). If two non-owning nodes say to toggle before the state has propagated from the other's change, it would turn off and back on again, cancelling each other out. If this is just meant for toy projects where the worst case scenario has no real consequences that may be fine, but the polished look of the project is what's a little scary. It looks too professional for something that simply won't work.
- josemaenzo 8y ago
  The protocol has a versioning system: https://github.com/DistributedObjectProtocol/protocol/blob/master/README.md#example-4 https://github.com/DistributedObjectProtocol/protocol/blob/m... Is the responsibility of the implementation to apply the patches/mutations in the correct order of the version.
bkeroack 8y ago
Flashbacks to CORBA.
languagehacker 8y ago
This is an interesting idea, but it's not clear to me that this is going to work at sufficient scale. This isn't clear to me because instead of getting a decent white paper on the implementation, we need to learn how this protocol works through what amounts to a PowerPoint. Sure, the slides are nice and simple, but I need more concrete answers on things like how consensus is determined and how available nodes recover from a disaster. The slides suggest that a sufficiently complex system will almost immediately get out of sync. The dependency on upstream nodes asserting state about objects before they are acknowledged and successfully applied by the "owner" node means that some subset of nodes will be working on assumptions that haven't been validated by objects they don't in fact own. This seems to conflict with what prior slides say about who can mutate objects. I think distributed object management is a useful concept, but instance state needs to be owned and managed by multiple nodes for redundancy in anything remotely approximating a production-level system. That doesn't seem to be readily addressed anywhere, either. I'd love to read more about this with the level of detail you'd need from a system that readily has use cases and reference architectures instead of possibilities.
- creamyhorror 8y ago
  Does anyone have recommendations for node packages that perform similar client-server pub/sub or even sophisticated syncing? Besides dop, DerbyJS/Racer seems to be dead, Apollo might be a solution but seems to require some setup, Meteor is too heavy, and Feathers with RxJS seems like a possibility. I'd be interested in any tools for getting easy client-server sync or reactivity.
  - bauerd 8y ago
    A coworker praised https://pouchdb.com https://pouchdb.com Apparently a client for CouchDB. Edit: Not affiliated with PouchDB, it's FOSS
    - zrail 8y ago
      PouchDB isn’t a client, it’s a whole implementation of CouchDB on top of IndexDB running in the browser or a Node server. It speaks the CouchDB sync protocol.
diegorbaquero 8y ago
Really nice implementation. I once tried to do something similar with V (npm i v) but lacked the time to continue. Hope this project grows!
lordgilman 8y ago
Where does this system of distributed objects improve from what CORBA did?
- atombender 8y ago
  This project is just about exchanging JSON data. CORBA "objects" are not pure data, but addressable RPC interfaces. Much more complex, and ultimately a bad fit for the modern web.
bastawhiz 8y ago
From the website it's unclear how nodes are authenticated. How can one node enforce access control over objects if its connection is proxied?
- josemaenzo 8y ago
  There is no authentication system in dop. You decide if a client can subscribe to a specific object: https://github.com/DistributedObjectProtocol/web/blob/master/docs/api/javascript/onSubscribe.md#nodes-have-the-object-listener-attached https://github.com/DistributedObjectProtocol/web/blob/master... The same way you would do it with plain WebSockets Also you decide what to do when a client call a specific function: https://github.com/DistributedObjectProtocol/web/blob/master/docs/guide/javascript/remote-procedure-calls.md https://github.com/DistributedObjectProtocol/web/blob/master...
- aaaaaaaaaab 8y ago
  I guess the server could sign the content.
  - bastawhiz 8y ago
    Even still, if a node is connected to the owner through another (malicious) node, how do you prevent the malicious node from making mutation requests on behalf of the legitimate node? I can see a number of ways that it can be accomplished that would take a good amount of work but it begs the question, is this worth the effort? You now have lots of security concerns, issues with nodes disconnecting, and nodes becoming overloaded. What benefit does this have over plain old fashioned AJAX? What problem does this solve?
mstade 8y ago
Is that you, CORBA? Is this me?
- DonHopkins 8y ago
  JSOAP!

86 points by creamyhorror 8y ago

This looks really pretty but the protocol seems not to be well-thought-out from a cursory glance. The example itself shows a case where the non-owning nodes are out of sync with the owner node (and sitting happily in a stable state!!!) and yet actions taken (possibly based off of the out-of-sync data...) are designed to propagate into mutations for the owned state which might be completely different to begin with! Instead of discarding alterations that are made on potentially bad/stale information, the system is designed to just accept any and all changes. There isn't even a rudimentary attempt at versioning to deal with conflicts and race conditions. Instead of dealing with errors from conflicts, they're swept under the rug and mutations are applied. Anything goes! For a simple example of why that's a big problem imagine you have a state which has some boolean and an rcp that toggles that boolean which you fire based on that state (where both just want to turn it off). If two non-owning nodes say to toggle before the state has propagated from the other's change, it would turn off and back on again, cancelling each other out. If this is just meant for toy projects where the worst case scenario has no real consequences that may be fine, but the polished look of the project is what's a little scary. It looks too professional for something that simply won't work.

josemaenzo 8y ago
The protocol has a versioning system: https://github.com/DistributedObjectProtocol/protocol/blob/master/README.md#example-4 https://github.com/DistributedObjectProtocol/protocol/blob/m... Is the responsibility of the implementation to apply the patches/mutations in the correct order of the version.

bkeroack 8y ago

Flashbacks to CORBA.

languagehacker 8y ago

This is an interesting idea, but it's not clear to me that this is going to work at sufficient scale. This isn't clear to me because instead of getting a decent white paper on the implementation, we need to learn how this protocol works through what amounts to a PowerPoint. Sure, the slides are nice and simple, but I need more concrete answers on things like how consensus is determined and how available nodes recover from a disaster. The slides suggest that a sufficiently complex system will almost immediately get out of sync. The dependency on upstream nodes asserting state about objects before they are acknowledged and successfully applied by the "owner" node means that some subset of nodes will be working on assumptions that haven't been validated by objects they don't in fact own. This seems to conflict with what prior slides say about who can mutate objects. I think distributed object management is a useful concept, but instance state needs to be owned and managed by multiple nodes for redundancy in anything remotely approximating a production-level system. That doesn't seem to be readily addressed anywhere, either. I'd love to read more about this with the level of detail you'd need from a system that readily has use cases and reference architectures instead of possibilities.

creamyhorror 8y ago
Does anyone have recommendations for node packages that perform similar client-server pub/sub or even sophisticated syncing? Besides dop, DerbyJS/Racer seems to be dead, Apollo might be a solution but seems to require some setup, Meteor is too heavy, and Feathers with RxJS seems like a possibility. I'd be interested in any tools for getting easy client-server sync or reactivity.
- bauerd 8y ago
  A coworker praised https://pouchdb.com https://pouchdb.com Apparently a client for CouchDB. Edit: Not affiliated with PouchDB, it's FOSS
  - zrail 8y ago
    PouchDB isn’t a client, it’s a whole implementation of CouchDB on top of IndexDB running in the browser or a Node server. It speaks the CouchDB sync protocol.

diegorbaquero 8y ago

Really nice implementation. I once tried to do something similar with V (npm i v) but lacked the time to continue. Hope this project grows!

lordgilman 8y ago

Where does this system of distributed objects improve from what CORBA did?

atombender 8y ago
This project is just about exchanging JSON data. CORBA "objects" are not pure data, but addressable RPC interfaces. Much more complex, and ultimately a bad fit for the modern web.

bastawhiz 8y ago

From the website it's unclear how nodes are authenticated. How can one node enforce access control over objects if its connection is proxied?

josemaenzo 8y ago
There is no authentication system in dop. You decide if a client can subscribe to a specific object: https://github.com/DistributedObjectProtocol/web/blob/master/docs/api/javascript/onSubscribe.md#nodes-have-the-object-listener-attached https://github.com/DistributedObjectProtocol/web/blob/master... The same way you would do it with plain WebSockets Also you decide what to do when a client call a specific function: https://github.com/DistributedObjectProtocol/web/blob/master/docs/guide/javascript/remote-procedure-calls.md https://github.com/DistributedObjectProtocol/web/blob/master...
aaaaaaaaaab 8y ago
I guess the server could sign the content.
- bastawhiz 8y ago
  Even still, if a node is connected to the owner through another (malicious) node, how do you prevent the malicious node from making mutation requests on behalf of the legitimate node? I can see a number of ways that it can be accomplished that would take a good amount of work but it begs the question, is this worth the effort? You now have lots of security concerns, issues with nodes disconnecting, and nodes becoming overloaded. What benefit does this have over plain old fashioned AJAX? What problem does this solve?

mstade 8y ago

Is that you, CORBA? Is this me?

DonHopkins 8y ago
JSOAP!