Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] MQTT-SN to MQTT Gateway

Hi Tomoaki,

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 most stringent rule 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 area before execution as 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.

Tomoaki

2016-02-23 9:15 GMT+09:00 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>:
Hi Tomoaki,

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.

Tomoaki

2016-02-19 10:47 GMT+09:00 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx>:
Hi Ian

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.

Tomoaki



2016-02-19 9:24 GMT+09:00 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>:
Hi Tomoaki,

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.

2016-02-18 0:35 GMT+09:00 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>:
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



On 02/16/2016 01:03 AM, Tomoaki Yamaguchi wrote:

What can I do for your Gateway ?

2016/01/07 23:02 "Ian Craggs" <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>:
Hello All,

due to a hackathon we held in IBM this week, I made a start on an embedded MQTT-SN to MQTT Gateway:

http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt-sn.embedded-c.git/tree/MQTTSNGateway

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

_______________________________________________
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


_______________________________________________
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


_______________________________________________
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


_______________________________________________
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


Back to the top