I’ve had a good hunt through the docs and can’t seem to find the answer to this simple question. If I have an internet based event, what is the longest time it will take for the imp device to get it, assuming connection and internet speed is all good?
The imp can be connected to the server permanently – discounting outages, obviously. This means that an agent -> device event is limited only by connection latency.
If you choose to run your device in offline (intermittently connected) mode – to save battery, for example, then it’s up to you when the device connects.
Read http://electricimp.com/docs/resources/offline/ for more details.
Thanks.
But presumably the imp, even though connected, has to send a request to the server to get any new event notification? How often does it poll the server to achieve this?
In fact it won’t really be connected to the server permanently at all if it operating over http protocols, it will be connecting via TCP, sending a HTTP request, getting a response and disconnecting every time it carrys out a poll. I can’t find a resource which details how often that occurs and if it is adjustable.
I can assure you in practical terms that the round trip from pushing a button on one imp, message going to its agent the other side of the world, talking to another agent, telling its imp to turn on an led, and all the way back again to confirm the led is lit, takes under 200 milliseconds.
The agent is not polling the imp for messages, they are sent actively and very rapidly, as long as you have a live wifi connection. If the connection is inactive, it takes another second or so to re-establish.
Thats not what I’m asking, I appreciate that connecting over the internet is fast. If I have an internet based event (not an imp based event), what is the longest time it will take for the imp device to get it, assuming connection and internet speed is all good?
I.e. I send the server an event from somewhere else that requires the imp to turn on a LED. What is the longest time it will take for the imp to get that message. This will be a critical infrastructure issue for electric imp as they don’t want the massive load of every imp device out there polling their servers too often, so there will be a time period set so that each imp only connects to ask for any new messages every # seconds. This is what I can’t seem to find any information on.
To put it in context, I am standing in front of an object containing an imp. I have my phone viewing a web page which has a button that tells this object to do something. I press the button. What is the longest it will take for the imp in front of me to get that event and react?
Sorry I misread your message slightly incorrectly, but I believe you are still incorrect. Sure the time from pressing the button on 1 imp and it sending that message over to the server is very fast. However the server being able to pass that message onto another imp will not be instant as the server can’t connect to an imp, imps have to connect to the server. The servers can’t possibly maintain live connections with every imp out there of this system wouldn’t be able to scale, so the imps will be polling, connecting periodically to check for any new message.
The servers can’t possibly maintain live connections with every imp out there of this system wouldn’t be able to scale
On the contrary, that’s exactly what we do. Scaling idle TCP sockets isn’t actually that hard.
Peter
Wow, I’m very surprised as that presumably limits you to 65535 imp devices per server IP address. I stand corrected, I’ve not come across anyone taking such an approach before on a system that needs to scale. Is this a core system design decision that will always be retained or might you change in the future if the number of active imp devices grows to much? Not being critical BTW, if this is the way it works and always will then that is great for the application we have in mind…
Also it might be worth mentioning this somewhere as I couldn’t find it and its a very attractive feature of your system that I expect others with a lot of low level networking knowledge might make the same wrong assumption about.
FWIW it’s not really the case that every client needs its own port number on the server: http://stackoverflow.com/questions/5945695/number-of-network-connections-possible
Peter
As Peter notes, TCP doesn’t actually limit you to 65535 connections per server IP; on our end, every device is on the same port number (as they all connect to port 31314). The kernel distinguishes connections by the combination of remote IP, remote port, local IP, local port.
There’s no issue with scaling, I assure you 
Not that we’d go this far, but here are some scaling tips to run 12 million concurrent TCP sockets on a linux box:
Very funky, glad I asked!
I've not come across anyone taking such an approach before on a system that needs to scale
I suspect you have. The iPhone and Android phones are all connected to their backend servers for push notifications in the same kind of way. Any website that uses websockets is doing the same. Even HTTP long polling (aka Comet) stays connected and is a very common tool for real-time (or real-time-ish) websites like stock tickers and auction sites. Look at services like PubNub and Firebase for examples of permanent or near-permanent connections that scale very well.