[Revactor-talk] Securing Revactor Communications
randyb at cloudscale.net
Thu Jan 31 17:40:24 EST 2008
On Jan 31, 2008, at 1:33 PM, Tony Arcieri wrote:
> On Jan 31, 2008 1:21 PM, Randy Bias <randyb at cloudscale.net> wrote:
> I haven't seen any emails yet, so I'll get things started. The Actor
> model for concurrency programming solves some specific problems for
> us, but I'm concerned about inter-system communications.
> That's a big hairy issue we haven't begun to work out at all. I've
> been discussing this a little bit with MenTaLguY, and I get the
> feeling it's something neither of us feel great about addressing.
> My inclination is to start with DRb as the basis for inter-Actor
> communications, then investigate alternatives in the future. For
> example, interoperability with the distributed Erlang protocol would
> be great, as you could build systems where Erlang and Ruby
> interoperate using the distributed Actor protocol. The Scala people
> have already done this:
Interop with Erlang / Scala is appealing to me. I don't have an
immediate need, but it definitely feels important.
> Regardless I feel that encryption (if present) should be handled by
> whatever's sending data to the wire, but for a number of use cases
> no encryption will be needed whatsoever.
I agree. Local Actor communications shouldn't be encrypted. Most of
our use cases are going to require a high degree of confidentiality.
> I have been thinking about the last option the most recently. Does
> it make sense to consider XMPP for such a task? Can the addressing in
> XMPP be overloaded to address Actors as endpoints? It feels like it
> could and I can't discern a reason why this wouldn't make sense.
> I've seen interest lately in using XMPP as a general-purpose
> asynchronous messaging protocol for cloud computing, e.g.:
Yes. We've been talking about it internally since last summer, but
started with Ruby Reliable Messaging (RRM) for prototyping/
simplicity. RRM turned out to be not so reliable. Since our first
RRM implementation XMPP seems very desirable. We get a lot of 'free'
functionality using it like encryption, authentication, store/forward,
presence, etc. And it appears like a well-vetted messaging system
that deals well with unreliable networks. We looked at AMQP, etc.,
but many of the other competitors look like they assume the network is
secure or reliable, which isn't ideal.
Our product is intended to be designed for hostile, unreliable, cloud
fabrics. XMPP seems ideal for that purpose.
> My take would be that while it could be used for a distributed Actor
> protocol, it's far more complex than what's actually needed.
I'm also concerned about that and we have little experience with XMPP,
but reading between the lines it looks like at least only minimal
functionality is needed to start.
> My personal inclination remains the Erlang wire protocol, especially
> as it could provide interoperability with both Erlang and Scala (as
> well as other JVM-based languages)
This is something else I know little about. Are folks able to wrap
this in SSL?
When I'm thinking about the future of distributed computing, it seems
pretty clear to me that it will be cross-firewall. You might want to
have part of your app on EC2 for elasticity reasons, for example.
Having a clean cross-firewall protocol that includes encryption and
authentication seems critical.
What would it take to go either route? Either XMPP or Erland wire
protocol? What level of effort would be required?
Randy Bias, Founder, CloudScale
(877) 636-8589, randyb at cloudscale.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Revactor-talk