Hi Sergio, Thank you for your email.
As I mentioned in my original post, I am using the raw API and the image data is around 7 kB in size. As you mentioned in your message, I copy the data in the pbuf into a larger buffer every time the callback is called. This continues until the connection is closed by the HTTP server (when the image transfer has completed and has been acknowledged), when my application processes the entire HTTP data. The purpose of my question was to try to find an alternative solution, but I now think my application is complete. Best regards, David -----Original Message----- From: lwip-users [mailto:[email protected]] On Behalf Of Sergio R. Caprile Sent: Monday, 10 April 2017 11:47 PM To: [email protected] Subject: Re: [lwip-users] Issue with TCP raw API and messages larger than TCP_MSS Imagine your image data is 3MB. Would you expect lwIP to buffer that on a 32KB microcontroller ? No, would you ? Right, that is, light-weight IP. The server will send bytes as it wants. TCP will send bytes as it wants. They will be put in IP and sent via Ethernet Each frame gets IP extracted, gets TCP extracted, gets your callback called. You get a pbuf. You will get bytes as the combination of the server, TCP and the net wills, plus, those bytes will be in a pbuf that can itself be a chain of smaller pbufs, depending on the fragmentation of your memory. You detect the connection has been closed. You detect content-length has been transferred. You are the client. You extract data from your pbuf with pbuf_copy_partial() and copy it to wherever you want. Do you want all the data in a single pbuf ? Chain them ! The httpd server is a nice example of how to do it. Basically: pbuf_cat(bigpbuf, newpbuf); However, since pbufs can be themselves chain of pbufs, I wouldn't do that... If you need the whole image in one piece for processing or whatever, you should copy each pbuf to your buffer with pbuf_copy_partial(). Even though you can chain all pbufs and access them later with pbuf_copy_partial(), I wouldn't dare to write an image processing algorithm doing its job this way. _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
