cancel
Showing results for 
Search instead for 
Did you mean: 

ip_sockd_timeout usage

Giulio Dalla Vecchia
Associate II
Posted on January 20, 2016 at 16:08

Hello all,

I'm using a SPWF01SA.11 as a web server. It is coupled with an host MCU that process the http protocol: the internal web server on the module is disabled (ip_use_httpd = 0), and I have opened the socket server on port 80 (AT+S.SOCKD = 80,t). In this way when the mcu receive an http request, it reply with the http header and the content of the html page. To load a page, the mcu sends over the uart a block of 800 bytes of data and waits for ip_sockd_timeout + 45ms before sending another block. This delay is intended to allow the sending of the data over the wireless and avoid the buffer overflow. Ip_sockd_timeout is set to 5ms. With this configuration sometimes I have some tcp packets corrupted (filled with zero) and the html page is not loaded. Unfortunatelly I can't use hardware flow control because I have some hardware constrains. Is there a solution to safely send some kB of data without having data loss?

Thanks in advance for the support.

Giulio

#spwf01sa #ip_sockd_timeout
1 REPLY 1
Posted on January 20, 2016 at 18:54

Ciao Giulio,

sorry for the stupid question, but... why are you using SOCKD on port 80, when module integrates its own webserver?

Moreover, since you are using .11 module, you have 1Mb external flash for filesystem. You can download inside it everything: files, images, binaries, etc.

Integrated webserver allows also usage of SSI and CGIs. There is an application note about it.

Let's move on your scenario. if you have no flow control, there is no way to avoid buffer overflow. If module needs some time to perform buffer send, and cannot stop external host, buffer overflow will happen for sure.

Please note that buffer send, and related needed time, depends on network load, RTT, and so on.

You can try to leave ip_sockd_timeout=5ms, but it's mandatory to increase external host ''wait time'' between 2 write on UART. It's mandatory, but (based also on network load) probably not sufficient...

Ciao

j