picotcp tftp support [was Adding IPv4 multicast support]

[Antony Pavlov]

On Wed, 16 Jul 2014 08:48:18 +0200
Daniele Lacamera <daniele.lacamera at tass.be> wrote:

> On Wed, Jul 16, 2014 at 8:30 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> > Right now the network users register to a udp port and provide a handler
> > which is called whenever a packet to this port is received. The
> > prototype for this function is:
> >
> > struct net_connection *net_udp_new(IPaddr_t dest, uint16_t dport,
> >                 rx_handler_f *handler, void *ctx);
> >
> > Then network users can send packets on this connection:
> >
> > int net_udp_send(struct net_connection *con, int len);
> >
> > The function returns after the packet has been sent.
> >
> > The network user has to keep the ball rolling by calling
> >
> > void net_poll(void);
> >
> > in a loop. This function will call into the network drivers receive
> > function and dispatch the received packets. ARP packets are handled
> > internally, the UDP packets are passed to the registered handlers.
> >
> > The handlers usually will send answers to received packets (so a tftp
> > client will send an ack here or request the next packet).
> >
> > Usually the loop calling net_poll() also has some functionality to
> > detect progress and will send the last packet again if it was lost.
> >
> > Hope that explains the networking model in barebox.
> >
> 
> Hi Sascha,
> 
> Thanks a lot for this clarification. The mechanism you described is
> the same as the native execution model of PicoTCP, and looking around
> in the code it seems that looping around net_poll() was in fact the
> way to go.
> 
> to Antony: I will improve TFTP first, by allowing multiple sessions at
> the same time. I will keep you posted on the progress.

I see a barebox-related publication with nice pictures on the picotcp website  :)

  http://www.picotcp.com/barebox-on-top-of-picotcp

We are awaiting improved TFTP...

-- 
Best regards,
  Antony Pavlov