From randyb at cloudscale.net  Sat Feb  2 02:12:46 2008
From: randyb at cloudscale.net (Randy Bias)
Date: Fri, 1 Feb 2008 23:12:46 -0800
Subject: [Revactor-talk] Securing Revactor Communications
In-Reply-To: <c7e6b2b00802010120p38a6046cq750a28595d51f3eb@mail.gmail.com>
References: <96B8037F-9B6B-47B9-9629-C2906134492A@cloudscale.net>
	<c7e6b2b00801311333x45e00a52o511b5de59cdaacd7@mail.gmail.com>
	<149E9948-9E9C-45DB-BBA3-F5746E69C157@cloudscale.net>
	<c7e6b2b00802010120p38a6046cq750a28595d51f3eb@mail.gmail.com>
Message-ID: <A7885492-85CE-4F12-9010-531881818081@cloudscale.net>

On Feb 1, 2008, at 1:20 AM, Tony Arcieri wrote:
> On Jan 31, 2008 3:40 PM, Randy Bias <randyb at cloudscale.net> wrote:
> One thing to keep in mind about inter-actor communication is the  
> base requirements aren't a whole lot.  Any asynchronous  
> communication channel will do.  XMPP would certainly work...

Yes, that was my impression.  I hope you don't mind if I ask some  
possibly dumb questions about this direction.  :)

> The biggest problem right now is that I don't have immediate need  
> for a distributed Actor protocol.  I agree that there's something to  
> be said for Actors interoperating across heterogenous and possibly  
> hostile networks in a safe and encrypted manner, and that there are  
> asynchronous messaging solutions which take care of all of these  
> problems.

Perhaps we have some resources that could assist?  We could chat about  
that offline as a possibility if you are interested.

> I'm probably not going to work on distributed Actors for a bit  
> here... there's still too much to flesh out in the core  
> implementation, things like supervisors, thread safety, and a logger  
> that are really core features I'd like to have in place before  
> working on distributed networks.

Right.  That makes sense to me.  Particularly logging.  That's a big  
challenge for us in our current distributed system.  A common issue,  
I'm sure.

> I don't think that adding distribution will be terribly difficult.   
> It can be done with Marshal and the existing "packet" filter for  
> TCP.  However, thread safety will be required before distribution  
> can take place: there needs to be one distributed messaging service  
> per node, and it needs to be able to talk to all of the Actors in  
> all of the threads.  After all of that's in place we can worry about  
> transport security.

Dumb question.  Why is thread safety important if Actors are based on  
Fibers (co-routines)?  One messaging service per node makes sense to  
me.  That's our current model and they way we see XMPP being used.   
One messaging endpoint per node that can pass messages between the  
inter-node transport (remote actors) and local actors.

> So, sorry to say, it's probably a ways off...


Fair enough.

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/20080201/7eee881b/attachment.html