• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 40 subscribers
  • Views 826 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3120: Keep-alive with POST request

Gary Klinefelter
Intellectual 780 points
Part Number: CC3120
Other Parts Discussed in Thread: CC3100

I am migrating a CC3100 design that uses user tokens for GET and POST to a CC3120 design using an MSP432.  The token GETs are working on the CC3120 through an HttpServer event like the CC3100. A keep-alive with a POST is creating a NetAppRequest event for the POST that I expected to come through as an HttpServer event.  Do I now have to have the MSP432 handle this HTTP request?

  • 0
    TI__Mastermind 38980 points

    Hi Gary,

    All tokens that were previously handled by the network processor without waking up the host (like device and network information) should still work on the CC3120. The CC3x20 NWP Programmer's Guide has the full list of supported tokens in the HTTP Server chapter, including details on the rest of my post below: http://www.ti.com/lit/swru455

    The HTTP server host requests (those that need to be handled by the application) changed from tokens to RESTful APIs between Gen 1 and Gen 2. You can see this new functionality in the Portable + Wi-Fi SimpleLink Academy that discusses a basic internal HTTP server: dev.ti.com/.../

    You can also use a legacy API left in the host driver for such porting purposes, SimpleLinkHttpServerEventHandler. If you move the contents of your Gen 1 HTTP server callback to SimpleLinkHttpServerEventHandler in your CC3120 application code, it should give you similar functionality.

    Best regards,
    Sarah

  • 0 in reply to Sarah P
    Intellectual 780 points
    Thank you Sarah,
    I had already read through the Portable + Wi-Fi example which helped me understand the capabilities of Gen 2. It also help me get token processing connected to the SimpleLinkHttpServerEventHandler. When I get a POST token preceded by a keep-alive from our phone app, the POST token does not trigger SimpleLinkHttpServerEventHandler. Instead the keep-alive triggers SimpleLinkNetAppRequestEventHandler and the POST token is part of the keep-alive. I have looked at adding the HttpServer.c from the Portable + Wi-Fi project, but then I add more overhead and another thread. In Gen 1 the keep-alive was handled by the Network Processor and the Post Token extracted and passed on to the HttpServerCallback. We will likely migrate to using SimpleLinkNetAppRequestEventHandler in the future when time allows. Ideally the keep-alive would be handled by the Network Processor as in the past, passing on the POST token to SimpleLinkHttpServerEventHandler.

    The SimpleLinkNetAppRequestEventHandler gives me this event package:

    AppId = 1
    Type = 2
    Handle = 258
    pMetaData = 98
    metadata = HTTP/1.1 //No_content! application/x-www-form-urlencoded keep-alive irrigreen.net - __SL_P_UDB=Server:0|Date:2/6/2019|Time:10:58|
    pPayload = 45
    payload = __SL_P_UDB=Server:0|Date:2/6/2019|Time:10:58|

    I could process the payload, but would have to provide the proper response for the keep-alive. Any advice on how to proceed would be appreciated.
    Gary
  • 0 in reply to Gary Klinefelter
    Intellectual 780 points
    Sarah,
    I figured it out. Thank you for pointing me in the right direction. I just needed a little more code to make the CC3120 work like the CC3100. Once I put the following code in SimpleLinkNetAppRequestEventHandler, the user post tokens and content were passed on to SimpleLinkHttpServerEventHandler.

    Gary

    void SimpleLinkNetAppRequestEventHandler(SlNetAppRequest_t *pNetAppRequest,
    SlNetAppResponse_t *pNetAppResponse)
    {
    UART_PRINT("NetAppRequest.Event\n\r");

    switch(pNetAppRequest->Type)
    {
    case SL_NETAPP_REQUEST_HTTP_POST:
    /* Prepare pending response */
    pNetAppResponse->Status = SL_NETAPP_HTTP_RESPONSE_204_OK_NO_CONTENT;
    pNetAppResponse->ResponseData.pMetadata = NULL;
    pNetAppResponse->ResponseData.MetadataLen = 0;
    pNetAppResponse->ResponseData.pPayload = NULL;
    pNetAppResponse->ResponseData.PayloadLen = 0;
    pNetAppResponse->ResponseData.Flags = 0;
    break;

    default:
    break;
    }
    }
  • 0 in reply to Gary Klinefelter
    Intellectual 780 points
    Adding the 204 response from my last post was not the solution I thought. I had turned on a packet capture app on my phone which seemed to have changed the dynamics. With Packet Capture on, I was receiving POST requests through SimpleLinkHttpServerEventHandler, at least until a POST would trigger a SimpleLinkNetAppRequestEventHandler. According to the Packet Capture App, there was no reply from the SimpleLinkNetAppRequestEventHandler when it received a POST. I am using an MSP-EXP432P4111 launch board to prepare code for a new board. I tried changing clock speeds and CC3120 boost boards with no change. If I delay the responses from the MSP432, I see the same result only delayed. Typically, with the Packet Capture App off, I receive 3 GET strings from our app that generate a SimpleLinkHttpServerEventHandler and then a POST that triggers SimpleLinkNetAppRequestEventHandler, after which the app throws an error. Any advice on what to try next would be appreciated.
  • 0 in reply to Gary Klinefelter
    TI__Mastermind 38980 points

    Hi Gary,

    Are you preparing the POST metadata and then sending a NetAppRequest back (sl_NetAppSend)? In the SimpleLink Academy I linked to in my first post, I do this in httpPostHandle(). The SimpleLinkNetAppRequestEventHandler does not have SlNetAppHttpServerResponse_t built in to the handler the way SimpleLinkHttpServerEventHandler does.

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Intellectual 780 points

    Hi Sarah,

    I did proceed with using the SlNetAppHttpServerResponse to respond to the POST.  It took me a bit to figure out how to add in the Server header, but once I did our app went through all the GETs through SimpleLinkHttpServerEventHandler and all the POSTs through SlNetAppHttpServerResponse without any problem.  I am in the process of implementing the POST parsing through SlNetAppHttpServerResponse as well. I am not sure why I don't reliably get POST tokens through SimpleLinkHttpServerEventHandler, GET tokens work fine.  It would seem to me that I am missing something. For the CC3100, we have 7 web pages with embedded GET tokens that correspond to 7 app pages which we program into the CC3100 flash.  (I used Fiddler on a PC to diagnose my POST response issues.  I the process, I noticed that if I send more than 3 GET requests on a repeat, some of the requests take more than a second to reply.  I may try using SlNetAppHttpServerResponse for the GETs to see if it is faster).

    Gary

  • 0 in reply to Gary Klinefelter
    TI__Mastermind 38980 points
    Hi Gary,

    Can you give an example of your GET tokens versus the POST tokens that aren't going to SimpleLinkHttpServerEventHandler?

    The new SimpleLinkNetAppRequestEventHandler method does pass preparing the responses to a thread instead of inside the handler the way SimpleLinkHttpServerEventHandler does, so it allows you more control of priority if you have other things going on in your application code. I don't believe it should add a ton of overhead since it should just change whether the metadata is prepared by the application MCU or the NWP, but please let me know if you see a difference.

    Best regards,
    Sarah
  • 0 in reply to Sarah P
    Intellectual 780 points
    Hi Sarah,
    The system we used with the CC3100 had this form. www.irrigreen.net/dashboard.html?__SL_G_UDB. dashboard.html was in the file system for the CC3100 with an embedded __SL_G_UDB in the html. The post was similar using www.irrigreen.net/dashboard.html with a post of __SL_P_UDB=Server:0 for example. __SL_P_UDB was not in the CC3100 file system. I have had some success implementing the POST using SimpleLinkNetAppRequestEventHandler, but I am getting a 500 internal Server Error. The phone ignores it so the app is able to POST values. When I switch the GET to SimpleLinkNetAppRequestEventHandler I get resource not found. When I process the GET and POST using SimpleLinkNetAppRequestEventHandler , the response is immediate and not delayed. If I implemented HttpServer.c, I would have a bit of work to add the characteristics and not sure if the /dashboard.html would be an issue.
    Gary
  • 0 in reply to Gary Klinefelter
    Intellectual 780 points

    Hi Sarah,

    I have fully implemented the legacy CC3100 tokens using SimpleLinkNetAppRequestEventHandler in turn calling SimpleLinkHttpServerEventHandler .  I like this solution because it removes the need to have special token files on CC3120 flash and it reuses our SimpleLinkHttpServerEventHandler code.  (The 500 internal Server Error mentioned previously was mine, I mistakenly put the response buffer inside the function so it wasn't persistent).  

    For the GET, I search through the TLVs in the request data to find the SL_NETAPP_REQUEST_METADATA_TYPE_HTTP_QUERY_STRING which is the token and check the token length.  I use the event and response data structures for SimpleLinkHttpServerEventHandler to pass on the token and get the data back.  We use multiple tokens which are processed by SimpleLinkHttpServerEventHandler .  When the GET response is returned, I wrap it in html because that is what our app expects.  The response is assigned to the payload and a Content Type header is added in the Metadata.  (No need for content length because the content is inside the html).  A Server header is generated automatically.  

    For the POST, the token is at the start of the payload and so I assign TokenName  and TokenValue (POST data comes after the token) in the HttpPostData structure for SimpleLinkHttpServerEventHandler.    The response is 204_OK_NO_CONTENT.  (I had trouble originally beacuse POST tokens weren't going to SimpleLinkHttpServerEventHandler ).

    For both GET and POST, the response is returned immediately.  For this limited case, this is much easier than adding HttpServer.c

    I did find one thing that appears to be a bug.  At first, the POST had no Metadata only a SL_NETAPP_HTTP_RESPONSE_204_OK_NO_CONTENT response and no Server header was being sent like in the GET.  When I added a Server header, I got 2 of them.  I guessed that there might have to be something in the Metadata to get the Server header so I put a single space character in the Metadata and the Server header was sent automatically.

    We can close this thread, thank you for the support.

    Gary

  • 0 in reply to Gary Klinefelter
    TI__Mastermind 38980 points
    Thanks for explaining your implementation Gary! We really appreciate it in case other customers are in a similar situation.

    I'll check on that last issue you ran into. I'm glad it seems that you've found a workaround for now.

    Best regards,
    Sarah