Emailed Support about this…
Is there any way to force a disconnect? The docs say that a client will be disconnected after 60 minutes of being idle.
However, in my app, if I close the connection from my end… and reconnect after a few minutes, I get N+1 ‘connection_opened’ messages (one for each time I connect)… so on the 2nd close and 3rd connect, I get 3 of the ‘connection_openend’ messages.
If I could send a JSON disconnect packet …
–Sam
For each “listen” you sent you need to send a stop:
{
“type”:“listen_stop”,
“device_id”:1110,
“id”:“2098388936”
}
{
“type”:“listen_stop_events”,
“station_id”:2594,
“id”:“2098388541”
}
{
“type”:“listen_rapid_stop”,
“device_id”:1110,
“id”:“2098388587”
}
It’s documented here:
I do that already. I even force my WS connection closed on my end… but still get the extra ‘connection_opened’ responses when I reconnect.
When you send the stop, do you get back the ACK?
What method to you use to close the connection?
I do get an ‘ack’ for each stop message I send. Just verified that…
I have two otions, a ‘close’ command and an ‘abort’ command. Both close the connection, just ‘close’ sends any pending data, while ‘abort’ does not.
Using ether route, I get the same results.
I’m pretty sure it’s because on the WF side:
Other Useful Information
A client should only open one websocket connection.
A client will be disconnected after 60 minutes of idle time.
All messages are JSON strings.
I’ve never had the issue. Something is not being closed properly.
After you is issue the stop commands, wait two minutes before you discount to see if any data comes in.
After you send the disconnect command send a listen command and see what is returned.
Ok. Issued the stop commands… and waited for over 5 minutes… no new messages came in.
What ‘disconnect’ command? Do you mean after my ‘close’ or ‘abort’?
As a result, I am getting multiple messages pushed… if I do the start/stop multiple times, then I get that number of messages (ie, 4 stop.starts on my AIR, I get 4 obs_air messages).
I use the websocket functionality in my Python code and have never observed this issue. I concur with @GaryFunk that this isn’t an issue with the WF websocket, and it must be to do with how your code is closing (or not closing) the connection.
When you want to disconnect from a web socket, you send a packet with an opcode 8 to the server.
Got it figured out… seems you have to invalidate your websocket object to get it to fully disconnect. So yes… it is on my end.
Along those lines… when does the 60 minute close come into play?
My impression is that if the device you are connected too stops sending data, the connection will be closed after 60 minutes. Happy to be corrected though!
Since the docs say:
A client will be disconnected after 60 minutes of idle time.
And the client only waits for data from the server… When is the client considered “idle”?
I will suggest the idle state starts after a packet is sent from the server AND received by the client.