I would rather have a gateway implementation that you are happy
with, so if you feel any of the restrictions are too severe, please
consider relaxing them. Really the most essential aspect is to use
MQTTPacket and MQTTSNPacket.
Not relying on STL I think would probably still be really useful as
well though. The Paho C client has LinkedList and Red/Black Tree
implementations, if they are any use to you.
Thanks.
Ian
On 23/02/16 02:14, Tomoaki Yamaguchi
wrote:
Hi Ian,
The
moststringentrule for me is a dynamic memory allocation.
rules
in my mind are
1) avoid MEMORY LEAK 2)
Class instances and variables are
allocated in the heap areabeforeexecutionas much as possible.
I
started to re-write a List and a queue of STL which I'm
using in my Gateway.
I
want to upload the Gateway using
MQTTPacket and MQTTSNPacket by the end of April.
maybe that's too stringent, and we (I) should be more
flexible?
Ian
On 02/19/2016 02:04 AM, Tomoaki Yamaguchi wrote:
Hi Ian
no heap memory allocation - to make
memory use as predictable as possible => which means
new() can't be used. It is very difficult.
but I will do my best.
and then contribute it to Paho? => YES,
my pleasure
C++ Standard Template Library
(STL) not used – too heavyweight =>
no problem but need to change my
codes.
system APIs for networking, timing
and threading are implemented as
replaceable classes (template
parameters in MQTTClient) =>
those
are defined as classes but not
template classes. (Process
framework classes in page 6 of my
attached doc)
limited or no other system APIs,
for portability =>
no problem. Do you have a list of
available APIs ?
no heap memory allocation - to
make memory use as predictable as
possible =>
no problem but need to change my
codes.
And, just to be clear, a
transparent gateway means that a new
MQTT connection is created for each
incoming MQTT-SN connection. Is that
your understanding too?
=> My
G/W creates new connection when CONNECT
message is sent from clients.
Are there any thing I should follow ?
I'm expecting many people will help us.
your architecture looks good. You
are proposing to alter your
gateway code to use MQTTPacket and
MQTTSNPacket, and then contribute
it to Paho?
I had some principles which I
adopted for the embedded
MQTTClient API and which I also
hoped to adopt for a gateway:
C++ Standard Template
Library (STL) not used – too
heavyweight
system APIs for networking,
timing and threading are
implemented as replaceable
classes (template parameters
in MQTTClient)
limited or no other system
APIs, for portability
no heap memory allocation -
to make memory use as
predictable as possible
Does your code follow any of
those? None of these principles is
a show-stopper - I just want to
understand where your gateway
fits.
And, just to be clear, a
transparent gateway means that a
new MQTT connection is created for
each incoming MQTT-SN connection.
Is that your understanding too?
Thanks!
Ian
On 02/18/2016 12:23 AM,
Tomoaki Yamaguchi wrote:
Hi Ian
Yes I am.
I will propose the
Transparent Gateway
with MQTTPacket and
MQTTSNPacket.
My gateway
architecture outlook
is attached.
If you can accept my
architecture, I will
convert < MQTT-Sn
Message > & <
MQTT Message > to
MQTTSNPacket &
MQTTPacket.
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.
it's not ready
for use yet,
but I hope to
be working on
it over the
next few
weeks. If
anyone has any
comments or
suggestions
please feel
free to make
them.
--
Ian Craggs icraggs@xxxxxxxxxx
IBM United
Kingdom
Paho Project
Lead;
Committer on
Mosquitto