One TCP Socket for Multiple Client over Wifi Connections ?

[AhFai Chan]

My current project requires connecting to multiple data loggers on the client side. The client's mechanism is relatively simple, possibly an ESP8266 with TCP/IP or an older Arduino UNO with an add-on Wifi shield.

I need to collect client data using my laptop as a local server (its running Windows 10).

QUESTION:  Is it feasible to use one socket (e.g. 192.168.3.123:80 ) to cycle through a hundred or more data loggers? Seeing how 192.168.xxx.yyy is only used locally without Internet access, is this the wrong approach?

[Ron McLeod]

Do you have to use TCP?  With UDP you could re-use the same socket for sending to each logger - just change the destination address and send again.

Also, if the client and loggers are on the same subnet, you could possibly broadcast your message to the loggers (provided that this is supported by the client, loggers, and WiFi infrastructure).  This would also have an advantage that neither the client nor the loggers would need to know about each other in-advance.

[Ron McLeod]

One concern with UDP is that since not a reliable protocol, messages may get lost or corrupted in transport.  To help mitigate these potential problems, you could frame the payload with a sequence number and checksum, and send (broadcast?) the message multiple times.  The logger could verify the integrity of the messages using the checksum, and look at the sequence number to check it had already seen the message.

If the client device isn't battery-powered, you might also want to re-send the last send message periodically, as a mechanism for loggers to discover the client.

[AhFai Chan]

Thanks for your suggestions about UDP.

Really, the loggers are very primitive and they use either (Ritchie & Kernigan) C or something called "Luv", it is not where I can write a hundred or more lines of codes. It does strange things to me switching from C to Java and SQL.

I might have jumped the gun again, but I have decided to try the basic Arduino board and plug a WiFi shield onto it. The new WiFi shield alone can handle the client side data logging from the sensors, but I already have the Arduino in hand and I am going to take it from there.

I can always have a few background threads running (our old friend Runnables), each thread with a different socket... which means I have to read up on Java's "synchronize", maybe that's a solution... try that and see whether that works.

Thanks.

[Tim Holloway]

I wrote a detailed reply to this yesterday and it seems to have totally disappeared.

Briefly: Arduino with a WiFi shield is something you only want to do if you have a whole box of them laying around cluttering up the place. Those things are expensive. The ESP8266 was designed to replace such devices with an inexpensive breakout module and it does the job very well indeed. You can easily buy them for under USD $5 each and they are so powerful that despite originally being intended as a peripheral to the Arduino, they can in many cases replace the Arduino entirely.

On the network front: Don't use UDP unless you can afford to lose data without a trace. But if the clients contact the server, it's actually common practice for many clients to connect to a single server TCP/IP port. That's how the web works. In fact, the HTTP protocol leverages that by using "one-shot" messages so that the client connects only long enough to send a request and receive a response so that server reply sockets don't have to be tied up all the time.

As a rule, you want the clients to be able to contact the server, not the other way around. Making the server do the contacting means that your networking resources will probably be under more stress. And it means that every time you add/remove a client, you have to tell the server explicitly about it.

Whether it's WiFi or wired, the basic networking constraints apply. For the 192.168 class C subnet there are 65,533 allowable client addresses that can be used at any given time. With DHCP those addresses can be leased making for a potentially unlimited pool of clients.

However, long before you reach such limits, you'll discover that the real limit is the LAN. If you're going to keep it all on one LAN segment, a single switch will generally not be able to handle more than a few dozen clients. After that you have to get more creative.

The 192.168 subnet is not routable over the open Internet, so if the server is not on the same LAN as clients then your client addressing gets more complicated.

Finally, another alternative worth considering is LoRa. LoRa is designed not only for many clients, but also for a range potentially measured in kilometers. It works best when the client is going to be transmitting a short burst of data every few seconds or minutes and it has the additional virtue of being very frugal with power requirements. The downside is that LoRa is not a TCP/IP protocol so it must communicate with a gateway machine. Many cities have public gateways and there are IoT (Internet of Things) cloud services that can do useful work using data received via a public gateway, but you can also set up your own private gateway.

[AhFai Chan]

COOL. Thank-you very much for the advice. Your advice dovetails into some writeups and other advice I received on other forum, but being a noob, I have already started with Arduino. I will get the loggers working with the sensors and write the codes, then replace totally with the cheaper ESP8266.

I cannot afford to loose data as each tank constitutes an investment and ongoing revenue for the clients. The logged data will be HTTPS-ed to a cloud mySQL (that part I have got working already).

Very cool response here, thank-you again for your input.

As a rule, you want the clients to be able to contact the server, not the other way around. Making the server do the contacting means that your networking resources will probably be under more stress. And it means that every time you add/remove a client, you have to tell the server explicitly about it.

Whether it's WiFi or wired, the basic networking constraints apply. For the 192.168 class C subnet there are 65,533 allowable client addresses that can be used at any given time. With DHCP those addresses can be leased making for a potentially unlimited pool of clients.


The power supply at client end is minimal.

[AhFai Chan]

I can get a LoRa module/modem unit for around $30 or €23 for the IoT I have in mind next.
https://www.loriot.io/modems.html
https://www.robotshop.com/en/lora-gps-long-range-transceiver-hat-915-mhz-north-america.html?gclid=EAIaIQobChMIyfnxhb-j2gIVRFcNCh2u8wkhEAYYASABEgKfYvD_BwE

[Tim Holloway]

I think I got a pack of 5 modules for around USD $20 on Ebay. Although there are a couple of things to keep in mind.

First, the radio frequencies used for LoRa vary by country and the USA runs in a different band from Europe, for example. Also some units run on 433 MHz, which may or may not be actually standard for LoRa (I forget), but technically in the USA if you run more than a miniscule amount of power on 433 MHz you need a radio license. It's part of the US amateur radio experimenter's band.

The actual radio chips are often programmable over a wide range of frequencies, and thus capable of operating in 2 or more of the bands I mentioned, but specific boards might not be able to allow them to.

Lower prices generally mean lower range and lower quality. Plus I think I ordered direct from China, which means a longer wait and a need to be somewhat cautious, since while some Chinese vendors are rock-solid, some aren't always dependable. I was ordering for future experiments, so in my case the added risks and delays were worth it.

I think the RobotShop Raspberry Pi HAT is intended to use for setting up a gateway. There's also a ready-to-run Pi-based gateway available from them, but last time I checked, they were out of stock with no known restocking date.

You can also set up an Arduino with LoRa and jack it into a server computer for a gateway if that's more convenient.