Author Topic: Generate file problem  (Read 4226 times)

Offline Kuroro

  • Newbie
  • *
  • Posts: 38
    • View Profile
Generate file problem
« on: May 31, 2010, 08:59:08 AM »
Hi mark

I tried to use the generate file to download a file stored in SD card, to do that i use the same technique that you use in the original project.
So i split my file in chunk of 280 byte until i reach the EOF.

That work fine for small file < 10ko but when i tried to download bigger file the download process stop to a random size, like if it lost the communication with the utasker webserver.

In my project I used socket, so it's possible that these socket crash the generate file process ?

Thank's

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3191
    • View Profile
    • uTasker
Re: Generate file problem
« Reply #1 on: May 31, 2010, 10:25:13 AM »
Hi

From the description I don't see any basic difference to collecting the data to be sent from an internal file or a file in SPI FLASH (for example). There is no size limit that has been experienced in these cases.

I suggest recording the process with Wireshark and sending this because it will show any problems taking place at the TCP connection, which will probably help explain the root-cause.

Regards

Mark

Offline Kuroro

  • Newbie
  • *
  • Posts: 38
    • View Profile
Re: Generate file problem
« Reply #2 on: June 02, 2010, 10:40:07 AM »
Hi Mark

her's the wireshark log file : http://thekuroro.vacau.com/cap_file.zip

I keep looking in my code, but i don't see anything wrong for now

Thank's

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3191
    • View Profile
    • uTasker
Re: Generate file problem
« Reply #3 on: June 02, 2010, 01:44:33 PM »
Hi

The problem is starting when the Web Browser client is sending window update frames. Normally this happens when the web server has sent a lot of data too fast for the web browser to keep up with and its TCP windows closes - the update informs that the window can accept form data.

However in your case the web browser (PC) is sending window update messages very early (it takes about 10k or so of data to provoke it). The window is however not closed but the updates are still being sent to inform that there is now more space.

This unexpected situation (what type of PC is it?) looks to be causing the web server to make an error - it is interpreting the the window updates as meanin that it can send more data (like an ACK) which looks to be resulting in sequence counter errors which are not recovered from.

Could you please try the following - in http.c:

            case TCP_WINDOW_UPDATE:                                      // handle TCP windows update as ACK

Add a break; after this line so that the updates are ignored by HTTP. I think that it will solve your particular problem. However the reason for handling them as ACKs was to allow stalled transmissions to be able to re-start, which is a different case. This means that I will need to try to reproduce a similar situation and then identify a technique which will allow the stall to be re-started but the early window updates to be ignored. This is probably not that difficult but it is surprising that I haven't seen a PC (web browser side) doing this before...

Regards

Mark