From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dhcsh-00038h-RC for qemu-devel@nongnu.org; Sun, 12 Jun 2005 20:32:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dhcsc-00035z-3p for qemu-devel@nongnu.org; Sun, 12 Jun 2005 20:32:42 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dhcsb-000331-Uf for qemu-devel@nongnu.org; Sun, 12 Jun 2005 20:32:41 -0400 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Dhck8-0007Hr-4R for qemu-devel@nongnu.org; Sun, 12 Jun 2005 20:23:56 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion) Date: Mon, 13 Jun 2005 01:22:50 +0100 References: <42A061E3.8010804@xtal.rwth-aachen.de> <20050611205850.GA7047@jbrown.mylinuxbox.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506130122.53129.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Monday 13 June 2005 01:02, Henrik Nordstrom wrote: > > If the ftp server ran on its own ip > > address, then qemu could simply set up new servers on new ports for the > > new data connections and have the client connect to them. > > You already have the router virtual IP address under your (or SLIRP) full > control. No need to invent additional addresses imho. I don't think this is a good idea. The current behaviour is to automatically forward connections to the router on to the host. INMO this is very useful and desirable behaviour, so any new services should be added on a different virtual IP. We already use additional addresses for dns, tftp and SMB. > I don't see why active should be much harder than passive. SLIRP already > have support for both accepting and making connections both ways. Just > use what there is. There will be a somewhat hefty state machinery involved > however.. writing an FTP daemon within SLIRP is considerably more complex > than the same thing as a stand-alone daemon. It doesn't have to be. You can use the same trick as the fork_exec code does. ie. the ftp code listens on a localhost socket, and use the normal slirp connection forwarding. Paul