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: Jacob Gorm Hansen <jacobg@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Tue, 25 Jan 2005 23:43:05 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Jan 2005 05:44:08 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <41F700EA.8010709@xxxxxxx>
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> <41F700EA.8010709@xxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Jacob Gorm Hansen wrote:

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.

That's certainly interesting. Are you using ICMP simply for high-level management or are you passing event channel messages via ICMP? Are you just punting issues of reliability?

I agree with you, TCP is not the only network solution. However, it seems logically that a large number of people will want a TCP solution :-)

Regards,

--

Anthony Liguori
anthony@xxxxxxxxxxxxx



-------------------------------------------------------
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>