Hi all, just a dumb question: is the port for ftp-data always ftp-1 ? I mean: usually ftp == 21 and ftp-data == 20, so if I start a FTP server on, say, 50021, would ftp-data be 50020 by default? if not, where do I configure that ftpd's behaviour? TIA and regards, Martin
Martin wrote regarding '[SLE] ftp and ftp-data' on Fri, Nov 12 at 03:18:
Hi all,
just a dumb question: is the port for ftp-data always ftp-1 ? I mean: usually ftp == 21 and ftp-data == 20, so if I start a FTP server on, say, 50021, would ftp-data be 50020 by default? if not, where do I configure that ftpd's behaviour?
My interpretation of RFC959, section 3.2, is that ftp-data will automagically be assigned to controlport-1, so if you specify the control port as 50021, then the data port will be determined to be 50020 by a properly written server program. A stupid program may choose 20 regardless. Then again, I think that active FTP is a stupid protocol in general (passive's almost as stupid), and that FTP is in general not a terribly good protocol, esp. in the presence of lots of other good protocols (notably http 1.1 and rsync). :) --Danny, pointing you to faqs.org for more details
On Wednesday 17 Nov 2004 22:14, Danny Sauer wrote:
Martin wrote regarding '[SLE] ftp and ftp-data' on Fri, Nov 12 at 03:18:
Hi all,
just a dumb question: is the port for ftp-data always ftp-1 ? I mean: usually ftp == 21 and ftp-data == 20, so if I start a FTP server on, say, 50021, would ftp-data be 50020 by default? if not, where do I configure that ftpd's behaviour?
My interpretation of RFC959, section 3.2, is that ftp-data will automagically be assigned to controlport-1, so if you specify the control port as 50021, then the data port will be determined to be 50020 by a properly written server program. A stupid program may choose 20 regardless.
Then again, I think that active FTP is a stupid protocol in general (passive's almost as stupid), and that FTP is in general not a terribly good protocol, esp. in the presence of lots of other good protocols (notably 1.1 and rsync). :)
--Danny, pointing you to faqs.org for more details
http errr Hyper text transfere protocol is thet not TEXT are we talking web pages or binary files here ..?.. -- Linux user No: 256242 Machine No: 139931 G6NJR Pete also MSA registered "Quinton 11" A Linux Only area Happy bug hunting M$ clan, The time is here to FORGET that M$ Corp ever existed the world does not NEED M$ Corp the world has NO USE for M$ Corp it is time to END M$ Corp , Play time is over folks time for action approaches at an alarming pace the death knell for M$ Copr has been sounded . Termination time is around the corner ..
peter wrote regarding 'Re: [SLE] ftp and ftp-data' on Thu, Nov 18 at 04:46:
On Wednesday 17 Nov 2004 22:14, Danny Sauer wrote: [...]
Then again, I think that active FTP is a stupid protocol in general (passive's almost as stupid), and that FTP is in general not a terribly good protocol, esp. in the presence of lots of other good protocols (notably http 1.1 and rsync). :)
http errr Hyper text transfere protocol is thet not TEXT are we talking web pages or binary files here ..?..
How do you think all of the images on web pages are downloaded, let alone the other media files (pdf, flash, etc)? http is a nice, simple protocol that also supports handy stuff like partial transfers and compression, among others (in 1.1 - 1.0 didn't have that stuff). FTP, while somewhat convenient in the use of a separate data and control channel (telnet's used on the control channel), is not at all simple from a network point of view. There's no good way to secure ftp, aside from using a tunnel created using some other protocol (which most clients/servers don't support anyway), and it has the handy side effect of doing dumb things like changing the file in transmission. Have you ever downloaded a binary in ascii mode? Why would I want my file transfer protocol screwing with line endings when I can just use a good editor instead? Why would I want the server opening up new connections when I've already got a bidirectional link established with the server that could be used? Etc. --Danny, who hates ftp
On Thu, 18 Nov, 2004 at 10:33:38 -0600, Danny Sauer wrote: <snip>
How do you think all of the images on web pages are downloaded, let alone the other media files (pdf, flash, etc)?
http is a nice, simple protocol that also supports handy stuff like partial transfers and compression, among others (in 1.1 - 1.0 didn't have that stuff). FTP, while somewhat convenient in the use of a separate data and control channel (telnet's used on the control channel), is not at all simple from a network point of view.
Speaking of network POVs: Suppose I have a router doing priority queueing based on ToS flags (wondershaper). Am I understanding this correct, in that file transfers by way of http are going to end up in the same queue as the 'ordinary' webtraffic? And if so, then what might one do about it? Because it seems to me that clients using http for tranfers would then be 'jumping' the queue, so to speak, unless there is some pratical way to differentiate... TIA, Jon -- Just say "know!"
Jon wrote regarding 'Re: [SLE] ftp and ftp-data, drifting slightly OT' on Fri, Nov 19 at 00:30:
On Thu, 18 Nov, 2004 at 10:33:38 -0600, Danny Sauer wrote: <snip>
How do you think all of the images on web pages are downloaded, let alone the other media files (pdf, flash, etc)?
http is a nice, simple protocol that also supports handy stuff like [...] Speaking of network POVs:
Suppose I have a router doing priority queueing based on ToS flags (wondershaper). Am I understanding this correct, in that file transfers by way of http are going to end up in the same queue as the 'ordinary' webtraffic?
And if so, then what might one do about it?
Because it seems to me that clients using http for tranfers would then be 'jumping' the queue, so to speak, unless there is some pratical way to differentiate...
Yes, wondershaper works at the transport level - it only knows that the traffic is TCP/UDP/etc, and what port the TCP traffic's destined for, etc. It doesn't know or care what's going on at the protocol level, where things like the mime type, etc are available. If you want to choke down certain types of downloads, you need to use a proxy (probably squid). You can throttle bandwidth from there, using things like the content type and content length to determine how much of the http bandwidth a particular request will be allowed to use. With just wondershaper, people using http are technicaly bypassing the "download" queue. --Danny
On Fri, 19 Nov, 2004 at 12:25:31 -0600, Danny Sauer wrote:
Jon wrote regarding 'Re: [SLE] ftp and ftp-data, drifting slightly OT' on Fri, Nov 19 at 00:30:
Because it seems to me that clients using http for tranfers would then be 'jumping' the queue, so to speak, unless there is some pratical way to differentiate...
Yes, wondershaper works at the transport level - it only knows that the traffic is TCP/UDP/etc, and what port the TCP traffic's destined for, etc. It doesn't know or care what's going on at the protocol level, where things like the mime type, etc are available. If you want to choke down certain types of downloads, you need to use a proxy (probably squid). You can throttle bandwidth from there, using things like the content type and content length to determine how much of the http bandwidth a particular request will be allowed to use. With just wondershaper, people using http are technicaly bypassing the "download" queue.
drat... Proxies aren't really an option given my circumstances. Thanks for clarifying though. /Jon -- Just say "know!"
participants (4)
-
Danny Sauer -
Jon Clausen -
Martin Mielke -
peter Nikolic