[Revactor-talk] Securing Revactor Communications

Randy Bias 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:
>
> http://www.theserverside.com/tt/articles/article.tss?l=IntegratingJavaandErlang

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.:
>
> http://www.jivesoftware.com/community/blogs/jivetalks/2008/01/24/xmpp-aka-jabber-is-the-future-for-cloud-services

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?


Thanks,



--Randy



Randy Bias, Founder, CloudScale
(877) 636-8589, randyb at cloudscale.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/revactor-talk/attachments/20080131/176833a7/attachment.html 


More information about the Revactor-talk mailing list