Can I get a callback or poll to make sure that an HTTP response has been received by the client?

I'm currently facing the situation where I have an HTTP server running and want to perform an action on the device after the HTTP client has received the reply that initiates the action.

This is about network configuration so I must not start with the action if the response hasn't been sent to the client yet. On the other hand I want the system to be responsive so I cannot simply use a larger waiting time.

TL;DR: I would like to know when the connection that is currently handled in the request_notify HTTP server callback is closed. Is there any way to get notified when this happens or to poll for it?

When I send the response with nx_tcp_socket_send and specify a wait option, is it guaranteed that the client has received the packet, confirmed the reception and has closed the connection when it returns NX_SUCCESS?

  • Hi Chris
    I sent you a response but apparently RR ate it or something. Anyway, no you cannot assume the client received the packet and closed the connection on success status. nx_tcp_socket_send returning success only means that the TCP layer was able to get the packet down to the IP layer. If it is dropped there or in the driver it fails silently. If the client receives the packet, it will send an ACK packet in which the TCP header acknowledgment number will indicate the data it has received.

    If the Client has closed the connection, the send call will fail because NetX checks the socket state before sending e.g. ESTABLISHED. I am checking with our dev team for how to get notified of the the HTTP server closing the connection. Any further details of your requirement for this would be helpful as this service is not available in the HTTP server (it is in native NetX services, but not HTTP server which intercepts netx services)
    janet
  • In reply to JanetC:

    Hi Janet,

    this is more or less what I expected from looking at the API and the source.
    I've seen some notification callbacks in the TCP layer, namely nx_tcp_disconnect_complete_notify and nx_tcp_disconnect_callback but I'm not sure if I can hook into these from outside of the HTTP server. One could maybe check for nx_tcp_socket_fin_received or a similar variable to determine if the connection has been successfully closed.

    The main scenario is the following:
    Our device serves an HTML page through which the user can configure the network settings of the device. The page sends a request to the device with the new network settings which the user wants it to use. After successful reception the device changes it's configuration to determine its new IP (possibly received from DHCP) and then reverts back to its old address while the client keeps polling the old address for redirection information. When the device receives such a request from the client it will send information about the new address to the client and switch back to the new address.
    As you can see there are two cases where the device will change its IP after a request from the client.
    Right now I handle this by putting the function calls which changes the IP in a queue which is handled in a thread's loop, so not directly in the HTTP server callback. This is working most of the time but I'm getting timeouts in the browser sometimes which might be a result of changing the IP before the connection is successfully closed.
  • In reply to ChrisS:

    Sorry Chris, I still am not picturing this. "The page sends a request to the device" means, your http server sends a request to the client or the http client sends a request to your https server? Who is the user, is that the http client or the http server developer? And why does the HTTP client or server have to tell the other of a different IP address to use? Normally servers do not change their IP addresses if this can possibly be helped. I have never heard of a client telling an HTTP server to change its IP address...?

    So please clarify who is page, who is device and who is user? Then I think I can piece together your scenario.

    Sorry to be obtuse here. You are correct that the HTTP server socket would 'intercept' all callbacks from NetX so that tactic would not be possible to use.

    Janet
  • In reply to JanetC:

    Hi Chris,

    I discussed with our development team what you were trying to do (which they seemed to grasp better than I). Here is their recommendation:

    It sounds like the problem is beyond the scope of the NetX HTTP server. But here is our solution if we were going to solve it:

    Client Server
    1 POST /config
    2 Respond /config
    3 Perform DHCP
    4 Revert old IP address
    5 GET /get_ip
    6 Respond /get_ip
    7 POST /update_ip
    8 Respond /update_ip
    9 Set IP address from DHCP


    The customer wants the response of (6) to be received by the client and than perform (9) directly. But there is no mechanism to assure that. To make sure the client has received response of a new IP address, the client should initialize the request "update_ip" to notify the server it has received the new IP address and the server can change its IP address now.

    Let me know if that helps.

    Thanks and happy holidays!
  • In reply to JanetC:

    Chris, looks like Renesas Rulz munged my formatting. Let me know if you need clarification what the client sends and what the server sends back.
  • In reply to JanetC:

    Hi Janet,

    doesn't that approach delay the issue to /update_ip? How can the client know that the server has successfully received the POST to /update_ip and didn't time out because of packet loss or similar issues? It would have to POST the call multiple times until it times out (then the server has changed IPs) or is confirmed (if old_ip == new_ip).
  • In reply to ChrisS:

    Hi Chris

    Warren Miller is asking me to close out or followup on this post. Is it still an issue, or did you find a resolution? If not where in the sequence I suggested,

    Client Server
    1 POST /config
    2 Respond /config
    3 Perform DHCP
    4 Revert old IP address
    5 GET /get_ip
    6 Respond /get_ip
    7 POST /update_ip
    8 Respond /update_ip
    9 Set IP address from DHCP

    Normally the HTTP server initiates the disconnect request. If the browser is timing out possibly due to a previous connection taking too long to close, can that NX_HTTP_SERVER_TIMEOUT_DISCONNECT which is defaulted to 10 seconds, but reduced?
  • In reply to JanetC:

    Hello Janet,

    I think this issue can be closed. I might need some more testing but so far it seems reliable enough. I'm not sure about reducing the timeout but I will think about that when the issue comes up again.
    Thanks for your support!