Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

[Jim C. Brown]

On Thu, Jun 09, 2005 at 01:56:09PM +0200, Henrik Nordstrom wrote:
> On Wed, 8 Jun 2005, Jim C. Brown wrote:
> 
> >Next to impossible to do portably. I am not sure how user-net port 
> >redirection
> >even enters the picture - once the FTP daemon is set up, the guest sees
> >the FTP server on the host (admittedly on a nonstandard port, but is that
> >such a big deal?).
> 
> With the user-net port redirection the wrapper can automate the task, 
> dynamically assigning a port to the FTP server and map this on port 21 of 
> the router.
> 

Ok this might be slightly useful. Still, any sane client should support using
a non-standard port, so this isn't a major issue.

> >>FTP unfortunately doesn't fit in the user-net pipe framework due to it's
> >>(ftp) broken design (data channel mess).
> >
> >Can you explain what you mean here?
> 
> The user-net pipe support when seeing a new TCP connection to the piped 
> port (as used for the SMB server) forks a child process and connects the 
> TCP connection via a pipe to this child process sort of as if it was 
> started by inetd.
> 
> Problem is that FTP uses more than one TCP connection (the main control 
> channel, plus one data channel per transfer) and this isn't supported by 
> the slirp pipe support. For this kind of protocols you have to use port 
> mapping or forwarding.
> 
> The real FTP server only works because it is running on a real TCP/IP, 
> allowing it to open additional ports which is bidirectionally reachable 
> for the client (direction depending on which PORT/PASV mode is used)
> 
> Regards
> Henrik
> 

I agree. While I believe this can be worked around (given a cooperative ftpd),
having a child process for every data connection is really not worth the
trouble. It's just too ugly. Besides, not every system will have an ftpd
installed.

I don't see this as a difficult problem for a builtin FTP server though,
provided that passive mode is used. 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. Active mode
is a little harder to do right, but thats hard to get right through a NAT
connection anyways.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.