Re: [lwip-devel] httpserver_raw with custom files

[Kieran Mansley]

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.  

> 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.

> 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.

> 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?

Kieran