I was under the impression that in NB IoT world, if the client device enters PSM mode, it can actually retain both the IOT network registration and also the TCP IP connection session. so when it wake up from PSM, it can quickly send data and go back to sleep again. but in my case, it imitates disconnection of the PDP session before it enter PSM. Is this normal ??
Currently I am using a dev client system based on Qualcomm 9205 modem connect to LTE Cat-M1 network.
the client will wake up every 10min to send a small chunk of data (100byte) to the AWS IOT service, it uses MQTT as the messaging protocol .
ideally I prefer the device to initiate the MQTT connection with the server once, then after it goes to PSM sleep, the client side remembers the MQTT connection, so when it wake up, it can just send the data via MQTT without re-establish the MQTT connection again.
Unfortunately, I realise the real behaviour is: when I ask the modem to go to PSM sleep, it will drop the PDP connection (which means the TCP/IP session is lost, so does MQTT ), so when it wake up, it will take extra 5-10 seconds also to re-establish MQTT connection again before sending data. this is a waste of both time and additional data communication.
Any suggestions?
Related
I’m working on an iOS App, where I’ve added NE Packet Tunnel Provider and using Network Path Monitor to detect when any switch between Wifi and Mobile Data is happening. If any switch in Network path is detected then canceling the Tunnel and restarting it again, in between the process few packets are being dropped. I wanted to know if anyone knows if it’s possible without canceling and restarting the tunnel, can we reset the process so that it works seamlessly.
MQTT protocol works on pub-sub concept. Client can subscribe and publish topic to the Broker. Clients who are sensor kind of thing can publish respective topics (temperature, humidity, switch on/off request etc) to Broker. Broker will send the respective data to the subscribed clients (display device, any device which can on and off).
Broker usually hosted on open internet.
I'm not getting the point how Broker will send the information to client device as the wifi connected device usually couldn't be reachable from open Internet as there will be no public IP assigned to such IoT devices. (I mean to say IP communication from Open internet to IoT device should not be successful)
The connection to the broker is established from the client to the broker, as this is an outbound connection as far as any home router/NAT device is concerned it will work just fine (in the same way a web browser would open a connection to a HTTP server).
The connection is also persistent, meaning the client opens it and keeps it open for the lifetime of the client. This means that the broker always has an open connection to forward messages to the client.
At no point does the broker try to connect to the client.
I believe I read that the peripheral side cannot terminate a connection?
terminate a connection CBPeripheralManager side
How then, can we authenticate a connection at the application level? We are making an iOS app connect to another iOS app, we only want them to connect to each other. After connection they exchange private-key-based challenge/response questions, and a failure should result in a refusal of the connection. This of course works fine on the central side, if it doesn't get the correct reply it closes the connection. But if the peripheral cant cancel the connection, then how do we prevent a different central from connecting, and staying connected to the peripheral?
When a central connects but does not authenticate correctly, do not respond to requests from it. Every CBATTRequest includes the requesting central, and updateValue(_for:onSubscribedCentrals:) lets you control which centrals you respond to.
If they're not authenticated. Don't talk to them. Or more correctly, send them .insufficientAuthentication to all their requests. If they are well behaved, they will disconnect. If they are badly behaved, there is nothing you can do about that (this is always true; even if you could disconnect them, they could still flood you with connection requests).
You cannot force them to disconnect, however. They may be communicating with another app, and you are not allowed to stop that. You can only refuse to talk to them yourself or send them errors.
I have a voip app for ios, based on webrtc. I also have a signaling server made with nodejs. I can connect to the server and make calls without a problem. But tracking presence (online/offline) accurately is a problem.
Just for the record, here is a list of everything I did to ensure a stable connection:
Set the background mode "Voice over IP"
Flag the inputstream as a voip stream with "[inputStream setProperty:NSStreamNetworkServiceTypeVoIP
forKey:NSStreamNetworkServiceType];"
Turned on persistent wifi by setting "UIRequiresPersistentWiFi" to YES in the plist file
I implemented "setKeepAliveTimeout:handler:" and I use it to send a ping to the server (unnecessary, but you never know...)
I created a small test app that does nothing more than connect to the server and respond to "ping" with the message "pong". This app sends "ping" to the server when the keep alive timeout handler fires and the server replies with "pong". I also created a simple test server that does nothing more than let clients connect, send "ping" to a client when I send "send_ping" to it via telnet and responds to "ping" with the message "pong".
Here is my client code
What I expect is the following:
Starting the app and signing in should create a persistent connection to the server (works)
Telnetting into the server and typing send_ping makes the server send "ping" to the client and the client should send "pong" back (works)
Putting the device in standby should have no effect on the above ping-pong mechanism (doesn't work)
Putting the device in standby and unlocking it after a few hours, then sending a ping to it should make the client send a pong back (works)
Turning off wifi on the client (without cellular enabled) should be detected on the server-side and kill the socket (doesn't work)
I log all messages from the server in a textview on the client with a timestamp, and sometimes when I put the device in standby the pings I send from the server just don't arrive at all. Sometimes it takes over a minute for the app to receive the ping message, sometimes it responds immediately. I don't understand why it is so random. Sometimes this undesired behaviour starts after mere minutes in standby mode, sometimes it goes alright for a while but breaks after 20+ minutes, sometimes all messages from the server arrive at once as soon as I unlock the device.
Push notifications and voip push notifications could be a solution, but they are also slightly unreliable. There should be a way to make this work 100% of the time.
I've been reading about MQTT and I understand it uses TCP for network transport. So if I have a mobile app that will send subscribe request, I presume this will be an full-duplex connection so the client can be notified for incoming pushed data.
How then is this more battery and network efficient? I mean you still established an open TCP connection. Also how does it handle disconnection, does it auto-reconnect to the broker?
Taking into account my comment on the question, assuming you want to compare to HTTP Long polling these 2 links may help to answer your question:
https://www.ibm.com/developerworks/community/blogs/sowhatfordevs/entry/using_mqtt_protocol_advantages_over_http_in_mobile_application_development5?lang=en
http://stephendnicholas.com/archives/1217
TL;DR version:
The message sizes tend to be significantly smaller with MQTT vs HTTP (especially when you take into account all the http headers that get sent), this saves on network usage and in turn battery usage.
As for the reconnect side of things, the client libraries do not automatically reconnect but they do trigger a call back when the connection drops so you can handle reconnecting as required.