I only meant the core functions of MQTTPacket and MQTTSNPacket to be
used - in the "src" directory. I consider the helper functions in
the samples directory to be optional, just a helpful was of getting
started quickly. You can use those or not, as you see fit.
Does that make sense?
Ian
On 17/03/16 19:35, Tomoaki Yamaguchi
wrote:
Hi Ian,
I almost finished the gateway design except the
MQTTPacket.
It looks that the design concept of the MQTTPacket is
different from the MQTTSNPacket one's.
NetworkHandler is included in the packet as follows;
Packet . send( Network ) Packet
sends by it self through Network.
Packet . read( Network ) This
is very useful for client applications.
But, those do not fit for my gateway architecture.
The architecture requires;
Network . send( Packet ) Network
sends a packet.
Network . read( Packet )
Requirement of Paho gateway is using MQTTSNPacket and
MQTTPacket.
however, It is difficult for me to use MQTTPacket for the
gateway.
The gateway follows the mqtt-sn.embeded-c project directory
structure.
paho.mqtt-sn.embeded-c
/ MQTTSNGateway
/src
main.cpp
MQTTSNGatway.cpp
MQTTSNGWClient.cpp
MQTTSNGWPacket.cpp <=== Lapper
class of MQTTSNPacket MQTTGWPacket.cpp
<=== New class of
MQTTPacket
MQTTSNGWTasks.cpp
MQTTSNGWProcess.cpp
...........
/linux
linux.cpp
Network.cpp
SensorNetwork.cpp
Threading
/MQTTSNPacket
/src
..........
Do you mind if I create MQTTGWPacket class which has same
functions of MQTTSNPacket?
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