I realise by last email may have been a bit rambling: The TFTP server listens continuously for requests on well-known UDP port number 69, which is reserved for TFTP. The client chooses for its initial communication an ephemeral port number, as is usually the case in TCP/IP. This port number actually identifies the data transfer, and is called a transfer identifier (TID).
What's different about TFTP, however, is that the server also selects a pseudo-random TID that it uses for sending responses back to the client; it doesn't send them from port number 69. The reason this is done is that by using unique client port number and source port number, multiple TFTP exchanges can be conducted simultaneously by a server. Each transfer is identified automatically by the source and destination port number, so there is no need to identify in data messages the transfer to which each block data belongs. This keeps the TFTP header size down, allowing more of each UDP message to contain actual data. For example, suppose the TFTP client selects a TID of 3,145 for its initial message. It would send a UDP transmission from its port 3,145 to the server's port 69. Say the server selects a TID of 1,114. It would send its reply from its port 1,114 to the client's port 3,145. From then on, the client would send messages back to server port 1,114 until the TFTP session was completed. So, what should I be doing, using MINA, to to start up a severside port and session - when a client has not actually communicated on that port to the server ! On Fri, Jul 3, 2009 at 2:58 PM, Linz RB <[email protected]> wrote: > Hi > > I am hoping that someone can share thoughts on this problem that I have. > > I am implementing a TFTP server on MINA 2. > I have ProtocolCode for encoding and decoding. > I have an ProtocolHandler that accepts TFTP message and produces repsonses. > All good to far. > > But I have struck a bit of a brick wall with with aspect of the TFTP > protocol - and am hoping that perhaps someone can share best practise (in a > MINA context). > Here it the sequence of TFTP messages I have to deal with: > > client (port A) ----- RRQ -----> server (port 69) // port 69 is the > default TFTP listening port > > client (port A) <----DATA----- server (port X) // server choose a > random port to continue talking to client on. > > client (port A) ----- ACK ------> server (port X) > client (port A) <----DATA------ server (port X) > .... > > I can see that NioDatagramAcceptor can accept binds to mutiple sockets so > binding to port x for the duration of transmission is find - and unbinding > is OK. > This means the same single instance ProtocolCodec and a single instance > ProtocolHandler can still be used for handling messages recieved on port 69 > and any other ports. Nice ! > > THE PROBLEM ! > > But - I cannot see how to get the first DATA message to be sent on a new > port, port X. Mina is going to try to send back via the port that the > request was recieved from - port 69. > (I can see that changing the client destination port is provided by > 'session.write(packet, > remoteAddress) in the IOSession object' - but nothing for the local > address). > > Am I attemting to handle this case wrong ? > Am I missng a feature of MINA that does handle this ? > > Many thanks in advance . > > > > > >
