Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Please Try Out the MQTT-SN Gateway
Ah, that brings something up!
I see that you have implemented a keep-alive timer in the gateway. I do not think that is correct (and it is definitely not necessary). The broker already has a keep-alive timer, the gateway does not need to track this. When the gateway detects that the keep alive has expired, it will drop the connection; the gateway should notice this and send DISCONNECT to the client (and consider things done!).

That is my reading of things anyway. It definitely works (without a timer on the gateway).

I will try out your branch stress the system a little and see if things recover better (looking at the commit, I expect they will).

I noticed Ian merged your pull request #29 (Yay!), so you probably want to re-fork (or pull) to keep up to date.

PK

On Sun, 2 Oct 2016 at 22:17 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx> wrote:
Hi Paul,
 According to the specification of MQTT broker never sends DISCONNECT message. 
but, according to the specification of MQTT-SN;

As with MQTT, the DISCONNECT message is sent by a client to indicate that it wants to close the connection.The gateway will acknowledge the receipt of that message by returning a DISCONNECT to the client. A server or gateway may also sends a DISCONNECT to a client, e.g. in case a gateway, due to an error, cannot map a received message to a client.  

so, I think  it's not a problem to send DISCONNECT from the gateway.

1) Gateway send DISCONNECT message to a client and broker when the client doesn't send any message within  the keep alive time.
2) Gateway send DISCONNECT message to a client when the gateway can not send message to the broker. (Gateway requires the client to send CONNECT to establish a connection between the broker.)

try my latest version (0.8.0) in my rep.


Tomy Technology

Tomoaki  YAMAGUCHI

2016-10-03 2:44 GMT+09:00 Paul Kierstead <paulkierstead@xxxxxxxxx>:
So, I tweaked TLS_client_method to be TLSv1_2_client_method and it compiles fine on the PI (but I presume this limits it to TLS1.2, which is fine by me...) and it #29 is working quite well on the PI. My previous complaints are all nicely addressed :)

Here is one thing that is sort of I think is only hinted at by the standard, which I implemented in previous gateway, but seems "open". Let say I power-cycle/etc the gateway. Now, the client keeps on going ... and sends a publish. The gateway ignores the client: "Not an active client". It would be really useful if the gateway sent back a DISCONNECT so that the client could immediately re-establish the connection.  Otherwise, a client sending QoS 0 messages doesn't know it is no longer connected and all the messages go to /dev/null. I think this is an oversight in the standard (or I've missed it.... I might have even known when I implemented  a gateway, but that was quite a while ago). Without it, QoS 0 is almost useless.

PK


On Sat, 1 Oct 2016 at 22:56 Paul Kierstead <paulkierstead@xxxxxxxxx> wrote:
Ah, well, might as answer my own question. Appears to be in OpenSSL v1.1, but ubuntu is at 1.0.2. Looks like it will have to be built from source ... I'll be betting that will take overnight on the pi :)

On Sat, 1 Oct 2016 at 22:47 Paul Kierstead <paulkierstead@xxxxxxxxx> wrote:
In #29 I'm getting

MQTTSNGateway/src/linux/Network.cpp: In member function ‘bool Network::connect(const char*, const char*, const char*, const char*, const char*, const char*)’:

MQTTSNGateway/src/linux/Network.cpp:299:40: error: ‘TLS_client_method’ was not declared in this scope

   _ctx = SSL_CTX_new(TLS_client_method());


This first appear in the "Update: indivisual client assigns TLS connection by clients.conf file." commit (2537dd76dd6a91d08162e925834f5d4af1626b91). Looking at https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_new.html, it does appear there, but my ubuntu vm nor my pi could find it. I am using libssl-dev. What is the required version of OpenSSL (ok, I'm lazy here, I probably could poke around, but just in case someone else runs into it, I though I would ask)

PK


On Sat, 1 Oct 2016 at 01:35 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx> wrote:
Hi All,

I found the serious bag of Que template. Que template can not queue elements, except only one.
This bug is already fixed and pull request #29 includes this fix. I hope this request will be merged soon.

Tomy Technology

Tomoaki  YAMAGUCHI
2016-09-25 23:15 GMT+09:00 Paul Kierstead <paulkierstead@xxxxxxxxx>:
On Sun, 25 Sep 2016 at 09:50 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx> wrote:
Hi Paul,

Thank you for your suggestions.

1.

> I'm not sure about its purpose,
const char* getDescription(void) { return "XBEE"; } has been changed.

Purpose is to show sensor network parameters defined by gateway.conf as follows:


Ah, I see its in your fork, but not in the gateway branch yet (my github terminology may not be right here). I think I'll try out your fork then, it seems to have some nice improvements.


you don't need to change Makefile to build GW for XBee.
SENSORNET is over writen by a command line parameter.

Input command as follows:
      $ make SENSORNET=xbee



Wow, I've used make for how many years and I didn't know command line assignments overrode explicit makefile assignments. You learn something new everyday!
 
3.
I disagree changing to the software selectable GW.
No one knows how many sensor network devices should be covered.

Sure, everyone who uses the supplied code knows: There are two. Of course people can write their own, but 99% of people will use it "out of the box". I'm not saying the ability to add ones at compile time should be eliminated, but what will happen is likely this: If this gateway has some success, people will want to have pre-built binaries for the supported networks (currently XBee and UDP). So, someone will make an Ubuntu package (or whatever) and just build one executable for each type of network. If more network types are added to the base, there will be more executables. This has the additional clunkiness that if the a new network type is added to the codebase, the package building stuff has to be updated instead of just rebuilt. This will also lead to confusion, as they all can be defined in the gateway.conf. Eventually, people will want one executable and be able to select which network type (or even types) in the conf file. Of course, one could easily have a make variable which defines which networks are in the executable for those who want to build their own. 

However, in any case, it only matters if the gateway gets some usage, which would be nice! 

PK


_______________________________________________
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

_______________________________________________
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