1

We have an apache server that hosts firmware files for some embedded devices. These files are not very large, only about 160kb. The embedded devices use an EDGE mobile connection to connect to this server and download an update when needed. The problem we are having is that there is a software bug in some of this devices that causes high packet loss. If the network connection is really good, the devices will manage to download the file and update. The problem is in most cases this doesn't happen.

I don't think the packet loss is caused by the network because the download always begins well. After about 4KB, when the device starts writing the data to flash and the connection slows to a crawl and never recovers. Normally this slowdown should be temporary, once the data is saved the download speed should improve.

Looking at the network traffic packets are still being sent by both sides but there are losses and the server just spends most of the time waiting for acknowledgment.

I was wondering if there is any way to force the server to resend the packets more often. I've tried changing the tcp congestion control to westwood but it doesn't help. Is there any setting in the web server (any web server) that could do this? Or maybe a way to write our own for this purpose? This is just a temporary solution until we update the buggy devices.

Improve this question
6
  • 1
    AFAIK retransmission of lost TCP packets isn't done at the application layer by your webserver, but at the OS level in your TCP stack and depending on your OS there are more settings than just the congestion control algorithm.
    – HBruijn
    Aug 24, 2017 at 9:28
  • @HBruijn could you point me to these settings? We're running Ubuntu 14.04 on the server, although, if needed, I could install a server just for this with any OS.
    – sorin.silaghi
    Aug 24, 2017 at 9:42
  • 1
    Yeah. If you have a broken network, fix it - standard technologies can not handle this. You decided to use a standard technology. In this csae you would best need your own download protocol which is UDP based and especially prepared to handle this type of broken environment.
    – TomTom
    Aug 24, 2017 at 10:13
  • tcp_retries1 & tcp_retries2 might be what you're after kernel.org/doc/Documentation/networking/ip-sysctl.txt
    – HBruijn
    Aug 24, 2017 at 10:18
  • @TomTom none of this was my decision and I can't change the protocol if I can't update the firmware. So far the only option for doing that is a recall and the customer is not exactly keen on it.
    – sorin.silaghi
    Aug 24, 2017 at 10:54

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .