On Wed, 16 Jul 2014 08:48:18 +0200 Daniele Lacamera <daniele.lacam...@tass.be> wrote:
> On Wed, Jul 16, 2014 at 8:30 AM, Sascha Hauer <s.ha...@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 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
