Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
PWLBOS #1 => Christopher Meiklejohn on "A Note on Distributed Computing" #166
This is a forum for questions/comments/resources related to the PWLBOS meetup.
We will look at A Note on Distributed Computing, a technical report published at Sun Microsystems in November of 1994. This paper specifically focuses on the idea that attempting to provide a unified view of objects, whether they are local or remote, is mistaken. We will briefly discuss the history of this model, starting with the remote procedure call (RPC) mechanism, discuss the differences between non-distributed and distributed objects, and finally provide an example of lessons learned given the problems in Sun’s Network File System (NFS).
Christopher Meiklejohn is a Senior Software Engineer with Basho Technologies, Inc. and a graduate student in the College of Computing at Georgia Tech.
Off the cuff thoughts
I wanted to write these down and throw them out for commentary. I make no claim that this writing respects the opinions of my employer or even myself, but they did come to mind as I was listening and I'd love to hear what anyone else has to say. But also feel free to just ignore me /disclaimer
Mashalling v. Serialization
I did a poor job trying to talk about this w.r.t. JSON and I'd like to suggest that "marshalling", i.e. sending objects (really, codata) is essentially impossible.
Does any partial failure mentioned in the paper not depend upon distributed state? I'd sort of like to believe that without distributed state there is no notion of partial failure—or rather any partial failure can be transparently considered a total failure without any "loss". The proof sketch is just that you need distributed state in order for anyone else to know a request happened, so if the requestor just pretends like a partial failure was actually a total failure then, at the end of the day, nobody can dispute it.
Writing code that the "object should have had"
One thing Chris mentioned sort of offhandedly is that using IDs in your queue is essentially replicating entity/identity management that your "object should have had". This is, in some sense, an enormous abstracting leaking that happens in the OO mindset that entity/identity is universally manageable. Obviously light cones quickly disprove that such an abstraction could ever work as the idea simply doesn't respect causality.
So, I'm not sure I believe that "objects should have had" anything at all like entity or identity as it depends upon an acausal model of global ambient state. You just have to throw out this fundamental (well, for some models) notion of OOness entirely. Objects are still useful—but entity/identity is not as obvious as it sort of feels like it ought to be.
What is easy to map between? (Int and Char are, but other things aren't)
Chris mentioned that Int/Char are easy to map between... but more complex types are not! This is completely identical to the data/codata divide that I mentioned originally. I don't think "more complex" is the problem, but instead corecursive.
The slides are available here:
The video is available here:
If you're interested, the IEEE Internet Computing articles of mine that @cmeiklejohn mentioned in his talk are here:
There are other related ones under http://steve.vinoski.net/blog/internet-computing-columns/ as well.