WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
From: Jacob Gorm Hansen <jacobg@xxxxxxx>
Date: Tue, 25 Jan 2005 18:31:06 -0800
Cc: Jared Rhine <jared@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Jan 2005 03:34:13 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <1106593648.18670.23.camel@localhost>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <1106322956.17263.26.camel@localhost> <eacc82a4050121083937725a83@xxxxxxxxxxxxxx> <Pine.LNX.4.58.0501211016500.4841@xxxxxxxxxx> <1106337581.18070.13.camel@localhost> <Pine.LNX.4.58.0501211343530.5215@xxxxxxxxxx> <1106342088.18665.1.camel@localhost> <Pine.LNX.4.58.0501211353100.5215@xxxxxxxxxx> <1106343476.7691.91.camel@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0501240829570.12186@xxxxxxxxxxxxxxxxxx> <1106584520.18665.10.camel@localhost> <1106585752.17408.16.camel@xxxxxxxxxxxxxxxx> <1106593648.18670.23.camel@localhost>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20050116)
Anthony Liguori wrote:
They do not take into account things like endianness into
consideration.  They certainly don't security into account at all.  To
export a proper TCP interface requires a higher level protocol.  The TCP
interface will have to do a certain amount of work to take these things
into account.

I think we all agree that we need a TCP interface.

No. In my implementation I think I have shown that you can run your cluster with a much more minimal network-interface.

My current implementation is less than 100 lines of network-facing code (using ICMP payloads, but the same could be achieved with UDP), though that increases to about 300 if you count in the SHA-1 implementation that I am using for verifying customer credentials. So 300 lines is for a complete solution including crypto and accounting/payment.

My nodes answer ARPs and pings, but that is all.

# nmap -sS blackbox07

Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2005-01-25 18:26 PST
All 1660 scanned ports on blackbox07 are: filtered

Nmap run completed -- 1 IP address (1 host up) scanned in 71.969 seconds

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>