From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] xenctld - a control channel multiplexing daemon Date: Tue, 25 Jan 2005 23:43:05 -0600 Message-ID: <41F72DE9.7070505@codemonkey.ws> References: <1106322956.17263.26.camel@localhost> <1106337581.18070.13.camel@localhost> <1106342088.18665.1.camel@localhost> <1106343476.7691.91.camel@bear.wordzoo.com> <1106584520.18665.10.camel@localhost> <1106585752.17408.16.camel@bear.wordzoo.com> <1106593648.18670.23.camel@localhost> <41F700EA.8010709@diku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <41F700EA.8010709@diku.dk> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jacob Gorm Hansen Cc: xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org 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@codemonkey.ws ------------------------------------------------------- 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