FTP and TFTP

Hi,

TFTP is just a connectionless version of FTP that uses UDP for
reducing the overhead and increasing the reliability. Why does TFTP
does not require 2 ports ?
How does TFTP manage to do the activities done by FTP with only
1 port ?

That is,
FTP (TCP based) use two ports (Port 20 and Port 21).
Port 20 - For Data Stream . (data)
Port 21 - For Control Stream (commands between FTP server and client)
TFTP (UDP based) use only one port(Port 69) . Why ?

Thx in advans,
Karthik Balaguru

On Nov 7, 11:57 am, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> Hi,
>
> TFTP is just a connectionless version of FTP that uses UDP for
> reducing the overhead and increasing the reliability. Why does TFTP
> does not require 2 ports ?
> How does TFTP manage to do the activities done by FTP with only
> 1 port ?
>
> That is,
> FTP (TCP based) use two ports (Port 20 and Port 21).
> Port 20 - For Data Stream . (data)
> Port 21 - For Control Stream (commands between FTP server and client)
> TFTP (UDP based) use only one port(Port 69) . Why ?

I wonder why the post does not appear immediately .
It has taken many hours to appear ? Strange !!
Strange.

I posted this message with subject 'FTP and TFTP' before posting a
query with
subject 'TFTP and FTP', It ('FTP and TFTP' msg) did not appear
after waiting for nearly an hour.
So, i reposted it with subject 'TFTP and FTP' assuming some problem in
the
post of 'TFTP and FTP'.

I think, i should wait for few hours after posting a message.
Appologies.

Karthik Balaguru

"karthikbalaguru" ...
> I wonder why the post does not appear immediately .
> It has taken many hours to appear ? Strange !!
> Strange.
>
> I posted this message with subject 'FTP and TFTP' before posting a
> query with
> subject 'TFTP and FTP', It ('FTP and TFTP' msg) did not appear
> after waiting for nearly an hour.
> So, i reposted it with subject 'TFTP and FTP' assuming some problem in
> the
> post of 'TFTP and FTP'.
>
> I think, i should wait for few hours after posting a message.
> Appologies.
>
> Karthik Balaguru
>

We did see it. It looked too much like your homework, and you should do that
yourself to benefit from it.

Did you look it up in Wikipedia?
Did you already completely study and understand the RFC's for FTP and TFTP?

Arie.

karthikbalaguru wrote:
>
.... snip ...
>
> I wonder why the post does not appear immediately . It has taken
> many hours to appear ? Strange !! Strange.

At time it may take Teranews several days to transfer my output
messages. Admittedly this is abnormal. But remember, there are no
transmission guarantees with Usenet.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

Karthik Balaguru asked
> TFTP is just a connectionless version of FTP that uses UDP for
> reducing the overhead and increasing the reliability. Why does TFTP
> does not require 2 ports ?
> How does TFTP manage to do the activities done by FTP with only
> 1 port ?

Arie commented
> It looked too much like your homework, and you should do that
> yourself to benefit from it.

Well, I have seen his posts here, so he's not just a carpetbagger on
an urgent homework mission.
FTP is a fairly complex protocol, which hands off the data transfer to
separate port pair so that the
control connection is available for further control traffic. TFTP is a
very simplified functional analog, which
just accepts a single command packet and sends multiple data packets
in return. There is no
connection, no error checking, no acknowledgements---so it doesn't
need more ports.

<(E-Mail Removed)> ...
> FTP is a fairly complex protocol, which hands off the data transfer to
> separate port pair so that the
> control connection is available for further control traffic. TFTP is a
> very simplified functional analog, which
> just accepts a single command packet and sends multiple data packets
> in return. There is no
> connection, no error checking, no acknowledgements---so it doesn't
> need more ports.


You don't do his homework very good... (if it is homework).

- There is state, with timeouts - I see that as a connection.

- The error checking is in the checksums on the UDP and ETH layers. No need
to add more. If the UDP were disabled (checksum zero) and another type of
transport were used without a good CRC, I could agree. But that is unusual.

- No acknowledgements? Each packet has a block number and gets acknowledged
with the block number. The TFTP protocol is "so slow" because the next
packet will not be send before the previous packet's ACK is received. No
windowing here.

Arie

On Nov 7, 5:54 pm, "Arie de Muynck" <no.s...@nospam.com> wrote:
>
> > FTP is a fairly complex protocol, which hands off the data transfer to
> > separate port pair so that the
> > control connection is available for further control traffic. TFTP is a
> > very simplified functional analog, which
> > just accepts a single command packet and sends multiple data packets
> > in return. There is no
> > connection, no error checking, no acknowledgements---so it doesn't
> > need more ports.
>
> You don't do his homework very good... (if it is homework).

I was sloppy, sorry, thanks for making me look it up again. I do
believe
I have a couple of points, though. Let's review:

> - There is state, with timeouts - I see that as a connection.

Cmon, if you say it this way, everything would be a connection. What
would
qualify as a no-connection by your criteria? a single packet exchange?

> - The error checking is in the checksums on the UDP and ETH layers. No need
> to add more. If the UDP were disabled (checksum zero) and another type of
> transport were used without a good CRC, I could agree. But that is unusual.

While it's true that UDP nowadays tends to have checksum turned on, it
really
is no substitute for higher-level error detection and correction.
Consider this:
I just collected a sample of 100 UDP packets from my network, and four
had invalid
checksum. It could have been a crappy implementation of DNS in some
embedded
device, or a software flaw in a router; I don't care. Stevens
discusses it here

http://uic.rsu.ru/doc/inet/tcp_steve..._user.htm#11_3

Without the protocol-level checks, ya just can't trust the data, so
you better do app-level checks.
I'm happy that e.g. Linux kernel will do a boot-time sanity check
while uncompressing
because I wouldn't absolutely trust the boot image received over
TFTP.

> - No acknowledgements? Each packet has a block number and gets acknowledged
> with the block number. The TFTP protocol is "so slow" because the next
> packet will not be send before the previous packet's ACK is received. No
> windowing here.

Yes, you're right, there are simple acks but the algorithm is the
simplest possible and,
ironically, vulnerable to both lockups and sorcerer's apprentice
blowup in packet loss situations.

<(E-Mail Removed)> ...
> I have a couple of points, though. Let's review:
>
>> - There is state, with timeouts - I see that as a connection.
>
> Cmon, if you say it this way, everything would be a connection. What
> would
> qualify as a no-connection by your criteria? a single packet exchange?

If at least one side remembers it's communication to someone else, e.g.
remembers the remote side's IP and/or port number, and puts a timout on
packet echange, and discards that information (a.k.a. disconnects) if a
timeout occurs: I see that as a connection. TCP is called a connection -
even when many minutes may go by without a single packet exchanged.

>> - The error checking is in the checksums on the UDP and ETH layers. No
>> need
>> to add more. If the UDP were disabled (checksum zero) and another type of
>> transport were used without a good CRC, I could agree. But that is
>> unusual.
>
> While it's true that UDP nowadays tends to have checksum turned on, it
> really
> is no substitute for higher-level error detection and correction.
> Consider this:
> I just collected a sample of 100 UDP packets from my network, and four
> had invalid
> checksum. It could have been a crappy implementation of DNS in some
> embedded
> device, or a software flaw in a router; I don't care. Stevens
> discusses it here
>
> http://uic.rsu.ru/doc/inet/tcp_steve..._user.htm#11_3
>
> Without the protocol-level checks, ya just can't trust the data, so
> you better do app-level checks.
> I'm happy that e.g. Linux kernel will do a boot-time sanity check
> while uncompressing
> because I wouldn't absolutely trust the boot image received over
> TFTP.

Agreed, the UDP checksum is not very good, although I have never seen a
packet fail the UDP checksum (and we're streaming up to 500 channels of
video using UDP/RTP). But then, it's over closed networks with switches and
routers but not over the over the internet or leased lines. Routers that
would modify packets are quickly discarded and never bought again.

Trust a kernel image? Hi, we do use TFTP for production programming of Linux
kernel and initrd images - but we do use a CRC32 embedded in all images :-)

>> - No acknowledgements? Each packet has a block number and gets
>> acknowledged
>> with the block number. The TFTP protocol is "so slow" because the next
>> packet will not be send before the previous packet's ACK is received. No
>> windowing here.
>
> Yes, you're right, there are simple acks but the algorithm is the
> simplest possible and,
> ironically, vulnerable to both lockups and sorcerer's apprentice
> blowup in packet loss situations.

Agreed. I've also seen some bad implementations that hang after a single
packet got lost (e.g. the original BSD tftp server).

Arie.

> <(E-Mail Removed)> ...
>> What would qualify as a no-connection by your criteria?
>> A single packet exchange?

Or broadcast, or multicast without RTCP. A.k.a. "the shoot and forget" way
of communication.

Arie