This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3120MOD: Large HTTP transfers

Part Number: CC3120MOD
Other Parts Discussed in Thread: CC3120

Hi, I'm setting up a SimpleLink application that includes downloading files over HTTP that may be multiple GB (from an SD card).

I have code that's working okay, but a couple of issues with the details.

1. If the user aborts the download (which closes the connection), is there some way the firmware can detect that? I don't get a non-zero result from the sl_NetAppSend() calls, and sl_DeviceGet(SL_DEVICE_STATUS) (not very well documented) returns zero status and zero device_status whether the data is going out or getting discarded. None of the event callbacks seem to be invoked when the connection is dropped.

2. Setting CONTENT_LENGTH in the metadata to a 64-bit value doesn't seem to work, even though I specify a size of 8 bytes. For files over 2GB, it looks like I have just leave off CONTENT_LENGTH and the user can't monitor progress very well.

Any suggestions would be much appreciated.

  • Hi Jack,

    Is our device operating as an HTTP server and users are downloading files from? From your description I cannot tell. Please confirm. Also describe what mode our device is operating in (AP/STA).

    1. Waiting for your response above.

    2. Where exactly are you setting the CONTENT_LENGTH?

    Jesu

  • The device is currently in STA mode, although I want the code to also work in AP mode. It's operating as an HTTP server but the host code NetAppRequestHdlr is handling the request, following the "GET with Fragmentation" model in manual section 9.7.2.1. The data is coming from separate storage, not the CC3120 file system.

    CONTENT_LENGTH is set in the metadata in the first sl_NetAppSend call.

    Other notes:

    - I'm using simplelink_sdk_wifi_plugin_2_40_00_22

    - The host driver interface includes a slcb_NetAppHttpServerHdlr event handler, but it seems that's never called, rather NetAppRequestHdlr is called for HTTP events.

    Thanks.

  • Hey Jack,

    Since you are using the internal HTTP server I don't think this is possible. Because HTTP itself is stateless there is no way to detect disconnect and you will have to rely on timeouts. This might be possible if you use the HTTP server library in our network services layer to try to detect if the TCP connection was closed earlier but I do not know if anyone has done this before. This is because the HTTP server will run on the host code so the TCP socket is created from the host side even though the NWP still maintains it. Ultimately there's nothing built in on the HTTP side of things that will tell you this but there might be a way by the TCP layer but you need access to the underlying TCP socket in the HTTP server. Please keep in mind we generally don't recommend changing our source code because we can only guarantee the performance of the code how it's released but if this is a critical requirement for you, you can try investigating this route yourself.

    Jesu

  • I appreciate the suggestions. There is no timeout - it looks like the NWP just immediately discards sl_NetAppSend() requests, with nominal status, if the connection was closed. I could look for this condition - all the requests returning within 2 msec. If the download is still active, at least occasionally (1 out of 50 1364-byte fragments?) the call takes significantly longer. That seems fragile though.

    I was hoping there was a way to query status on the "request handle" passed into my NetAppRequestHdlr (and passed back into sl_NetAppSend requests), but I guess that's internal to the NWP and no such query is provided.

    > there might be a way by the TCP layer but you need access to the underlying TCP socket in the HTTP server

    I'm not sure if you're suggesting modifying the NWP firmware - I'd prefer to avoid that. However, this does give me an idea: I could do my own HTTP server on the host side, using TCP socket services on a different port number, specifically for this file download function.The built-in HTTP server could still be used for everything else, including serving pages from the NWP flash file system.

  • Hi Jack,

    I'm not sure if you're suggesting modifying the NWP firmware - I'd prefer to avoid that. However, this does give me an idea: I could do my own HTTP server on the host side, using TCP socket services on a different port number, specifically for this file download function.The built-in HTTP server could still be used for everything else, including serving pages from the NWP flash file system.

    You cannot modify the NWP FW. Correct, I was suggesting to use the HTTP server on the host side so you have more access to the underlying functionalities. 

    Glad I could help.

    Jesu

  • OK, that's probably not too hard. And I can deal with the content-length over 32 bits while I'm at it.

    Thanks for the help.