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.
If you have followed the conversation with Tomoaki then you will
have some more detail. What would be really useful, when it's ready
will be testing, including "porting" to the environment you are
interested in.
About aggregation. This is the sort of mode that RSMB acts in,
receiving MQTT-SN connections and then an MQTT bridge connection.
The bridge topics are configured separately to the incoming MQTT-SN
connections however. How would you see subscriptions working in
aggregated mode? I guess we could track the subscriptions made by
each MQTT-SN subscriber so that we know which of them to distribute
messages to.
In RSMB we did implement multiple MQTT connections over one TCP
socket, which had some of the advantages of both worlds (as long as
the TCP connection was reliable).
Ian
On 02/17/2016 04:57 PM, Paul Kierstead
wrote:
Oh wow, I totally missed the start of this (January
was a wreck). I've written one in python specifically aimed at
XBee (pretty narrowly written for my needs, and not terribly
robust) and would love to replace it. My main requirement is
that it be very flexible on taking MQTT-SN input, either via
some piping type mechanism or plug-in architecture type of deal;
sure you could write it to take UDP and then write an agent that
takes the input from something like an XBee and forwards it on
UDP, but that is heavy and icky. Aggregation is definitely a
nice to have, would make a great 'future'.
I am willing to contribute effort/testing. What do you
need?
PK
Hello Tomoaki,
are you the Tomoaki who has his own MQTT-SN client and
gateway ( https://github.com/ty4tw)?
Nice to hear from you!
I would like to have an MQTT-SN gateway which prioritizes
being "transparent" but can be "aggregating" too (as the
terms are used in the MQTT-SN specification).
I intend it to be portable in the same way as the existing
embedded MQTT and MQTT-SN Paho clients are. I realize that
there are other gateways out there, including your own, but
I wanted to have one which was based on the MQTTPacket and
MQTTSNPacket code, similar in structure to the Paho embedded
client so that they would make sense as a family. In that
way, I imagine they will be easier to maintain and more
reliable that way.
My first immediate goal is to substantially finish the
coding, getting the gateway working on Linux, before moving
to ARM mbed, Arduino and other environments. I'd welcome
collaborating on the coding and testing.
(For anyone that's looking, the repository has now moved to
Github:
https://github.com/eclipse/paho.mqtt-sn.embedded-c/tree/master/MQTTSNGateway)
Ian
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
|