Device-Agent Data Size

Device Code
1

I am trying to transfer four data points to the agent every 10 minutes. Since the communication is through a WiFi GPRS router, I need to cut the data size down as much as possible. Here is a snippet of my code -

local out = blob(64);
local myname = 201506026;
local lasttime1 = 1434907368;
local laststate1 = 1;

        out.writen(myname, 'i');    
        out.writen(lasttime1, 'i');
        out.writen(hardware.voltage(),'f');
        out.writen(laststate1,'w');

agent.send(“post”, out);

Every transfer seems to use 5kb of data. This seems a lot of overhead for transferring what is essentially 160 bytes of information. I am wondering if there is something I am missing here. Can anyone help?

Thanks.

2

Are you disconnecting/reconnecting for each point? The TCP connect, TLS certificate exchange, connection negotiation, etc is several kB.

When connected, data overhead is fairly small - there’s IP and TCP headers, then TLS overhead per packet (32 bytes, but there’s rounding on the data size).

Link maintenance happens at two levels - TCP level every ~60s (from memory, maybe 50ish bytes each way) and TLS level on average every 4.5 minutes (more like 100-150 bytes).

3

Hugo - I am disconnecting every time to save on power. Its running on batteries. So is 5kb per transaction to be expected? Can that be reduced?

4

No, that’s about right, and cannot be reduced. There’s a full TLS connection setup there as I said, which means a couple of kB in each direction for the crypto. Whilst 5kB is a bit painful over GPRS, it’s really not much in terms of most data plans at least in the EU or US.

In theory we could do TLS session resumption, but we have not implemented this at this point. That’d cut it down quite a lot, but 5kB isn’t generally a problem for most use cases.

5

OK Thanks. Good to know. Yes in most cases this should not be an issue. But since I dont get any benefits of scaling when the number of devices grow, I need to plan for not being on gprs for larger installations. One vote for TLS session resumption in case it is possible.