From: "Jim C. Brown" <jma5@umd.edu>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
Date: Sat, 11 Jun 2005 16:58:50 -0400 [thread overview]
Message-ID: <20050611205850.GA7047@jbrown.mylinuxbox.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0506091349130.18410@filer.marasystems.com>
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.
next prev parent reply other threads:[~2005-06-11 21:00 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-03 13:57 [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion) Jan Marten Simons
2005-06-05 19:17 ` Henrik Nordstrom
2005-06-06 14:28 ` Jim C. Brown
2005-06-07 21:45 ` Henrik Nordstrom
2005-06-08 18:24 ` Jim C. Brown
2005-06-09 11:56 ` Henrik Nordstrom
2005-06-11 20:58 ` Jim C. Brown [this message]
2005-06-11 21:29 ` Christian MICHON
2005-06-13 0:14 ` Henrik Nordstrom
2005-06-13 8:59 ` Christian MICHON
2005-06-13 11:55 ` Jernej Simonèiè
2005-06-13 12:52 ` Christian MICHON
2005-06-14 19:49 ` John R. Hogerhuis
2005-06-14 20:00 ` Christian MICHON
2005-06-15 13:40 ` Henrik Nordstrom
2005-06-14 20:33 ` Jim C. Brown
2005-06-15 13:43 ` Henrik Nordstrom
2005-06-13 0:02 ` Henrik Nordstrom
2005-06-13 0:22 ` Paul Brook
2005-06-06 18:11 ` marten
2005-06-06 19:55 ` Jim C. Brown
2005-06-06 23:38 ` Jan Marten Simons
2005-06-07 16:16 ` Johannes Schindelin
2005-06-07 21:52 ` Henrik Nordstrom
2005-06-08 18:27 ` Jim C. Brown
2005-06-07 21:50 ` Henrik Nordstrom
2005-06-06 23:54 ` John R. Hogerhuis
2005-06-07 8:40 ` Christian MICHON
2005-06-07 22:59 ` Henrik Nordstrom
2005-06-08 6:43 ` Christian MICHON
2005-06-08 7:55 ` Henrik Nordstrom
2005-06-08 11:22 ` Christian MICHON
2005-06-08 12:25 ` Henrik Nordstrom
2005-06-08 22:31 ` Jan Marten Simons
2005-06-08 23:50 ` Jim C. Brown
2005-06-21 14:17 ` Jan Marten Simons
2005-06-21 20:02 ` Jim C. Brown
2005-06-21 21:39 ` Paul Brook
2005-06-21 21:47 ` Jim C. Brown
2005-06-09 16:33 ` Johannes Schindelin
2005-06-10 13:45 ` Jan Marten Simons
2005-06-07 22:15 ` Henrik Nordstrom
2005-06-08 6:12 ` John R. Hogerhuis
2005-06-08 7:52 ` Henrik Nordstrom
2005-06-08 11:22 ` Johannes Schindelin
2005-06-09 11:48 ` Henrik Nordstrom
2005-06-09 16:26 ` Johannes Schindelin
2005-06-08 18:33 ` Jim C. Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050611205850.GA7047@jbrown.mylinuxbox.org \
--to=jma5@umd.edu \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).