Thank you for the pointer to the paper Mark, it was an interesting read. We're keeping an eye on Ken as it seems promising for implementing distributed actor configurations. NodeKen would be interesting. Do you think that one actor per Node.js process would be necessary if you had a JavaScript engine written using actors with object-capability?
Thank you for the reminder about web-keys (referenced in the paper). I always wondered what is the protocol for revoking long-lived "swissnums" that might get guessed/compromised? Also, I noticed mention of using TLS for NodeKen. Is DTLS not feasible/unsupported? Cheers, Tristan On Monday, August 12, 2013 4:19:13 PM UTC-5, MarkM wrote: > > [+cutsem, +btulloh] > > Hi Tristan, you may be interested in a recent paper on Dr. SES by Tom Van > Cutsem, Bill Tulloh, and myself: < > http://research.google.com/pubs/pub40673.html>. In it we explain our > plans and hopes for Dr. SES, (Distributed Resilient Secure EcmaScript). I > say hopes because part of this depends on another project, NodeKen, that we > hope to be the successor to v8Ken <https://github.com/supergillis/v8-ken>, > but which is not currently in active development. (Tom, is this true?) For > NodeKen and Dr. SES, we expect we would proceed with one Node process per > actor, at least at first, since performance is not currently a priority for > this work. > > > > On Mon, Aug 12, 2013 at 6:39 AM, Tristan Slominski > <[email protected]<javascript:> > > wrote: > >> I've been working on this type of problem from different angles for a few >> years now. >> >> On top of Node.js it is relatively easy to build an actor framework, >> especially if you are familiar with actor patterns and how actors should >> communicate. >> >> I don't understand what problems you hope to solve with the actor model >> that don't fit a single event loop pattern? Actors are concurrent, any >> actor solution ought to be implementable on single event loop, perhaps not >> as efficiently as would be possible otherwise in Node.js. Do you have >> specific examples of synchronous operations that cannot be made >> asynchronous? This also refers to your other comment. What is the reasoning >> behind actors running in isolated event loops? Concurrency can be >> accomplished on one event loop. Are you looking for parallelism? >> >> What is the purpose of work-stealing scheduler? Is that where you need to >> start? Perhaps a design with a simple scheduler that can later be upgraded >> independently would be easier to do initially? >> >> I would say that one of your missing criteria is Object Capability ( >> http://en.wikipedia.org/wiki/Object-capability_model). This is missing >> in Akka for sure, I think it is also missing in Erlang but I'm not as sure >> about that one. A good place to start is to make actor addresses >> unforgeable and force explicit actor address passing in messages (no >> implicit "sender" in messages). This enables you to reason (in mathematical >> proof sense) about security of your actor configuration. If you find >> yourself getting actors by name (from a string), you've lost object >> capability. This is not to be confused with externally known "receptionist" >> actors, there's a somewhat crowbar separation there. >> >> As far as how to break up actors so that they perform reasonably on >> Node.js, (and perhaps this is what you mean by running them in multiple >> event loops) actors that end up working together, tend to form what's >> commonly referred to in literature as actor configurations. You can think >> of configurations as somewhat analogous to linux control groups, that is, >> they can be sponsored with a fixed amount of resources (technically, every >> single actor can be sponsored, but it seems configurations are a better >> "batch size"). You could run a lot of configurations on the same event >> loop, but then, you could start multiple processes with actor >> configurations of their own. This is how you could start to abstract >> computation in a way that would be meaningful and bound to hardware >> resources that you have. This is also how you could start moving toward >> running untrusted code and actor isolation. >> >> Once you figure out how to comfortably scale on one machine, perhaps >> using multiple Node.js processes each running multiple actor >> configurations, then you'll have to solve the problem of actors being able >> to talk to actors on other machines. The >> centralized/single-point-of-failure way of doing that is relatively >> straightforward. I'm more interested in how to do it in a decentralized >> way. I have a project that is getting near ready to be tested that is an >> attempt at solving that (sort of Node.js userspace ZMQ-like point-to-point >> with Kademlia DHT discovery mechanism). >> >> I'm happy to talk at length about this stuff and perhaps collaborate. >> Ping me if you'd like. >> >> Cheers, >> >> Tristan Slominski >> Github: https://github.com/tristanls >> Twitter: @tristanls >> >> >> On Sunday, August 11, 2013 5:38:31 PM UTC-5, Kevin Swiber wrote: >>> >>> I'm contemplating an experiment to bring an Erlang-like "process" model >>> to Node.js. >>> >>> I'm curious if anyone has been down this path before or if there's prior >>> art I haven't stumbled upon yet. >>> >>> Background: I've been working with Node for a couple of years now. The >>> default answer to multi-threading Node is "don't do it." This experiment >>> challenges that advice. There are many benefits to multi-threading, though >>> they admittedly bring features not promised by Node core. I'm fine with >>> that. >>> >>> Inspiration: Erlang implements an Actor model for concurrency. A >>> process running in Erlang's VM runs on a thread underneath the covers. The >>> VM implements a work-stealing task scheduler to manage the load >>> effectively. From here on out, I'll refer to the "Erlang process" style >>> pattern as an Actor. (Note: I'm no expert in Erlang. Some of this might >>> be wrong. :) >>> >>> The Node event loop is powerful, but unfortunately, not all operations >>> are asynchronous in nature. For problems whose solution does not fit the >>> single event loop pattern, I'd like to see an alternative emerge. >>> >>> Current thinking on design: >>> * Actors should have access to all Node's capabilities. >>> * Actors should run in isolated event loops. >>> * Actors should communicate via message passing. >>> * No shared state. >>> * Actors should take advantage of a V8 Isolate. >>> * A work-stealing task scheduler should be implemented under the covers. >>> * Actors can spawn other actors. >>> >>> The scheduler seems like one of the hardest pieces to implement (IMHO). >>> For that, it might be worth investigating Intel's Threading Building >>> Blocks[1] or the Cilk project[2]. >>> >>> Ideally, this could all be accomplished via modules without rewriting >>> any part of Node core. >>> >>> So... what am I missing? Is there a giant hurdle that makes this nearly >>> impossible? Distributed systems made of actors using arbitrary >>> computational complexity and having the ability to take advantage of the >>> Node ecosystem seems very compelling to me. >>> >>> [1] >>> http://**threadingbuildingblocks.org/<http://threadingbuildingblocks.org/> >>> [2] >>> http://supertech.csail.**mit.edu/cilk/<http://supertech.csail.mit.edu/cilk/> >>> >>> Cheers, >>> >>> -- >>> Kevin Swiber >>> Projects: https://github.com/kevinswiber >>> Twitter: @kevinswiber >>> >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Text by me above is hereby placed in the public domain > > Cheers, > --MarkM > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
