TFTP questions - TCP-IP

This is a discussion on TFTP questions - TCP-IP ; About to implement TFTP for transfers to/from embedded system and I have a couple of questions: 1) Why does the server switch to an ephemeral port after the initial connection? The reason I heard is that the pair of ephemeral ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: TFTP questions

  1. TFTP questions

    About to implement TFTP for transfers to/from embedded system and I have a
    couple of questions:

    1) Why does the server switch to an ephemeral port after the initial
    connection? The reason I heard is that the pair of ephemeral ports on client
    and server side act as a transaction ID. Wouldn't the ephemeral client port
    be enough? I don't see the advantage on the server side since the server
    already knows which client IP and port each packet belongs to. What am I
    missing?

    2) The built-in Windows TFTP client does not appear to support server
    sockets other than the default 69. Is this typical of most clients? Of
    course I could easily write my own client but I'm wondering if it would be
    possible to implement a TFTP server on my embedded device (which is limited
    to one single UDP port!) and assume that the client already has a TFTP
    client available that permits connecting to an arbitrary server socket.


    Thanks,
    Andrew



  2. Re: TFTP questions

    In article ,
    "andrew queisser" wrote:

    > About to implement TFTP for transfers to/from embedded system and I have a
    > couple of questions:
    >
    > 1) Why does the server switch to an ephemeral port after the initial
    > connection? The reason I heard is that the pair of ephemeral ports on client
    > and server side act as a transaction ID. Wouldn't the ephemeral client port
    > be enough? I don't see the advantage on the server side since the server
    > already knows which client IP and port each packet belongs to. What am I
    > missing?


    When the protocol was designed, many UDP API's didn't provide anything
    like the connect() operation for UDP sockets, so you couldn't specify
    that a socket should only receive packets from a particular remote
    address/port. UDP applications could only specify the local port to
    listen on. So there was no way to easily dispatch packets to the
    appropriate server process for each transfer. So they require the
    server to listen on a new, unused port for each connection, and the
    well-known port is just used for the initial setup.

    > 2) The built-in Windows TFTP client does not appear to support server
    > sockets other than the default 69. Is this typical of most clients? Of
    > course I could easily write my own client but I'm wondering if it would be
    > possible to implement a TFTP server on my embedded device (which is limited
    > to one single UDP port!) and assume that the client already has a TFTP
    > client available that permits connecting to an arbitrary server socket.


    The most common use of TFTP is for network booting, which typically
    doesn't provide a way to configure details like this -- the TFTP client
    is in the device's ROM, and there's no place for user-specified
    parameters.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: TFTP questions


    "Barry Margolin" wrote in message
    news:barmar-E685E7.20062707062006@comcast.dca.giganews.com...
    > In article ,
    > "andrew queisser" wrote:
    >
    >> About to implement TFTP for transfers to/from embedded system and I have
    >> a
    >> couple of questions:
    >>
    >> 1) Why does the server switch to an ephemeral port after the initial
    >> connection? The reason I heard is that the pair of ephemeral ports on
    >> client
    >> and server side act as a transaction ID. Wouldn't the ephemeral client
    >> port
    >> be enough? I don't see the advantage on the server side since the server
    >> already knows which client IP and port each packet belongs to. What am I
    >> missing?

    >
    > When the protocol was designed, many UDP API's didn't provide anything
    > like the connect() operation for UDP sockets, so you couldn't specify
    > that a socket should only receive packets from a particular remote
    > address/port. UDP applications could only specify the local port to
    > listen on. So there was no way to easily dispatch packets to the
    > appropriate server process for each transfer. So they require the
    > server to listen on a new, unused port for each connection, and the
    > well-known port is just used for the initial setup.
    >

    Thanks for the background but I think must still be missing something.
    Wouldn't the server simply dispatch packets based on the source (client)
    IPAddrort value? Anything coming in on 69 would be assumed to be TFTP and
    for each new source IPort value a new server process would handle all
    subsequent packets from that address?

    Andrew



  4. Re: TFTP questions

    In article <2MXhg.1663$X33.433@news.cpqcorp.net>,
    "andrew queisser" wrote:

    > "Barry Margolin" wrote in message
    > news:barmar-E685E7.20062707062006@comcast.dca.giganews.com...
    > > In article ,
    > > "andrew queisser" wrote:
    > >
    > >> About to implement TFTP for transfers to/from embedded system and I have
    > >> a
    > >> couple of questions:
    > >>
    > >> 1) Why does the server switch to an ephemeral port after the initial
    > >> connection? The reason I heard is that the pair of ephemeral ports on
    > >> client
    > >> and server side act as a transaction ID. Wouldn't the ephemeral client
    > >> port
    > >> be enough? I don't see the advantage on the server side since the server
    > >> already knows which client IP and port each packet belongs to. What am I
    > >> missing?

    > >
    > > When the protocol was designed, many UDP API's didn't provide anything
    > > like the connect() operation for UDP sockets, so you couldn't specify
    > > that a socket should only receive packets from a particular remote
    > > address/port. UDP applications could only specify the local port to
    > > listen on. So there was no way to easily dispatch packets to the
    > > appropriate server process for each transfer. So they require the
    > > server to listen on a new, unused port for each connection, and the
    > > well-known port is just used for the initial setup.
    > >

    > Thanks for the background but I think must still be missing something.
    > Wouldn't the server simply dispatch packets based on the source (client)
    > IPAddrort value? Anything coming in on 69 would be assumed to be TFTP and
    > for each new source IPort value a new server process would handle all
    > subsequent packets from that address?


    You don't want everything funneled through a single dispatcher process.
    It's preferable to have each server process listening on its own socket,
    and for that it needs a unique local port.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

+ Reply to Thread