Re: [lwip-devel] httpserver_raw with custom files

[Gawie de Vos]

Thanks for your feedback Kieran. See my comments inline.

Regards,
Gawie
 
On 2010/12/13 11:39 AM, "Kieran Mansley" <address@hidden> wrote:

>On Mon, 2010-12-13 at 10:36 +0200, Gawie de Vos wrote:
>> 
>> 1. There wasn't a call to fs_read_custom() from the fs_read() function
>> (fs.c). I added it.
>> 
>> 2. Change the http_init_file() (httpd.c) function to initialize
>> hs->left
>> to 0 when a custom file is read. I had to do this in order to read a
>> chunk
>> of data from the SD Card when http_send_data() is called the first
>> time.
>> 
>> 3. Extend HTTP_IS_DATA_VOLATILE(hs) macro to return
>> TCP_WRITE_FLAG_COPY
>> when dealing with a custom file. I used the
>> (hs)->handle->is_custom_file
>> flag. I experienced some data corruption when http_write() was called
>> without TCP_WRITE_FLAG_COPY.
>
>Those all sound like reasonable improvements.

Great! 

>
>> 4. Force a tcp send (tcp_output(pcb)) after each call to the
>> http_send_data() function. I used the return value of http_send_data()
>> whether or not to force it. I added this to ensure deterministic
>> sending
>> of tcp packets and therefore helped me when debugging with WireShark.
>> Not
>> sure if this is needed, but I kept it as it is working very nicely
>> now.
>
>I expect this isn't strictly necessary, but if it works for you it's OK
>to use it like that.

OK, I will keep on using it like that.

>
>> 5. The len variable within the http_send_data() function gets updated
>> with
>> each header string that gets added dynamically. Once all the header
>> strings has been added and there is file data to be send, the value of
>> len
>> is set to tcp_sndbuf(pcb). I found that tcp_sndbuf(pcb) sometimes
>> returns
>> 1024 (2*MSS - full buffer available) and in that instances I never saw
>> that header bytes was sent in WireShark. I don't understand why, and
>> this
>> may need some more investigation. I "fixed" this by always return
>> after
>> sending the dynamic headers.
>
>I don't understand this one.

Sorry for being a bit vague on this one. I am still a bit new to
httpserver_raw and lwIP and did not really understand the code. After
subsequent testing I can confirm that this was just a lack of
understanding on my part and the code works as it should. Thus, forget
this one.

>
>> For instance (see extract of log file
>> below), the httpserver sends 1020 bytes (> MSS and < 2*MSS) and the
>> first
>> 512 bytes get acked, the httpserver will now try to read more data
>> from
>> the file but EOF is reached and then the connection is closed. It is
>> not a
>> train smash, but we close the connection before the last packet has
>> been
>> confirmed delivered.
>
>Why is it a problem if the application closes the connection before all
>data are acked?  The TCP stack (i.e. lwIP) should continue to handle the
>retransmission and so on of the data until it is all acked, or we give
>up.  i.e. The application closing the connection shouldn't change
>whether the other end gets the data or not.  Did you see something going
>wrong here?

OK, I wasn't sure if the lwIP stack will continue to handle the
retransmission etc. after the connection is closed. You state that this is
the case, so I will remove this change and test it like that.