5 years, 5 months ago.

stability of IOT architecture

Hi all, I have developed the internet of things application using K64F mbed board. I deployed my own java based websocket server. My architecture is as follows:

1) Mbed board with Rf sensor (websocket client) 2) Websocket Server java based 3) Client Application displaying sensor values

I have observed if there is no communication between server and clients for more than 15 mins the websocket link between them goes down. I then read that by default timeout session is 10-15 minutes in websocket protocol, and the solution for it is to deploy the ping pong messages.

I implemented the ping pong messages but they are putting the burden on the network plus they are not efficient as well, I observed that the link still some times goes down after 6-7 hours. Does any one know the permanent solution for it? How can we set the timeout session value in websockets?

Thanks in advance, cheers

still learnig IoT - why do you have to keep that socket connected? - isn't there any 'id' information sent when you first establish the connection?? - (similar to requesting a webpage - it doesn't keep alive for too long) ' the 6-7 hours almost sounds like you might be running out of a 'space' of some kind - heap, stack, etc. FWIW - Gary

posted by Gary Z 13 May 2015

I am developing a application which is related to health sector so I need to connect to the end server at all times. usually by default timeout interval is 15 minutes for websockets. In order to cope with this issue i am sending some dummy messages like keep alive, which has increased the timeout interval, but still after some time , the connection goes down

posted by zain aftab 14 May 2015

1 Answer

5 years, 5 months ago.

You may want to consider MQTT: https://developer.mbed.org/cookbook/mbed_Client_for_MQTT or https://developer.mbed.org/teams/mqtt/ or https://developer.mbed.org/forum/team-11-mqtt-community/topic/4797/ and the MQTT Broker http://mosquitto.org/

I have found that MQTT has a much smaller overhead and therefore a lower bandwidth requirement.