Dear Marcel Moolenaar, In message <cac78579-738b-4d03-8ef0-14fa1141f...@mac.com> you wrote: > > This is also the crux of the problem. The application > waits for a specific response, but there's no guarantee > (due to broadcast or multicast packets on the LAN) that > the next packet to arrive on the interface is the one > that we're waiting for.
Right. > Now, one approach would be to ignore packets that don't > fit the buffer. This seems unflexible, because it makes > it impossible to employ flexible buffer allocation in > the application. What's left? The only thing left is that "flexible buffer allocation"? May I ask what sort of applications you have in mind? We're talking about applications running in the context of a boot loader, right? For anything fancy you should probably rather use an operating system. > you return whatever arrived on the interface truncated > to the buffer size. That way the application can discard > and call read again if headers don't match, or it can > allocate a bigger buffer and retry. Allocate a bigger buffer? What for? The packet has been dropped already and is not recoverable. > The problem with this approach is that theoretically > an application needs to use a buffer that is as large > as the maximum size of a packet that can appear on the > interface. For example, with jumbo frames this means > that any application, module or function that wants to > receive even the smallest amount of data (say an ARP > response) needs to allocate a 9K buffer. Right. > The question is not of effort -- there's virtually none. > The question is whether this is good engineering. Worst > case buffer allocation doesn't strike me as portable nor > reasonable. Not portable? In which way do you see any porting issues here? Not reasonable? How many such buffers do you need, then? All it takes is a different size in simple call to malloc(), or am I missing something? Please let's keep in mind: this is a boot loader, and a very minimal network stack. It is not an OS, and we don't claim to implement a TCP/IP stack. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "We shall reach greater and greater platitudes of achievement." - Richard J. Daley _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
