Re: NEWB: How to get started on writing new client?

On Tue, Nov 27, 2007 at 05:47:12PM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 27, 2007 at 12:19:17AM -0500, Nic Watson wrote:
> > Along those lines, I hit across another solution by pure serendipity
> > this weekend:
> > <http://vde.sourceforge.net/>
> > "VDE is an ethernet compliant virtual network that can be spawned over a
> > set of physical computer over the Internet."
> 
> Yes, I also noticed this could be of help, I need to look into it.
> 
> btw, the project leader is my ex professor of operative systems, he's
> a few kmt away from my place and I know him well.

I looked into it, it seem to fit CPUShare needs nicely. I'm a bit
concerned about the security, think one malicious KVM using a
duplicate mac address, that's not too nice in a ethernet network, it'd
be better if this was only a routing where only the IP address
matters. OTOH with this model even samba will work out of the box with
broadcast messages, you can ping the broadcast to see all ip
connected, etc... But I think a "tun" routing model would be more
secure than this "tap" bridging model of vde. I'd rather have CPUShare
assign IP and not mac addresses.

The full interconnected switches are also apparently supported with
the fast fast spanning tree switch:

    http://wiki.virtualsquare.org/index.php/Fast_Spanning_Tree_Protocol

However I'm not sure if this will require changes for the internet,
the idea is not to have a master switch but to find the shortest path
to reach a certain virtual mac-address. The mac-addresses of course
will be decided by the CPUShare server. Initially I'll route all
traffic through the master switch in the server.

vde_cryptcab will be the wire between the buyer and sellers
switches. The buyer switch will run the cryptcab server and it will
act a switch to connect all clients together. However there are a few
details that needs to be addressed even in this simple not fully
interconnected model, that is the cryptcab protocol needs a
keepalive. The keepalive should also notice in a few minutes if a
client is down, mostly like openvpn keepalive packet does (it also
keep the UDP NAT conntracking alive so the server can always reach the
clients). Not sure if it worth to address this first or not, perhaps
the requirement of pinging the broadcast is not too bad (even if
certainly it doesn't look nice). Another way is to have a background
ping in the isofs itself. It's a tradeoff between being clean and
requiring changes to a package that will have to be installed in all
clients for this to work.

The nicest thing of this is that vde allows then the buyer to handle
the incoming cryptcab connection as he wants. he can have his master
switch attached to a tap interface, and attach a real dhcp server in
the host, and have his MPI server listening on the tap interface. Or
he can use slirpvde to route the whole cluster over the internet with
his IP address (not the safest thing to do but it would work).

So we all know this will be less secure, but the malicious people will
be identified easily if they ever pretend to withdraw any cash to
paypal. So if CPUShare grows, it won't be in the interest of the
sellers to be malicious. This is not like seti_X_at_X_home or similar, where
the seller can't be identified (IP address would be available but
that's about it). Infact I may raise the requirement to the seller to
authenticate itself with paypal getexpresscheckout before he can run a
client at all (even with CPUCoins) if there are many malicious clients
around.

My priority right now is to make life as easy as possible to the
buyer, all other priorities gone down now, and we'll address the rest
later once there are already real buyers into the system. VDE and KVM
by design shouldn't be exploitable even when used for CPUShare (if
they are it's most likely because of a bug that would be quickly
fixed) and that should be enough to start with.

The nice thing is that with this design, even if I change the CPUShare
protocol in a total different way, this time it will be guaranteed
that the isofs livecd and the real buyer application will require zero
changes, and no matter which OS the buyer decides to use (bootable
windows isofs, openbsd, freebsd, linux). What could change is that he
wouldn't run vde_cryptcab anymore to handle the incoming VPN
connections from the remote KVM, but that's certainly not a big
deal. The real application won't be able to notice the difference. I
think it's better to keep the vde_cryptcab and vde_switch invocation
external to the CPUShare buy client (only the sell client has to know
about them and it has to run it internally). The CPUShare buy client
will only keep a pool of KVM booting the isofs uploaded by the buyer,
coming into the vde_cryptcab server.

In some way this simplify the CPUShare protocol, and with this model
even the current server (the moment I switch to epoll and I'm really
close) will be able to handle zillon of nodes connected with extremely
low network traffic. So this really will scale wonderfully.

If anybody has comments let me know, I just wanted to let me know my
current development ideas after having looked into this more deeply.

Your help and feedback is greatly helpful and appreciated.

Thanks!
Andrea
-- 
cpushare-discuss_X_at_X_cpushare.com mailing list - http://www.cpushare.com/
To unsubscribe, send mail to cpushare-discuss-unsubscribe_X_at_X_cpushare.com