I ran into a problem with the httpclient when used with the Photon. What I found to be happening is the httpclient relies on the the TCPClient to become disconnected before it stops polling the connection for response data. On the core this disconnection happens relatively quickly, but does not on the Photon I always timeout the polling loop.
I played around with the code such that I now exit the polling loop immediately once data is received not waiting for the connection to close. A normal response from my server is in the range of 128 bytes and I have not seen any multiple packet responses but I am kind of worried by my approach that it will cause problems in the future.
I am very interested in hearing others thoughts on taking this approach to fix this.
I also wanted to thank @nmattisson for making this library available in the first place.
@HardWater and @kennethlimcp, this is something I asked @mdma about. I have an outstanding question to him in response to his comment that doing a client.flush() and a client.read() will cause the disconnect condition to be detected by the Photon as it should. However, I have not tested this and I presently use the timeout method like you do.
I’m sorry that I haven’t been able to chime in on development of HttpClient lately. I wrote it because I needed it when prototyping Point (www.minut.com) which has since taken on a life of it’s own and currently occupies all of my time.
If someone feels like taking up ownership of the project on github, feel free to ping me.
@nmattisson can you add @peekay123, @bko as the collaborators so that eventually we take that under our wings at least to make sure things work ok? Thanks!
I am having a real problem with using the httpclient library to send multiple requests on the Photon.
I am compiling locally using the photon_043 branch
What I am finding is the first request gets transmitted as it should but the next request fails at the call to client.connect() It seems the code never returns from client.connect()
To test what was happening I added these serial print commands to the httpclient code
@HardWater, I saw similar behavior with some code I ported to test a Nextion HMI display. It seems that client.connect(HOSTNAME, port) does an SOS (WDT) if it can’t resolved the hostname, or at least it appears that way. The call to client.connect() never returns.
My setup pulls weather data from api.wunderground and the client.connect() call occurs every hour. It seems to be hit and miss where the Photon will sometimes go into a reset loop (after SOS) for a while and then recover and pull data. On a Core with the same code, locally compiled with the same library (but for Core target), it doesn’t have the same behavior. I raised an issue on the firmware repo and pinged @mdma.
Thanks @peekay123 for the confirmation you have seen it too.
I was thinking there was a need to put a client.flush() before the client.stop() even though all data has been received but that did not help at all.
As for difficulty resolving the hostname that might be the problem but for clarity I would say both requests I am trying to send are to the same hostname.
@peekay123 I am continuing to drill down to find out where this problem is. What I have found out so far is the problem occurs at this call in spark_wiring_tcpclient.cpp
uint32_t ot = HAL_WLAN_SetNetWatchDog(S2M(MAX_SEC_WAIT_CONNECT));
DEBUG("_sock %d connect",_sock);
//gets here first and second request
connected = (socket_connect(_sock, &tSocketAddr, sizeof(tSocketAddr)) == 0 ? 1 : 0);
DEBUG("_sock %d connected=%d",_sock, connected);
//gets here only on first request on the second request WDT seems to trip before here
@mdma is this something that you would be looking into or is there someone else that should be pinged?
@mdma Making further progress on finding where the problem happens here is part of socket_hal.cpp
sock_result_t socket_connect(sock_handle_t sd, const sockaddr_t *addr, long addrlen)
{
sock_result_t result = SOCKET_INVALID;
socket_t* socket = from_handle(sd);
if (is_tcp(socket)) {
wiced_result_t wiced_result = wiced_tcp_bind(tcp(socket), WICED_ANY_PORT);
if (wiced_result==WICED_SUCCESS) {
wiced_tcp_register_callbacks(tcp(socket), socket_t::notify_connected, socket_t::notify_received, socket_t::notify_disconnected, (void*)socket);
SOCKADDR_TO_PORT_AND_IPADDR(addr, addr_data, port, ip_addr);
unsigned timeout = 5*1000;
//-----------> gets here on first and second request
result = wiced_tcp_connect(tcp(socket), &ip_addr, port, timeout);
//-----------> gets here only on the first request WDT reset before here on the second
}
if (result!=WICED_SUCCESS)
{
result = as_sock_result(wiced_result);
}
}
return result;
}
I do not seem to be able to get closer to the problem as I cannot find the source for wiced_tcp_connect() I am assuming that is part of the WICED binary image. Please Help?
Hi @Rockvole I took a quick at the httpclient library that was modified by @mojtabacazi
It looks to me as it should have the same problem I am experiencing today when used on the Photon. I believe the problem lies at the lowest levels of setting and closing tcp connections. The other idea of what it could be is the the WDT is not set correctly second time around.
Just confirmed this problem does not exist with the photon_042 branch. Which is good news that it has not always existed but bad I need other features that are part of photon_043. I think @peekay123 alludes to this fact that this was not a problem before. Just thought I would check for sure.
