Hi Paul,
my plan is that the networking classes be replaceable, as
they are for MQTTClient. The intention is that networking
classes can then be written for UDP, ZigBee or any
suitable networking transport, even serial.
So, you are seeing this as more of a toolkit or
framework, with integration with other components at the
code level, rather then a service which would be integrated
at the system level.
Do you have an intended scale in mind? If we keep the
gateway super tight and constrained, I'd have some concerns
with a lot of clients; for example, if I have a couple of
hundred MQTTSN clients or more, and we run without threads
or async calls, there could be quite a bit of data loss
while we spin up TCP connections to the MQTT server
(especially if TLS is used) as the MQTTSN clients will be
blocked, and there is a fair chance they are using poorly
buffered serial connections. Using async or threads would
likely demand usage of dynamic memory usage or considerably
more complexity.
Maybe two should target two gateway profiles: A
"powerful" one intended run on something with lax constrains
(lets say raspberry pi as the lower end) and a very
constrained one, intended for fewer clients.
Or maybe (as has been known to happen) I am worrying for
nothing.
In any case, I'm certainly willing to run some testing.
