FTP and TFTP - Networking

This is a discussion on FTP and TFTP - Networking ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: FTP and TFTP

  1. 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


  2. Re: FTP and TFTP

    On Nov 7, 11:57 am, karthikbalaguru
    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


  3. Re: FTP and TFTP


    "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.






  4. Re: FTP and TFTP

    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)

    Try the download section.



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


  5. Re: FTP and TFTP

    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.


  6. Re: FTP and TFTP


    ...
    > 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



  7. Re: FTP and TFTP

    On Nov 7, 5:54 pm, "Arie de Muynck" 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.


  8. Re: FTP and TFTP


    ...
    > 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.






  9. Re: FTP and TFTP

    > ...
    >> 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




+ Reply to Thread