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

"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

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