I’m having a little uncertainty about the amount of data that is being used. I retrieve a web page that is a total of 3 bytes. However, for that session it states I use 1.49kbs for the session. What is the likely cause of the majority of the extra data?
Ok I’ve read through a lot more threads and this is where I’m at. The HTTP Service built into SIMCOM runs on TCP / IP stack and has high overhead.
To reduce the amount of data I am consuming, it is best to implement UDP Connection, especially considering I’m only sending one packet. I’ll have to do some more research on the reliability of UDP however.
I am pretty surprised that the overhead for the TCP connection is so high. Has anyone using SIMCOM experienced similar?
HTTP is a pretty high overhead protocol. It’s fine if you’re using an unmetered connection. UDP is a good choice to save data, but there is no error recovery and you will not know if packets you send actually arrive. My own experience after sending tens of millions of UDP packets is that a very small fraction of 1% of packets get lost.
Hmm thanks all for responses. I’ve since implemented UDP but have only reduced it to 564 bytes. Given my data is 62 bytes, I’m a bit unsure where the remainder of the bytes are going considering that I’ve seen it stated that UDP overhead is under 100 bytes.
Do you use the IP address or domain name to send data? A domain name lookup will use a few hundred bytes and may perform the lookup over TCP if the body is large.
Of course if you hardcode an IP address you save the bytes but are in big trouble if you lose access to the static IP.
Andrew you are a legend! I never even considered the data consumed doing a domain name lookup. Now getting 130 bytes data, which would be ~70 bytes my data and ~60 bytes UDP overhead.
Thanks again,
Trent
@AndrewGifft’s point about the potential problem of using an ip address to contact a server and latter losing that static ip address may seem unlikely, but it actually did happen to me. The whole system was an IoT one and all devices were deployed and mobile. It was a nightmare.
The data packets I was sending were only 17 bytes long, and I couldn’t bear to add so much DNS lookup data, so I created and deployed a solution like this:
I use a fixed ip address to contact the application server, same as I was doing.
I also put up a second, very simple server which I call a “server-server.” This server can be accessed by a URL. When contacted, all it does is respond with the ip address of the application server.
The application attempts to contact the application server using the fixed ip address. If it discovers the host is unreachable, or the server isn’t responding appropriately (maybe the ip address was lost by the application server and is now being used by an entirely different server) it contacts the server-server to get the proper ip address of the application server.
If, for whatever reason, the ip address of the application server must be changed, the server-server is tweaked to provide the new ip address of the application server.
The overwhelming majority of the time the application will connect to the application server correctly using the fixed ip address. Only rarely will the application every need to contact the server-server and use the additional bytes necessary for DNS lookup.
I’ll also mention the the server-server can be implemented as just a few lines of php code. just a few lines of php