Code Monkey home page Code Monkey logo

paho.mqtt.javascript's Introduction

Eclipse Paho JavaScript client

Build Status

The Paho JavaScript Client is an MQTT browser-based client library written in Javascript that uses WebSockets to connect to an MQTT Broker.

Project description:

The Paho project has been created to provide reliable open-source implementations of open and standard messaging protocols aimed at new, existing, and emerging applications for Machine-to-Machine (M2M) and Internet of Things (IoT). Paho reflects the inherent physical and cost constraints of device connectivity. Its objectives include effective levels of decoupling between devices and applications, designed to keep markets open and encourage the rapid growth of scalable Web and Enterprise middleware and applications.

Links

Using the Paho Javascript Client

Downloading

A zip file containing the full and a minified version the Javascript client can be downloaded from the Paho downloads page

Alternatively the Javascript client can be downloaded directly from the projects git repository: https://raw.githubusercontent.com/eclipse/paho.mqtt.javascript/master/src/paho-mqtt.js.

Please do not link directly to this url from your application.

Building from source

There are two active branches on the Paho Java git repository, master which is used to produce stable releases, and develop where active development is carried out. By default cloning the git repository will download the master branch, to build from develop make sure you switch to the remote branch: git checkout -b develop remotes/origin/develop

The project contains a maven based build that produces a minified version of the client, runs unit tests and generates it's documentation.

To run the build:

$ mvn

The output of the build is copied to the target directory.

Tests

The client uses the Jasmine test framework. The tests for the client are in:

src/tests

To run the tests with maven, use the following command:

$ mvn test

The parameters passed in should be modified to match the broker instance being tested against.

Documentation

Reference documentation is online at: http://www.eclipse.org/paho/files/jsdoc/index.html

Compatibility

The client should work in any browser fully supporting WebSockets, http://caniuse.com/websockets lists browser compatibility.

Getting Started

The included code below is a very basic sample that connects to a server using WebSockets and subscribes to the topic World, once subscribed, it then publishes the message Hello to that topic. Any messages that come into the subscribed topic will be printed to the Javascript console.

This requires the use of a broker that supports WebSockets natively, or the use of a gateway that can forward between WebSockets and TCP.

// Create a client instance
var client = new Paho.MQTT.Client(location.hostname, Number(location.port), "clientId");

// set callback handlers
client.onConnectionLost = onConnectionLost;
client.onMessageArrived = onMessageArrived;

// connect the client
client.connect({onSuccess:onConnect});


// called when the client connects
function onConnect() {
  // Once a connection has been made, make a subscription and send a message.
  console.log("onConnect");
  client.subscribe("World");
  message = new Paho.MQTT.Message("Hello");
  message.destinationName = "World";
  client.send(message);
}

// called when the client loses its connection
function onConnectionLost(responseObject) {
  if (responseObject.errorCode !== 0) {
    console.log("onConnectionLost:"+responseObject.errorMessage);
  }
}

// called when a message arrives
function onMessageArrived(message) {
  console.log("onMessageArrived:"+message.payloadString);
}

Breaking Changes

Previously the Client's Namepsace was Paho.MQTT, as of version 1.1.0 (develop branch) this has now been simplified to Paho. You should be able to simply do a find and replace in your code to resolve this, for example all instances of Paho.MQTT.Client will now be Paho.Client and Paho.MQTT.Message will be Paho.Message.

paho.mqtt.javascript's People

Contributors

andypiper avatar greenstone7 avatar icraggs avatar jpwsutton avatar knolleary avatar manueliglesias avatar miketran78727 avatar nicorikken avatar svarogg avatar tmulkern avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

paho.mqtt.javascript's Issues

API uses non-standard names like "send" and "destinationName"

migrated from Bugzilla #440771
status UNCONFIRMED severity normal in component MQTT-JS for 1.1
Reported in version 1.0 on platform All
Assigned to: Andrew Banks

On 2014-07-30 09:09:39 -0400, Karl Palsson wrote:

Every other MQTT library uses "publish" to publish messages, and "topic" for the topic. It's rather odd to find "send" and "destinationName" used in this library instead.

Seeing as any semblance of backwards compatibility was already broken, it would be a major improvement to make this more in line with every other user and library.

On 2014-08-11 04:01:07 -0400, Ian Craggs wrote:

Karl,

"Seeing as any semblance of backwards compatibility was already broken". What do you mean by this? Backwards compatibility with what?

The async C API uses sendMessage as the operation to publish.

On 2014-08-11 05:55:37 -0400, Karl Palsson wrote:

Backwards compatibility with prior releases of the javascript code. compatibility with the C api is not "backwards" compatibility, it's sideways at best, and if I was using the C api you mention, would have filed the same bug there :)

On 2014-08-11 06:10:45 -0400, Ian Craggs wrote:

(In reply to Karl Palsson from comment # 2)

Backwards compatibility with prior releases of the javascript code.
compatibility with the C api is not "backwards" compatibility, it's sideways
at best, and if I was using the C api you mention, would have filed the same
bug there :)

I just mentioned the C API as an example of an alternative function name, not as a base for backward compatibility.

I was not aware that this Javascript API had changed in an incompatible way. I thought that this API has always used "send" and "destinationName". I just checked the initial commit of the code, which appears to verify that.

On 2014-08-11 08:06:33 -0400, Karl Palsson wrote:

Yes, the method names stayed, but the package changed. You were required to modify your code if you moved up to v1.0, hence, backwards compatibility was lost, so let's take advantage of that.

Messaging -> Paho.MQTT
and there were some parameters to functions changed. I don't have them all to hand right now.

On 2014-08-13 05:40:11 -0400, Ian Craggs wrote:

Unfortunately, yes the package name did change. I felt we had to bite the bullet on that one - it had been dithered about for long enough, and we were going for version 1.0.

I'm not aware of function parameters changing, though. So I feel your statement "Seeing as any semblance of backwards compatibility was already broken" is an exaggeration.

As we have released 1.0 now, we can't just throw in more incompatible changes without changing the version number. We could however add synonyms for the current APIs, at the expense of code complexity and size.

The reason why the author used send and destinationName rather than publish and topic, is as you might have guessed, because he was thinking about the time when these APIs might be used for queues as well as topics. I can understand both points of view.

No one else has been too exercised about these "non-standard" names though (or at least has spoken up) - they are just names.

On 2015-09-08 11:28:58 -0400, Jan-Piet Mens wrote:

The Paho Python package uses "topic" and "publish". The Eclipse Mosquitto library also. When is the Paho JavaScript library going to add compatible names? I'm asking again, because this just bit somebody who had to read through the source of mqttws31.js to find out what to do.

Published docs reference Messaging.Client not Paho.MQTT.Client

migrated from Bugzilla #439804
status RESOLVED severity normal in component MQTT-JS for 1.1
Reported in version v0.5 on platform PC
Assigned to: Andrew Banks

On 2014-07-17 10:04:30 -0400, Al Stockdill-Mander wrote:

The published generated jsdoc refer to Messaging.Client rather than the new Paho.MQTT.Client

On 2014-07-22 10:59:06 -0400, Al Stockdill-Mander wrote:

New docs were generated and uploaded to the Paho website

JavaScript offline buffering

migrated from Bugzilla #481413
status ASSIGNED severity normal in component MQTT-JS for 1.2
Reported in version 1.2 on platform PC
Assigned to: Mike Tran

On 2015-11-04 09:32:01 -0500, Mike Tran wrote:

Here is a couple of use cases (copied from email sent by Dennis Wulff)

  1.  Mobile App publishes messages to back end
    
    App Connects
    App attempts to publish message (wants guaranteed delivery) and is no longer connected
    App retries without success
    Now what to do with this message
    Save it in JS object?
    Save in indexedDB?
    Drop and notify user?

Currently to guarantee delivery some custom coding is required to save and manage the message until reconnected. It would be ideal if MQTT lib handled storage and resend logic.

  1.  App is deployed to field on laptop roaming in and out of wifi
    
    Same as above

On 2015-11-04 10:09:46 -0500, Ian Craggs wrote:

Assigning to Mike.

Use cases:

  1. Remember we are talking about browser apps only for this JavaScript client. The client could give similar options to the Java or C clients for persistence - allow the app to choose what type of persistence to use: memory, disk, or an app supplied plugin. Disk or similar is only needed if the app can terminate and then restart with those messages ready to send.

Given that the current JavaScript application does not persist to anything other than memory, I suggest we do the same for the "offline buffering", for now. That's what many client libraries do anyway.

  1. This means the wifi connection is dropping and re-establishing. While the app continues running, you don't need to store the messages in anything other than memory like the Paho Python client.

On 2015-11-04 10:28:55 -0500, Mike Tran wrote:

I think for JavaScript we can have a callback to allow the application to persist offline messages via HTML5 webStorage support https://html.spec.whatwg.org/multipage/webstorage.html

On 2015-11-04 10:34:05 -0500, Ian Craggs wrote:

Yes, I was thinking that for HTML5, then using webstorage would be an option. A callback would be an ideal solution.

We would also have to add a callback for the persistence of inflight message state, which doesn't exist at the moment.

Client throws exception on connect error

migrated from Bugzilla #408078
status RESOLVED severity normal in component MQTT-JS for ---
Reported in version v0.5 on platform All
Assigned to: Andrew Banks

On 2013-05-15 01:03:29 -0400, Simon Racliffe wrote:

If the MQTT-JS client can't connect for any reason (bad path given, server down etc) the client throws an exception as it tries to disconnect an unconnected session.

The line it throws the exception on is:
delete this.socket;
and here is the exception:
WebSocket connection to 'ws://h2o.proatomic.com.au/mosquitto1' failed: WebSocket is closed before the connection is established. mqttws31.js:1307

Regards
Simon Ratcliffe

On 2013-05-15 07:19:55 -0400, Andy Piper wrote:

Thanks Simon. cc'ing Nick as QA for verification as I know he has experience as a user of the JS client too.

On 2013-05-15 17:03:20 -0400, Nicholas O'Leary wrote:

I've tried a couple things, but not been able to cause the symptom you describe.

Can you provide a minimal test case?

Here's what I tried:

<script src="mqttws31.js"></script> <script> var client = new Messaging.Client("NotARealHost",9999, "clientId"); client.onConnectionLost = function(err) { console.log(err);}; client.connect({ onSuccess:function() { console.log("connected");}, onFailure:function(err) { console.log(err);} }); </script>

On 2013-05-15 21:48:35 -0400, Simon Racliffe wrote:

Nicholas,

I tried your test case except I changed the host and port to a valid webserver inside my network that doesn't support websockets.

So initially I get a 404 error at line 912:

this.socket = new WebSocket(wsurl, 'mqttv3.1');

this should probably be wrapped with a try/catch. After this I get the exception I mentioned before. I should mention I am using the latest version of Chrome as my browser. I have tested with the latest version of IE10 and FF and give differing results, but all return the initial script error for the 404.

Hope this helps.

Simon

On 2013-05-15 21:55:31 -0400, Simon Racliffe wrote:

Just a little more info. Using your test case, I got script errors (the 404) in both IE10 and FF, but not in Chrome.

On 2013-05-16 04:25:18 -0400, Nicholas O'Leary wrote:

Thanks Simon - I had only tried in Chrome.

In Chrome:

  • If the server/port doesn't exist
    LOG: Starting... 127.0.0.1:5
    LOG: Object {invocationContext: undefined, errorCode: 8, errorMessage: "AMQJS0008I Socket closed."}
  • If the server/port exists, but not a websocket handler
    LOG: Starting...
    ERROR: WebSocket connection to 'ws://127.0.0.1/mqtt' failed: Unexpected response code: 404
    ERROR: WebSocket connection to 'ws://127.0.0.1/mqtt' failed: WebSocket is closed before the connection is established.
    LOG: Object {invocationContext: undefined, errorCode: 7, errorMessage: "AMQJS0007E Socket error:undefined."}

In FF

  • If the server/port doesn't exist, or it does exist but not a websocket handler:
    LOG: Starting...
    ERROR: Firefox can't establish a connection to the server at ws://127.0.0.1oih/mqtt
    LOG: ({invocationContext:(void 0), errorCode:7, errorMessage:"AMQJS0007E Socket error:undefined."})

I don't have ready access to IE to test against.

Issue # 1: none of the 'ERROR' lines above should be exposed to the console - they need to be caught internally.

Issue # 2: in each of these cases, the subsequent errorMessage object passed back to the onFailure callback has 'Socket error:undefined'.

On 2013-05-16 04:55:00 -0400, Simon Racliffe wrote:

Happy to run IE10 test cases for you.

In IE10:

I had to change the onFailure function from:

onFailure:function(err) { console.log(err);}

to

onFailure:function(err) { console.log(err.invocationContext+' '+err.errorCode+':'+err.errorMessage);}

The original function in IE10 just outputs the following to the console:
[object Object]

  • If the server/port doesn't exist
    SCRIPT12007: WebSocket Error: Network Error 12007, The server name or address could not be resolved
    undefined 7:AMQJS0007E Socket error:undefined.
    • If the server exists, but port is not listening
      SCRIPT12029: WebSocket Error: Network Error 12029, A connection with the server could not be established
      undefined 7:AMQJS0007E Socket error:undefined.
    • If the server/port exists, but not a websocket handler
      SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 404, Not Found
      undefined 7:AMQJS0007E Socket error:undefined.

On 2013-05-16 10:33:48 -0400, Andrew Banks wrote:

Looks like the WebSocket was being closed before the negotiation was finished.
The documentation is not clear whether this is allowed, but I've put a guard round it anyway.

Can you give this a spin, it wont fix the negotiation bug but at least the client wont complain.

On 2013-05-16 11:30:18 -0400, Nicholas O'Leary wrote:

I can confirm the commited fix removes the "WebSocket is closed before the connection is established" error message. But it doesn't touch the related issues identified in this bug.

Andy: as you've closed this bug, would you like me to raise separate issues for those other items?

Specifically:

Issue # 1: none of the 'ERROR' lines above should be exposed to the console - they need to be caught internally.

Issue # 2: in each of these cases, the subsequent errorMessage object passed back to the onFailure callback has 'Socket error:undefined'.

On 2013-05-17 06:37:18 -0400, Andy Piper wrote:

Nick, let's split those out as separate issues so we can track them separately. Thanks.

On 2013-05-17 06:44:57 -0400, Simon Racliffe wrote:

I don't think you need to complicate this that much.

As I mentioned in comment # 3 probably the best solution is a try/catch around the opening of the websocket. This should solve all the differing results that occur with the various browsers and reasons for the fault.

On 2013-05-17 08:04:40 -0400, Nicholas O'Leary wrote:

Simon is right here - the additional items are all related and could have been easily swept up together with a single fix.

Without feedback from Andy B, I'll raise these items separately.

The client in the develop branch generates a different key for the persistence store if uri's are used

migrated from Bugzilla #421267
status CLOSED severity normal in component MQTT-JS for ---
Reported in version v0.5 on platform PC
Assigned to: Andrew Banks

On 2013-11-07 11:22:04 -0500, Al Stockdill-Mander wrote:

If I have an application using the current JS client where the server is identified by host and port with messages held in the client persistence store and I change the application to use the develop branch client and identify the same server by uri instead the client would not see the messages in the persistence store.

On 2013-11-12 18:58:22 -0500, Nicholas O'Leary wrote:

Thought I had accommodated that scenario
Will take a closer look.

On 2014-06-06 05:38:19 -0400, Al Stockdill-Mander wrote:

Not an issue

Change the namespace for the Javascript MQTT client

migrated from Bugzilla #407372
status RESOLVED severity major in component MQTT-JS for 1.0
Reported in version v0.5 on platform All
Assigned to: Andrew Banks

On 2013-05-07 05:19:19 -0400, Nicholas O'Leary wrote:

The javascript client creates a global Messaging namespace with two objects, Client and Messaging.

Following the discussion about the python client's namespace, the javascript client should follow suit and use something more appropriate.

For example:

paho.Client
paho.Messaging

On 2013-05-07 10:28:45 -0400, Andy Piper wrote:

Reassigning to MQTT-JS component

On 2014-06-06 05:45:45 -0400, Al Stockdill-Mander wrote:

The JS client now checks for the existence of a global Paho Object, creates it if it does not exist, then within that creates an MQTT object, which contains the Client and Message objects.

Browser compatibility list

migrated from Bugzilla #409016
status RESOLVED severity normal in component MQTT-JS for ---
Reported in version v0.5 on platform PC
Assigned to: Andrew Banks

On 2013-05-24 12:31:33 -0400, Matteo Collina wrote:

When the WebSocket MQTT tunnel is released, the release note should include which browsers are supported.

As an example of such a compatibility list:
https://ci.testling.com

On 2014-07-03 07:03:38 -0400, Al Stockdill-Mander wrote:

README.md includes a link to browser compatibility list based on stated WebSockets support

Create basic utility for Javascript client

migrated from Bugzilla #470085
status RESOLVED severity normal in component MQTT-JS for 1.2
Reported in version 1.1 on platform All
Assigned to: James Sutton

On 2015-06-12 10:48:38 -0400, James Sutton wrote:

It would be useful to have a web page based utility that can be used to try out the features of the Javascript client. It should be able to load without having to manually pull in any dependencies and preferably leverage all parts of the API.

On 2015-06-12 11:01:10 -0400, Benjamin Cabรƒยฉ wrote:

+1!
And we should host an instance of this web page on eclipse.org/paho so as people can play with the iot.eclipse.org broker.
FWIW I believe there are several existing projects that implement similar functionality so it might be interesting to encourage the people behind those to contribute them.
See:

On 2015-06-12 11:49:51 -0400, Ian Craggs wrote:

Actually I asked James to write one this week, so the first pass is done, and in the repos.

What port on iot.eclipse.org allows websockets?

On 2015-06-12 12:11:37 -0400, Benjamin Cabรƒยฉ wrote:

(In reply to Ian Craggs from comment # 2)

Actually I asked James to write one this week, so the first pass is done,
and in the repos.

That's the problem with opening tickets afterwards i guess :)

What port on iot.eclipse.org allows websockets?

var client = new Paho.MQTT.Client("ws://iot.eclipse.org/ws", "id-" + new Date().getTime());

On 2015-06-12 14:43:14 -0400, Ian Craggs wrote:

It didn't take James long to write at all, and this way I could ask for exactly what I wanted :-)

I've added it to the website at:

https://www.eclipse.org/paho/clients/js/utility/index.html

However the connect doesn't work at the moment to the sandbox server (at iot.eclipse.org:80) because the page is connected via https, and the connect is not using TLS. I attempted to use TLS but that didn't seem to work - I don't know if that port accepts secure websocket connections as well.

On 2015-06-15 03:31:38 -0400, James Sutton wrote:

I've remembered that it's not exposing a field to enter the path either e.g. /ws. I'll see if I can remedy the TLS issue and add a path field.

On 2015-06-15 05:45:08 -0400, Ian Craggs wrote:

We need the ability to set any or all of the connect options, such as clean session, etc.

On 2015-06-15 05:45:56 -0400, Ian Craggs wrote:

Assigning to James.

On 2015-07-28 09:01:39 -0400, Eclipse Genie wrote:

New Gerrit change created: https://git.eclipse.org/r/52705

On 2015-07-28 09:45:01 -0400, Eclipse Genie wrote:

New Gerrit change created: https://git.eclipse.org/r/52714

On 2015-07-28 09:49:04 -0400, Eclipse Genie wrote:

Gerrit change https://git.eclipse.org/r/52714 was merged to [develop].
Commit: http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.javascript.git/commit/?id=SHA: a115bee

On 2015-10-07 10:09:13 -0400, James Sutton wrote:

Changes made and is available here: http://www.eclipse.org/paho/clients/js/utility/index.html

On 2015-10-07 10:14:04 -0400, Benjamin Cabรƒยฉ wrote:

It looks like since eclipse.org/paho is served over HTTPS, only websockets over TLS are permitted by the browser, correct? And I don't think the iot.eclipse.org sandbox has been setup for websockets over TLS (yet) :-/

On 2015-10-07 10:22:27 -0400, James Sutton wrote:

That's odd, when I load the page it comes in as plain http and the default settings work. But yes, I've not seen any way to connect to iot.eclipse.org over using TLS either.

On 2015-10-07 10:42:33 -0400, Benjamin Cabรƒยฉ wrote:

(In reply to James Sutton from comment # 13)

That's odd, when I load the page it comes in as plain http and the default
settings work. But yes, I've not seen any way to connect to iot.eclipse.org
over using TLS either.

Interesting รข๏ฟฝ๏ฟฝร‚ย I think that if you're logged in on eclipse.org with your committer/contributor credentials, you will get redirected to https://... even if you landed on http:// initially.
At least that's what happens to me since I can stick to http://eclipse.org/paho if I use an "anonymous browser" window.

Some function are using global variable, which can interfere some other modules.

migrated from Bugzilla #436190
status RESOLVED severity normal in component MQTT-JS for 0.9
Reported in version unspecified on platform Macintosh
Assigned to: Tang Zi Han

On 2014-05-29 12:00:12 -0400, Ryosuke Tajima wrote:

Hi,

Some function are using global variables in for loop iterator.
For instance, WireMessage() uses variable 'name' in for loop, which is global variable.

var WireMessage = function (type, options) {
this.type = type;
for(name in options) {
if (options.hasOwnProperty(name)) {
this[name] = options[name];
}
}
};

I believe it should be:

var WireMessage = function (type, options) {
this.type = type;
for(var name in options) {
if (options.hasOwnProperty(name)) {
this[name] = options[name];
}
}
};

It can interfere some other module. I have noticed this when I use mqtt31.js with google hangout APIs.
After making a MQTT connection, functions of gapi.hangout.data APIs are corrupted.
After I changed it to a local variable, it works fine.

I'm a newbie of MQTT and javascript. Please check I don't tell wrong.

Thanks,

On 2014-06-06 05:28:52 -0400, Al Stockdill-Mander wrote:

Thanks for reporting this, it does appear that some variables are not scoped correctly.

On 2014-07-22 10:53:19 -0400, Karl Palsson wrote:

Another place that does this is about line 200, formatting error messages

var format = function(error, substitutions) {
var text = error.text;
if (substitutions) {
for (var i=0; i<substitutions.length; i++) {
field = "{"+i+"}";
start = text.indexOf(field);
if(start > 0) {
var part1 = text.substring(0,start);
var part2 = text.substring(start+field.length);
text = part1+substitutions[i]+part2;
}
}
}
return text;
};

both "field" and "start" should be made locals

On 2014-08-31 22:40:07 -0400, Tang Zi Han wrote:

Fixed in develop branch include the above two parts and some other points which are not scoped correctly.

Connect Options Validation does not validate all possible fields

migrated from Bugzilla #476039
status RESOLVED severity normal in component MQTT-JS for 1.2
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

On 2015-08-27 08:49:49 -0400, James Sutton wrote:

First raised on the forum: https://www.eclipse.org/forums/index.php/t/1069724/

The step during connection which validates the connectOptions object does not validate all of its potential attributes. Furthermore during the connect sequence, these unknown attributes are added to the connectOptions object:

mqttVersionExlpicit (boolean)
uris (object)

This means that if a connection was dropped and needed to be re-opened, the connectOptions object would then fail validation as it would now contain the above attributes.

The fix will be to simply add the two attributes into the validation object.

On 2015-08-27 08:56:43 -0400, Eclipse Genie wrote:

New Gerrit change created: https://git.eclipse.org/r/54695

On 2015-08-27 10:12:16 -0400, Eclipse Genie wrote:

Gerrit change https://git.eclipse.org/r/54695 was merged to [develop].
Commit: http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.javascript.git/commit/?id=SHA: f0cd0c6

On 2015-09-01 11:28:00 -0400, James Sutton wrote:

Added mqttVersionExlpicit and uris as valid fields.

Change connect parameter from host,port to url

migrated from Bugzilla #407605
status RESOLVED severity enhancement in component MQTT-JS for ---
Reported in version v0.5 on platform All
Assigned to: Nicholas O'Leary

Original attachment names and IDs:

On 2013-05-08 19:47:40 -0400, Simon Racliffe wrote:

Created attachment 230690
Patch to implement url's as parameters

Currently the mqtt-js client uses a host,port parameter to specify the websocket server and you have to specify useSSL if you want to use SSL. Also the path on the server is hardcoded in the code.

A better way to specify this is to simply to pass in a url in the form:
{ws:|wss:}//hostname[:port]/path

The attached patch changes the implementation to do it this way.

Regards
Simon Ratcliffe

On 2013-05-10 11:56:23 -0400, Andy Piper wrote:

Simon, thanks very much for your patch! We will take a look.

In order for us to accept your contribution to the project, can you please confirm:

  1. That you authored 100% of the content youรข๏ฟฝ๏ฟฝre contributing?
  2. That you have the rights to contribute this content to Eclipse?
  3. That you're willing to contribute the content under the projectรข๏ฟฝ๏ฟฝs EPL and EDL license(s)

In addition, since this patch is (just!) greater than 250 lines, we will need to pass it through the IP review process. CQ # 7253 opened for this review.

On 2013-05-10 11:58:05 -0400, Andy Piper wrote:

Assigning to Andrew.

On 2013-05-10 19:56:29 -0400, Simon Racliffe wrote:

Andy, no problem. I 100% authored the contribution and have the rights to contribute it.
I am willing to contribute this under the projects licence's.

Regards
Simon Ratcliffe
ProAtomic Software Development

On 2013-05-17 07:45:35 -0400, Simon Racliffe wrote:

Hi guys,

Any progress on this one?
I think it is important to address this as it is a change to the API and therefore a good idea to say yay or nay before many people start to use the library.

I know that it got tagged as needing to be reviewed due to the size, but most of the patch was just the references to the surrounding lines. I think a philosophical decision/discussion on the API change is important.

Regards
Simon Ratcliffe

On 2013-05-17 08:03:10 -0400, Nicholas O'Leary wrote:

Hi Simon,

Philosophically, I'm all for allowing the url to be passed in rather than just the hostname/port.

A related part of this is that the client assumes the path to connect to is always "/mqtt". This change would allow that to be anything - again, in my view a good thing.

I haven't looked at your specific implementation, but I don't see why this needs to be an API change - it could be added as an alternative acceptable parameter to the existing constructor.

Ultimately this needs input from Andy Banks.

On 2013-05-17 08:15:53 -0400, Simon Racliffe wrote:

I agree it doesn't have to be an API change, but the current implementation is restrictive and cumbersome. Maintaining multiple alternative API's when not providing real functionality is not a good idea in my opinion. Also the library does no checking of the parameters and just concatenates them and passes them on, so there is no benefit to passing them separately.

Once the other issue I have reported is addressed (bug 408078) any error in the url will be handled correctly.

On 2013-05-18 06:22:46 -0400, Andrew Banks wrote:

I chose to use host,port and the useSSL flag rather than requiring the user to provide a URL because its less error prone and requires less knowledge of the correct URL format. Whether one needs the extra flexibility of providing a URL vs the constraints of generating only correct URLs is moot, what would be undesirable is to have two ways of doing this.

There is an open issue for the Oasis Technical Committee to resolve on the
path name and how WebSockets fits with MQTT in general, so I don't want to preempt the outcome of that now. See

https://tools.oasis-open.org/issues/browse/MQTT-1

On 2013-05-24 08:06:57 -0400, Simon Racliffe wrote:

Hi Andrew,

I doubt that anyone that wants to use mqtt-js is not going to understand how to construct a URL (scary, but most 5yo's know what a URL is). I didn't see anything of relevance in the topic you posted.

If you are going to parameterise the URL it needs to contain all options.

Just my thoughts.

On 2013-05-24 08:23:14 -0400, Andy Piper wrote:

CQ 7253 was approved, but the header needs amending to include Simon if the patch is applied.

On 2013-07-22 09:31:43 -0400, Al Stockdill-Mander wrote:

Created attachment 233669
Allow the use of URIs and host/port

This patch allows the JS client to be used by providing both host/port or with a URI.
Something to be aware of; if you were using it in host/port and have data in the local storage for the client, it would no longer be visible to the client if you change to using a URI.

On 2013-09-27 16:27:34 -0400, Nicholas O'Leary wrote:

Fix pushed to the develop branch.

The fix is completely backward compatible with the existing api.

The constructor signature is now:
Client(host,[port,[path]],clientId)
where:
host: is the hostname/ip address, or the fully qualified ws uri
port: if host is not a uri, this is the port to connect to
path: if host is not a uri, this is the path portion, defaults to /mqtt

This means all of the following are valid:

Client("m2m.eclipse.org",80,"myclient")
Client("m2m.eclipse.org",80,"/ws","myclient")
Client("ws://m2m.eclipse.org:80/ws","myclient")

The other way the client supports supplying server details is via the ConnectOptions.hosts array passed to the connect function. This can now be an array of fully qualified ws uris. If they are determined to be uris, the .ports array is ignored. For better or worse, as before, if .hosts/.ports is used, you must still provide host details in the constructor to provide a key into local storage persistence.

On 2013-09-30 04:19:41 -0400, Andrew Banks wrote:

Nick, please be aware that there are data migration issues with this fix which may
cause data loss. If you flip between the host+port version of the constructor and
the url version, or if you use differing forms of the url to reach the same server
then different sets of stored data will be used for recovery, causing duplicate or
lost messages.

On 2013-09-30 05:59:48 -0400, Nicholas O'Leary wrote:

Andy,

yes, if a user modifies how they specify the broker, it does risk them losing state.

But that scenario already existed with the client; if a broker had multiple CNAMES and a user flipped between them, exactly the same would happen. So this fix does not introduce data loss scenarios that weren't already there.

In reality, application isn't going to suddenly flip from one method to the other.

Given it could already happen, I assume the documentation is clear on this point - if not, it should be updated.

On 2013-09-30 06:01:15 -0400, Nicholas O'Leary wrote:

Also, the fix ensures that an existing application that upgraded, with no changes to the application code, would still access the same local storage as before - so there is no data migration issue there.

publish/(send!) is too awkward to use, requiring Message object creation

migrated from Bugzilla #440770
status RESOLVED severity normal in component MQTT-JS for 1.1
Reported in version 1.0 on platform All
Assigned to: Tang Zi Han

On 2014-07-30 09:07:00 -0400, Karl Palsson wrote:

The "Message" object is quite useful in the received case, containing information about length, topic, dup flag, and helpers to get the payload in multiple formats.

For publishing however, it's an obstacle.

To send a message, you are required to make the following calls..

var m = new Paho.MQTT.Message("some payload");
m.destinationName = "bulky/code/is/better/right";
m.qos = 2;
m.retain = true;
mqclient.send(m);

There's no reason for this at publish time. The only options available at publish time are qos, retain flag, topic and payload. If we can't simply have a publish method that accepts all these parameters. (with only topic and payload being required) can we at least have a better constructor?

either
mqclient.send(topic, payload, qos=0, retain=false)
or
mqclient.send(new Paho.MQTT.Message("topic", "payload"))

I presume the second form wouldn't work, as the existing constructor puts the payload first, but really, anything would be an improvement. If we can't put hardcoded defaults on qos and retain flag, they could be client creation time options, if necessary.

On 2014-08-11 01:46:22 -0400, Tang Zi Han wrote:

It's better to add a new API,
such as
mqclient.publish(topic, publishOptions)
publishOptions = {
payload: "TEST",
qos : 0,
retain: false
}

In this way , it also solve the below problem.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=440771

On 2014-08-31 22:27:44 -0400, Tang Zi Han wrote:

Fixed by extending the send api to support parameters of topic,payload,qos,retained and keep backward compatiblity.
Merged in develop branch.

this.send = function (topic,payload,qos,retained) {
var message ;

      if(arguments.length == 0){
          throw new Error("Invalid argument."+"length");

      }else if(arguments.length == 1) {

          if (!(topic instanceof Message) && (typeof topic !== "string"))
              throw new Error("Invalid argument:"+ typeof topic);

          message = topic;
          if (typeof message.destinationName === "undefined")
              throw new Error(format(ERROR.INVALID_ARGUMENT,[message.destinationName,"Message.destinationName"]));
          client.send(message); 

      }else {
          //parameter checking in Message object 
          message = new Message(payload);
          message.destinationName = topic;
          if(arguments.length >= 3)
              message.qos = qos;
          if(arguments.length >= 4)
              message.retained = retained;
          client.send(message); 
      }
  };

The name of the file doesn't properly represent its function

migrated from Bugzilla #439909
status NEW severity normal in component MQTT-JS for 1.1
Reported in version v0.5 on platform PC
Assigned to: Tang Zi Han

On 2014-07-18 12:00:23 -0400, Al Stockdill-Mander wrote:

mqttws31.js was originally just an MQTT 3.1 implementation, but now supports both 3.1 and 3.1.1. While the file name may not have changed to allow easy drop in replacement of an updated copy of the library we broke backward compatibility with the 1.0.0 release moving from Messaging. to Paho.MQTT. for the namespace. Going forward perhaps the name of the file should be paho-mqtt.js

On 2014-07-18 13:47:24 -0400, Benjamin Cabรƒยฉ wrote:

(In reply to Al Stockdill-Mander from comment # 0)

Going forward perhaps the name of the file should be
paho-mqtt.js

+1

On 2014-07-21 04:24:29 -0400, Ian Craggs wrote:

(In reply to Al Stockdill-Mander from comment # 0)

mqttws31.js was originally just an MQTT 3.1 implementation, but now supports
both 3.1 and 3.1.1. While the file name may not have changed to allow easy
drop in replacement of an updated copy of the library we broke backward
compatibility with the 1.0.0 release moving from Messaging. to Paho.MQTT.
for the namespace. Going forward perhaps the name of the file should be
paho-mqtt.js

+1

On 2014-08-19 06:34:17 -0400, Ian Craggs wrote:

Are we going to get complaints of not being backward compatible if we make this change?

On 2014-08-20 18:17:11 -0400, Tang Zi Han wrote:

(In reply to Al Stockdill-Mander from comment # 0)

mqttws31.js was originally just an MQTT 3.1 implementation, but now supports
both 3.1 and 3.1.1. While the file name may not have changed to allow easy
drop in replacement of an updated copy of the library we broke backward
compatibility with the 1.0.0 release moving from Messaging. to Paho.MQTT.
for the namespace. Going forward perhaps the name of the file should be
paho-mqtt.js

+1

It's better to keep the file name and global namespace changed at the same step.
How about pahoMqtt3.1.1.js

subscribe only takes a single topic, yet returns an array

migrated from Bugzilla #440767
status UNCONFIRMED severity normal in component MQTT-JS for 1.1
Reported in version 1.0 on platform All
Assigned to: Tang Zi Han

On 2014-07-30 08:57:30 -0400, Karl Palsson wrote:

MQTT Spec allows sending multiple topics to subscribe in a single message, and replies with a list of granted QoS.

The current API only allows subscribing to a single topic, yet still returns an array, (with only one entry)

Ideally, both of these would work:

client.subscribe(topicA, qosA, {existing options blob (if we must) for callback definition})
which would invoke callbacks with just a single granted qos field, not an array,

and also...

client.subscribe([[topicA, qosA],[topicB,qosB],....], ...) which would return an array of qos's.

I don't actually personally even need a way to subscribe to multiple topics in one call, but the only time I would ever want an array of granted qos back is if I had actually subscribed to multiple topics.

On 2014-08-26 01:49:43 -0400, Tang Zi Han wrote:

Currently the subscribe API allows a single topic and return an array of grantedQos.
The first fix step is to return a single grantedQos to match one topic.

On 2014-09-08 05:57:23 -0400, Al Stockdill-Mander wrote:

Changing the return type in the callback is an API change, so not something I would be keen to see. Perhaps it would be better to allow subscriptions to multiple topics in a subscribe call.

On 2014-09-08 06:09:11 -0400, Karl Palsson wrote:

If the API is confusing and inconsistent, surely there must be a path to change it. Backwards compatible is only useful if the old way is good.

On 2015-01-08 02:10:31 -0500, Tang Zi Han wrote:

(In reply to Tang Zi Han from comment # 1)

Currently the subscribe API allows a single topic and return an array of
grantedQos.
The first fix step is to return a single grantedQos to match one topic.
Commit change to develop branch: https://git.eclipse.org/r/#/c/39165/

Currently the subscribe api :
this.subscribe = function (filter, subscribeOptions)
the qos is a number and include in subscribeOptions.
It is not very clear to change the api to
subscribe ([topic1,topic2],{qos:[1,1],onsuccess:function(){},onfailure:function(){}....})

In current version, it will be a big api change if changing the api to
client.subscribe([[topicA, qosA],[topicB,qosB],....], callback).

It's better to add a new api to subscribe multiple topic in the following version.

Javascript Client Download

migrated from Bugzilla #420221
status CLOSED severity normal in component MQTT-JS for ---
Reported in version v0.5 on platform All
Assigned to: Andrew Banks

On 2013-10-23 16:56:25 -0400, Obermaier Dominik wrote:

Currently there is no official download of the Paha Javascript client on the main page, only a link to the Git repository.

To enable people to download a "release" version of the Javascript client, a download link should be added

On 2013-11-12 18:53:30 -0500, Nicholas O'Leary wrote:

This issue, as well as the separate ones you've raised on similar lines (# 420222 # 420223) are all on the todo list for once we have an automated, regular build of the js client up and running.

Al was looking at that although I know hes just gone away for a couple weeks.

Will see if I can find out where he had gotten to.

On 2014-02-01 11:27:49 -0500, Nicholas O'Leary wrote:

Tidying up the backlog - there is a catch-all bug for doc/download/website improvements - # 423940

*** This bug has been marked as a duplicate of bug 423940 ***

Paho Javascript Documentation

migrated from Bugzilla #420223
status CLOSED severity normal in component MQTT-JS for ---
Reported in version v0.5 on platform All
Assigned to: Andrew Banks

On 2013-10-23 17:01:28 -0400, Obermaier Dominik wrote:

Since Javascript isn't typed statically, it is critical for every library that there is a good documentation for the API. Paho has a very good documentation as comments (even with code examples!) in the code itself.

It should be considered to at least extract the comment documentation in a real documentation on the website. At least all important functions + parameters should be shown.

On 2014-02-01 11:30:36 -0500, Nicholas O'Leary wrote:

Tidying up the backlog - there is a catch-all bug for doc/download/website improvements - # 423940

*** This bug has been marked as a duplicate of bug 423940 ***

errors in user code are swallowed, along with stack traces

migrated from Bugzilla #440126
status RESOLVED severity normal in component MQTT-JS for 1.1
Reported in version 1.0 on platform PC
Assigned to: Tang Zi Han

Original attachment names and IDs:

On 2014-07-22 10:56:21 -0400, Karl Palsson wrote:

If a user supplied onMessage handler produces an error, you simply get an "AMQJS0005E Internal error" with error code 5 in the onConnectionLost handler.

However, if you set a breakpoint at Paho.MQTT.ClientImpl._handleMessage (mqttws31.js:1343) You can see that error.message has the real cause, and that the code clearly attempts to preserve it, but either the usage of format is wrong, or format itself is wrong. Either way, you don't get the error.message preserved.

Further, presumably because of the way the "scope" function is created, you lose the stack trace taking you back to the original user supplied function. This seems like a backwards step, the stack trace below is all that chromium developer tools will show me, when I stop where I can see my error, but the "anonymous function" is the "scope" function, not my own function, so I have to read the error, and then try and infer which method of my own might have caused it.

Paho.MQTT.ClientImpl._handleMessage (mqttws31.js:1343)
Paho.MQTT.ClientImpl._on_socket_message (mqttws31.js:1152)
(anonymous function) (mqttws31.js:157)

On 2014-07-22 11:01:35 -0400, Karl Palsson wrote:

Created attachment 245270
demonstrates failure to preserve errors or stacktraces

On 2014-07-22 11:07:01 -0400, Karl Palsson wrote:

Example of what error.stack looks like in the _handleMessage exception handler, showing that it is useful, before the js library swallows it:

error.stack
"ReferenceError: wop is not defined
at onMessageArrived (http://192.168.255.38/cgi-bin/luci/;stok=9ea51323a52992a6ae727f50301d7492/home/hoho:50:16)
at Paho.MQTT.ClientImpl._receiveMessage (http://192.168.255.38/resources/paho/mqttws31.js:1402:9)
at Paho.MQTT.ClientImpl._receivePublish (http://192.168.255.38/resources/paho/mqttws31.js:1377:10)
at Paho.MQTT.ClientImpl._handleMessage (http://192.168.255.38/resources/paho/mqttws31.js:1251:10)
at Paho.MQTT.ClientImpl._on_socket_message (http://192.168.255.38/resources/paho/mqttws31.js:1152:12)
at WebSocket.Paho.MQTT.scope (http://192.168.255.38/resources/paho/mqttws31.js:157:13)"

On 2014-08-10 22:44:10 -0400, Tang Zi Han wrote:

I can reproduce the scenario and try to fix it .

On 2014-08-11 03:52:14 -0400, Tang Zi Han wrote:

The config of Error text do not leave a placeholder to format error message and stack trace.

Fixed and Close.

Karl's description and demonstration is very helpful.

On 2014-08-11 04:46:32 -0400, Tang Zi Han wrote:

Change the Error variable to
INTERNAL_ERROR: {code:5, text:"AMQJS0005E Internal error. Error Message: {0}, Stack trace: {1}"},

and add error message and stack trace to related callback.
this._disconnected(ERROR.INTERNAL_ERROR.code , format(ERROR.INTERNAL_ERROR, [error.message,error.stack.toString()]));

push the fix to develop branch

On 2014-08-11 13:47:23 -0400, Karl Palsson wrote:

This is a substantial improvement, but it could still be better. Is there any actual reason not to just let it bubble up as it is? In chromium, the string representation is parsed, and you can click on the elements of the stack trace nicely. Firefox just shows it as raw text.

On 2014-08-13 23:07:33 -0400, Tang Zi Han wrote:

(In reply to Karl Palsson from comment # 6)

This is a substantial improvement, but it could still be better. Is there
any actual reason not to just let it bubble up as it is? In chromium, the
string representation is parsed, and you can click on the elements of the
stack trace nicely. Firefox just shows it as raw text.

The actual reason is that the try-catch block in ClientImpl.prototype._handleMessage.
If some error occures in the callback function which is called based on the MESSAGE_TYPE , it will go to the catch block to deal with the error or exception.
Based on the currently design, the easiest and best way is to bubble up the error to notify developer.

Multi-topic support for subscribe and unsubscribe

migrated from Bugzilla #473089
status UNCONFIRMED severity normal in component MQTT-JS for ---
Reported in version 1.0 on platform All
Assigned to: Ian Craggs

On 2015-07-20 11:10:56 -0400, James Sutton wrote:

According to the API mqtt v3.1.1 spec (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718063), the client should be able to create one or more subscriptions. Currently the Javascript API only subscribes and unsubscribes to one topic at a time. This should be changed in order to match the specification.

Utility does not have correct default path for iot.eclipse.org

migrated from Bugzilla #478320
status CLOSED severity normal in component MQTT-JS for 1.2
Reported in version unspecified on platform PC
Assigned to: James Sutton

On 2015-09-24 10:00:24 -0400, James Sutton wrote:

Currently the javascript demo utility has the iot.eclipse.org server as it's default, however it does not have the correct websocket path. The path should be /ws. This should be fixed to make it easier for users to use the demo.

On 2015-09-24 10:01:34 -0400, Eclipse Genie wrote:

New Gerrit change created: https://git.eclipse.org/r/56626

On 2015-09-24 10:05:53 -0400, Eclipse Genie wrote:

Gerrit change https://git.eclipse.org/r/56626 was merged to [develop].
Commit: http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.javascript.git/commit/?id=SHA: 1ffbead

On 2015-09-24 10:06:27 -0400, James Sutton wrote:

This change is now delivered.

client doesn't maintain keepalive

migrated from Bugzilla #483990
status RESOLVED severity normal in component MQTT-JS for 1.2
Reported in version 1.2 on platform All
Assigned to: James Sutton

On 2015-12-09 05:03:10 -0500, Andy Stanford-Clark wrote nothing.
On 2015-12-09 05:08:32 -0500, Andy Stanford-Clark wrote:

If the client is receiving regular messages, but not publishing any, the connection drops when the keepalive timer expires on the broker.

line 1080 of mqttws31.js ...
// Reset the receive ping timer, we now have evidence the server is alive.
this.receivePinger.reset();

remove those two lines. Keepalive is to provide evidence to the broker that the client is alive, not the other way round.

There is a bigger question of the client deciding when the connection to the broker has gone away, but there's already a bug open for that.

On 2015-12-09 05:36:07 -0500, Eclipse Genie wrote:

New Gerrit change created: https://git.eclipse.org/r/62300

On 2015-12-11 06:24:53 -0500, Eclipse Genie wrote:

Gerrit change https://git.eclipse.org/r/62300 was merged to [develop].
Commit: http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.javascript.git/commit/?id=SHA: fcb3b0a

messages mixed up when multiple retained messages are received at once

migrated from Bugzilla #424753
status RESOLVED severity normal in component MQTT-JS for ---
Reported in version future on platform PC
Assigned to: Andrew Banks

On 2013-12-30 12:15:34 -0500, Kris K wrote:

Using the developer branch, which I believe, is supposed to handle multiple messages in one websocket frame, messages appear to get mixed up.
I am using mosquitto with the mod_websocket from https://launchpad.net/~roger.light/+archive/ppa

Steps to reproduce:

  1. create 2 retained msgs:
    mosquitto_pub -t "/test/topic1" -m "blaba" -r
    mosquitto_pub -t "/test/topic2" -m "blubu" -r

  2. run javascript:
    var clientid = "clientid_"+ Math.random().toString(36).substring(7);
    client = new Messaging.Client("wss://172.22.197.77:443/mqtt", clientid); // your mqtt-websocket broker here
    client.onConnectionLost = onConnectionLost;
    client.onMessageArrived = onMessageArrived;
    client.connect({onSuccess:onConnect});

function onConnect() {
console.log("onConnect");
client.subscribe("/test/#");
};

function onConnectionLost(responseObject) {
if (responseObject.errorCode !== 0)
console.log("onConnectionLost:"+responseObject.errorMessage);
};

function onMessageArrived(message) {
console.log("onMessageArrived: Topic: "+message.destinationName+' msg='+message.payloadString);
}

  1. on my system, it comes out like this:
    onConnect retained_msg_test.html:18
    onMessageArrived: Topic: /test/topic1 msg=blaba1/test/topic2blubu retained_msg_test.html:29
    onMessageArrived: Topic: /test/topic2 msg=blubu

On 2014-01-09 09:48:23 -0500, Kris K wrote:

following patch will fix this problem:

diff --git a/src/main/javascript-templates/mqttws31s.js b/src/main/javascript-templates/mqttws31s.js
index a234c49..36f2e63 100644
@@ -459,7 +459,7 @@ Messaging = (function (global) {
pos += 2;
}

  •         var message = new Messaging.Message(input.subarray(pos));
    
  •         var message = new Messaging.Message(input.subarray(pos, endPos));
          if ((messageInfo & 0x01) == 0x01) 
              message.retained = true;
          if ((messageInfo & 0x08) == 0x08)
    

Please add 'topic' as an alias for 'destinationName'

migrated from Bugzilla #433811
status RESOLVED severity enhancement in component MQTT-JS for 1.1
Reported in version unspecified on platform All
Assigned to: Andrew Banks

On 2014-04-30 02:10:19 -0400, Jan-Piet Mens wrote:

mqttws31.js calls the MQTT topic 'destinationName' which is a bit confusing (as well as being long to type :-)

Would it be possible to add an "alias" to it to call it "topic"? This is more in line with the MQTT terminology, and an alias would not break old code which relies on destinationName.

On 2014-04-30 07:29:21 -0400, Ian Craggs wrote:

The latest version of the spec uses "topic filter" and "topic name" for when wildcards are allowed and when they are not, respectively. I realize that topicFilter and topicName are not as short... I just thought I'd mention it :-)

On 2014-07-03 09:38:08 -0400, Al Stockdill-Mander wrote:

As the field is directly editable (and not an aliasable type like an array or object) adding an "alias" means adding another field to Message and ensuring the content of both is kept in sync. I agree the naming is not ideal but I'm not in favour of a breaking change. closing as wontfix

JavaScript Auto reconnect

migrated from Bugzilla #481249
status UNCONFIRMED severity normal in component MQTT-JS for 1.2
Reported in version 1.2 on platform All
Assigned to: Mike Tran

On 2015-11-02 11:08:07 -0500, Mike Tran wrote:

In the current implementation, the client is disconnected at its own request or because of the server or network disconnected. When disconnect occurs, all message buffers are cleared and socket is reset. Then if backup hosts and ports were specified in connection options at connect time, the client attempts to connect to a new host in the list. Otherwise, either onConnectionLost or onFailure callback is called.

From the application perspective, it is desirable to have an option to auto-reconnect until exhausted (i.e. time interval and maximum number of retries)

On 2015-11-02 11:39:28 -0500, Ian Craggs wrote:

Putting in the correct component.

ie9 compatibilty: SCRIPT1028: Expected identifier, string or number

migrated from Bugzilla #443805
status RESOLVED severity normal in component MQTT-JS for 1.1
Reported in version 1.0 on platform PC
Assigned to: Tang Zi Han

Original attachment names and IDs:

On 2014-09-11 06:12:35 -0400, Karl Palsson wrote:

Created attachment 246953
remove trailing comma in object

Trailing commas in dictionary objects cause problems for ie9. Ie9 doesn't support websockets, this is true, but I expect to get paho's built in, "websockets not supported" error, not a hard to understand script syntax error.

Patch attached

On 2014-12-26 03:17:23 -0500, Tang Zi Han wrote:

Fixed in https://git.eclipse.org/r/#/c/38780/

On 2015-01-05 02:21:36 -0500, Tang Zi Han wrote:

Merged in to develop branch

Enable automated testing of JS client

migrated from Bugzilla #418081
status RESOLVED severity normal in component MQTT-JS for ---
Reported in version v0.5 on platform PC
Assigned to: Al Stockdill-Mander

Original attachment names and IDs:

On 2013-09-26 06:41:02 -0400, Al Stockdill-Mander wrote:

It would be good to have automated testing of the JS client (I imagine drive by Hudson like the other clients).

On 2013-09-26 07:11:29 -0400, Al Stockdill-Mander wrote:

I've just created a develop branch for the JS client to work on this and pushed some changes there. I've set up a maven pom file to help manage the tasks for setting up and running the tests.
There is a package.json file that gives the node pre reqs for running the tests. I've taken the mqttws31.js file and removed a few lines, added hooks to be replaced and called it mqttws31s.js and put it in src/main/javascript-templates.
When mvn compile or other lifecycle tasks requiring it are run it will produce two js files in target/src/javascript; mqttws31.js is the standard JS client that works in a web browser and is the same as what exists in the master branch. mqttws31n.js is a slightly modified version that it able to be run under nodejs.

In src/test/javascript-templates is base-spec.js. This is a simple proving file of 4 basic tests for the JS client. The file is filtered to insert the correct directory to load the JS client from and insert the test server (mvn test -Dtest.server="m2m.eclipse.org" for example), currently as per the browser client only websockets are supported.

Additionally the tests in base-spec.js can be run in a browser, running mvn jasmine:bdd will configure the environment and provide a localhost link that can be opened in a browser (mvn compile process-test-sources -Dtest.server="server" must have been run first to build the client and tests)

I realise this is a hacky way of doing this but very little had to be changed to allow it to work.

On 2013-09-30 06:37:57 -0400, Tang Zi Han wrote:

Created attachment 235954
Js client test of basic function.

The test specs all passed in browser. But some do not pass in Node.js, especially the case about 'connect','disconnect' or 'HA connect'.

On 2013-10-01 04:49:17 -0400, Al Stockdill-Mander wrote:

I've fixed the client so those tests should pass in the nodejs version under this commit; http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.javascript.git/commit/?h=develop&id=SHA: cda7202

On 2013-10-11 05:11:05 -0400, Bin Zhang wrote:

Created attachment 236366
js client - SendReceiveTest

The SendReceiveTest of js client, all passed for both browser and node.js.

BUT need to comment out one line in mqttws31n.js for node.js to avoid the TypeError: Cannot read property 'onclose' of undefined

Line: //if (ref.socket.onclose != null) ref.socket.onclose();

On 2013-10-11 05:19:57 -0400, Tang Zi Han wrote:

Created attachment 236367
Js client- basicTest

revise the '235954: Js client test of basic function'

On 2013-10-15 01:08:31 -0400, Bin Zhang wrote:

Created attachment 236470
js client - LiveTakeOverTest

The LiveTakeOverTest of js client, all passed for both browser and node.js.

On 2013-10-17 05:47:14 -0400, Tang Zi Han wrote:

Created attachment 236582
Js client- basicTest

revise the basicTest.
client id with '-' is not allowed by the server of MQ v7.5.0.1

On 2013-10-17 06:08:10 -0400, Tang Zi Han wrote:

Created attachment 236584
js client-BasicSSLTest

The basic ssl test for js client. All cases pass in browser(Firefox).

SSL server: MQ v7.5.0.1 ; Test browser: Firefox(17.0.9)

Set up the SSL server and client on local environment following the info-center as below:
1.Connecting the MQTT messaging client for JavaScript over SSL and WebSockets:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/index.jsp?topic=%2Fcom.ibm.mq.helphome.doc%2Fwmq_helphome.html
2.http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/index.jsp?topic=%2Fcom.ibm.mm.tc.doc%2Ftc00151_.htm

Then import the 2 certificates to Firefox:
'cacert.cer' and 'cltkeystore.p12'

On 2013-12-17 11:00:55 -0500, Ian Craggs wrote:

This defect should be in a different state. Resolved even?

On 2013-12-17 20:57:44 -0500, Tang Zi Han wrote:

(In reply to Ian Craggs from comment # 9)

This defect should be in a different state. Resolved even?

JS Client automated tests are finished. This defect is resolved.

On 2013-12-18 04:47:01 -0500, Al Stockdill-Mander wrote:

Tests now in place and running

Maven JS obfuscated file contains wrong code

The mvn compress goal produces wrong code.
The regular Message.prototype contains the getPayloadString() and getPayloadBytes() functions.
After obfuscation this functions are renamed to "getPayloadStringfunction" and "getPayloadBytesfunction".
The ClientImpl prototype method store() is not updated accordingly and refers in the obfuscated version to the original getPayloadBytes - therefor all calls to send() with a qos=1 message fail for the mqttws31-min.js file.

I have not checked for more errors. At least current minified version is unusable.

Original file:

 ClientImpl.prototype.store = function(prefix, wireMessage) {
        var storedMessage = {type:wireMessage.type,  messageIdentifier:wireMessage.messageIdentifier, version:1};

        switch(wireMessage.type) {
          case MESSAGE_TYPE.PUBLISH:
              if(wireMessage.pubRecReceived)
                  storedMessage.pubRecReceived = true;

              // Convert the payload to a hex string.
              storedMessage.payloadMessage = {};
              var hex = "";
              var messageBytes = wireMessage.payloadMessage.payloadBytes;
              for (var i=0; i<messageBytes.length; i++) {
                if (messageBytes[i] <= 0xF)

...

    Message.prototype = {
        get payloadString() { return this._getPayloadString(); },
        get payloadBytes() { return this._getPayloadBytes(); },
        ...

Minified/compressed version (with code reformatted for easier reading):

    v.prototype.store = function (E, D) {
        var A = {type: D.type, messageIdentifier: D.messageIdentifier, version: 1};
        switch (D.type) {
            case o.PUBLISH:
                if (D.pubRecReceived) {
                    A.pubRecReceived = true
                }
                A.payloadMessage = {};
                var C = "";
                var B = D.payloadMessage.payloadBytes;
                for (var z = 0; z < B.length; z++) {
                    if (B[z] <= 15) {

...

    a.prototype = {
        get payloadStringfunction() {
            return this._getPayloadString()
        }, get payloadBytesfunction() {
            return this._getPayloadBytes()
        }, get destinationNamefunction() {
        ...

Testcalls:

var message = new Paho.MQTT.Message(1);
message.destinationName = 'topic';
message.qos = 1;
mqttClient.send(message);

Disconnect when sending larger message (about 15kb)

migrated from Bugzilla #455446
status RESOLVED severity major in component MQTT-JS for 1.1
Reported in version unspecified on platform PC
Assigned to: Tang Zi Han

On 2014-12-17 04:25:48 -0500, Stefan Ekman wrote:

Using MQTT client from http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.javascript.git/plain/src/mqttws31.js

Using broker ActiveMQ 5.10.0 on a Ubuntu host.

Sending message in the end of the bug report fails with "AMQJS0008I Socket closed." Same result using Chrome latest version and Internet Explorer 11.

Sending a smaller version of the same JSON string works fine.

Sending the very same message with a few different tools(mosquitto_pub.exe, activemq's admin pages) to the broker works fine so that confirms that the broker is ok with the size of message.

Message:
"{"nSession":2,"csTitleMain1":"Spelschema - Omgรƒยฅng 2","csTitleMain2":"2014 HT Slut onsdag 5/11","serier":[{"csTitleSub":"Mรƒยคstarserien onsdag","matcher":[{"nTeamIDHome":19627,"nTeamIDAway":19628,"nTable":1,"csTeamHome":"Berik","csTeamAway":"Bahaj","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":18,"nVPTotAway":25,"nRankHome":2,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19629,"nTeamIDAway":19631,"nTable":2,"csTeamHome":"Nya Bridgeskolan","csTeamAway":"Norbรƒยคck","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":2,"nRankHome":0,"nRankAway":6,"nUpDownHome":0,"nUpDownAway":0,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19632,"nTeamIDAway":19630,"nTable":3,"csTeamHome":"Goldberg","csTeamAway":"BK Herkules","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":18,"nRankHome":4,"nRankAway":2,"nUpDownHome":0,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19641,"nTeamIDAway":19633,"nTable":4,"csTeamHome":"Huvet","csTeamAway":"Jรƒยถrgen Lindqvist cr","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":21,"nRankHome":6,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"}]},{"csTitleSub":"Eliten 1 onsdag","matcher":[{"nTeamIDHome":19627,"nTeamIDAway":19628,"nTable":1,"csTeamHome":"Berik","csTeamAway":"Bahaj","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":18,"nVPTotAway":25,"nRankHome":2,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19629,"nTeamIDAway":19631,"nTable":2,"csTeamHome":"Nya Bridgeskolan","csTeamAway":"Norbรƒยคck","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":2,"nRankHome":0,"nRankAway":6,"nUpDownHome":0,"nUpDownAway":0,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19632,"nTeamIDAway":19630,"nTable":3,"csTeamHome":"Goldberg","csTeamAway":"BK Herkules","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":18,"nRankHome":4,"nRankAway":2,"nUpDownHome":0,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19641,"nTeamIDAway":19633,"nTable":4,"csTeamHome":"Huvet","csTeamAway":"Jรƒยถrgen Lindqvist cr","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":21,"nRankHome":6,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"}]},{"csTitleSub":"Mรƒยคstarserien onsdag","matcher":[{"nTeamIDHome":19627,"nTeamIDAway":19628,"nTable":1,"csTeamHome":"Berik","csTeamAway":"Bahaj","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":18,"nVPTotAway":25,"nRankHome":2,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19629,"nTeamIDAway":19631,"nTable":2,"csTeamHome":"Nya Bridgeskolan","csTeamAway":"Norbรƒยคck","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":2,"nRankHome":0,"nRankAway":6,"nUpDownHome":0,"nUpDownAway":0,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19632,"nTeamIDAway":19630,"nTable":3,"csTeamHome":"Goldberg","csTeamAway":"BK Herkules","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":18,"nRankHome":4,"nRankAway":2,"nUpDownHome":0,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19641,"nTeamIDAway":19633,"nTable":4,"csTeamHome":"Huvet","csTeamAway":"Jรƒยถrgen Lindqvist cr","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":21,"nRankHome":6,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"}]},{"csTitleSub":"Eliten 1 onsdag","matcher":[{"nTeamIDHome":19627,"nTeamIDAway":19628,"nTable":1,"csTeamHome":"Berik","csTeamAway":"Bahaj","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":18,"nVPTotAway":25,"nRankHome":2,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19629,"nTeamIDAway":19631,"nTable":2,"csTeamHome":"Nya Bridgeskolan","csTeamAway":"Norbรƒยคck","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":2,"nRankHome":0,"nRankAway":6,"nUpDownHome":0,"nUpDownAway":0,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19632,"nTeamIDAway":19630,"nTable":3,"csTeamHome":"Goldberg","csTeamAway":"BK Herkules","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":18,"nRankHome":4,"nRankAway":2,"nUpDownHome":0,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19641,"nTeamIDAway":19633,"nTable":4,"csTeamHome":"Huvet","csTeamAway":"Jรƒยถrgen Lindqvist cr","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":21,"nRankHome":6,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"}]},{"csTitleSub":"Mรƒยคstarserien onsdag","matcher":[{"nTeamIDHome":19627,"nTeamIDAway":19628,"nTable":1,"csTeamHome":"Berik","csTeamAway":"Bahaj","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":18,"nVPTotAway":25,"nRankHome":2,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19629,"nTeamIDAway":19631,"nTable":2,"csTeamHome":"Nya Bridgeskolan","csTeamAway":"Norbรƒยคck","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":2,"nRankHome":0,"nRankAway":6,"nUpDownHome":0,"nUpDownAway":0,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19632,"nTeamIDAway":19630,"nTable":3,"csTeamHome":"Goldberg","csTeamAway":"BK Herkules","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":18,"nRankHome":4,"nRankAway":2,"nUpDownHome":0,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19641,"nTeamIDAway":19633,"nTable":4,"csTeamHome":"Huvet","csTeamAway":"Jรƒยถrgen Lindqvist cr","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":21,"nRankHome":6,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"}]},{"csTitleSub":"Eliten 1 onsdag","matcher":[{"nTeamIDHome":19627,"nTeamIDAway":19628,"nTable":1,"csTeamHome":"Berik","csTeamAway":"Bahaj","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":18,"nVPTotAway":25,"nRankHome":2,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19629,"nTeamIDAway":19631,"nTable":2,"csTeamHome":"Nya Bridgeskolan","csTeamAway":"Norbรƒยคck","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":2,"nRankHome":0,"nRankAway":6,"nUpDownHome":0,"nUpDownAway":0,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19632,"nTeamIDAway":19630,"nTable":3,"csTeamHome":"Goldberg","csTeamAway":"BK Herkules","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":18,"nRankHome":4,"nRankAway":2,"nUpDownHome":0,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19641,"nTeamIDAway":19633,"nTable":4,"csTeamHome":"Huvet","csTeamAway":"Jรƒยถrgen Lindqvist cr","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":21,"nRankHome":6,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"}]},{"csTitleSub":"Mรƒยคstarserien onsdag","matcher":[{"nTeamIDHome":19627,"nTeamIDAway":19628,"nTable":1,"csTeamHome":"Berik","csTeamAway":"Bahaj","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":18,"nVPTotAway":25,"nRankHome":2,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19629,"nTeamIDAway":19631,"nTable":2,"csTeamHome":"Nya Bridgeskolan","csTeamAway":"Norbรƒยคck","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":2,"nRankHome":0,"nRankAway":6,"nUpDownHome":0,"nUpDownAway":0,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19632,"nTeamIDAway":19630,"nTable":3,"csTeamHome":"Goldberg","csTeamAway":"BK Herkules","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":18,"nRankHome":4,"nRankAway":2,"nUpDownHome":0,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19641,"nTeamIDAway":19633,"nTable":4,"csTeamHome":"Huvet","csTeamAway":"Jรƒยถrgen Lindqvist cr","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":21,"nRankHome":6,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"}]},{"csTitleSub":"Eliten 1 onsdag","matcher":[{"nTeamIDHome":19627,"nTeamIDAway":19628,"nTable":1,"csTeamHome":"Berik","csTeamAway":"Bahaj","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":18,"nVPTotAway":25,"nRankHome":2,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19629,"nTeamIDAway":19631,"nTable":2,"csTeamHome":"Nya Bridgeskolan","csTeamAway":"Norbรƒยคck","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":2,"nRankHome":0,"nRankAway":6,"nUpDownHome":0,"nUpDownAway":0,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19632,"nTeamIDAway":19630,"nTable":3,"csTeamHome":"Goldberg","csTeamAway":"BK Herkules","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":18,"nRankHome":4,"nRankAway":2,"nUpDownHome":0,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"},{"nTeamIDHome":19641,"nTeamIDAway":19633,"nTable":4,"csTeamHome":"Huvet","csTeamAway":"Jรƒยถrgen Lindqvist cr","nIMPMatchHome":-1,"nIMPMatchAway":-1,"nVPMatchHome":-1,"nVPMatchAway":-1,"nVPTotHome":12,"nVPTotAway":21,"nRankHome":6,"nRankAway":1,"nUpDownHome":-1,"nUpDownAway":-1,"csMemberID1Home":"NULL","csMemberID2Home":"NULL","csMemberID3Home":"NULL","csMemberID4Home":"NULL","csMemberID1Away":"NULL","csMemberID2Away":"NULL","csMemberID3Away":"NULL","csMemberID4Away":"NULL"}]}]}"

On 2014-12-17 08:38:08 -0500, Stefan Ekman wrote:

I have also encoded the string to Base64 to remove encoding problems but with the same result.

On 2015-01-14 01:01:04 -0500, Tang Zi Han wrote:

Test with Websphere MQ as the server , there are not connection lost . Can you check your server side error log?

On 2015-01-14 02:14:00 -0500, Tang Zi Han wrote:

(In reply to Stefan Ekman from comment # 1)

I have also encoded the string to Base64 to remove encoding problems but
with the same result.

The message of 100kb works fine with chrome and firefox. Browsers set up mqtt connection with Websocket, and the Websocket behave differently in different browsers. You can try with firefox for the same size message.

On 2015-01-14 03:11:48 -0500, Tang Zi Han wrote:

For big data test between different browsers:
200kb message : IE 10 and Firefox 24.4 work fine.
chrome 38 don't support message larger than 14kb.

It's an issue about compatibility of browsers.

It won't be resolved in JS client.

On 2015-01-14 06:57:18 -0500, Ian Craggs wrote:

Changed bug state to reflect Amy's comments.

Client disconnecting due to timeout (no pingreq being sent)

migrated from Bugzilla #407627
status RESOLVED severity major in component MQTT-JS for ---
Reported in version v0.5 on platform All
Assigned to: Andrew Banks

On 2013-05-09 03:33:42 -0400, Simon Racliffe wrote:

When the Paho MQTT JS cleint is connected to a server and only subscribes to topics at qos 0 it gets disconnected after the timeout period if it is receiving PUBLISH messages.

In this situation the server sends PUBLISH messages to the client, but with qos 0 the client does not respond with a PUBACK meaning the server does not reset its timeout period.

I think the client is incorrectly resetting its timeout counter when it receives the PUBLISH message, and therefore doesn't send a PINGREQ and hence gets disconnected.

I am using Mosquitto as the server if that is of any relevance (I bleieve not).

On 2013-05-14 09:42:09 -0400, Nicholas O'Leary wrote:

Confirmed - the client incorrectly resets the time-out whenever it sends or receives anything and doesn't distinguish between the two.

This causes two faults with the client:

  1. as reported, if the only messages flowing are qos 0 from the server, the client never sends a PINGREQ so will be disconnected by the server.
  2. if the only messages flowing are qos 0 from the client, the client never sends a PINGREQ so will never detect if the server/network hangs until the TCP connection times out which could be a long time.

Of these two scenarios, # 1 is the more likely and severe. # 2 is an edge case that, whilst not ideal, will at least resolve itself if the TCP connection eventually times out.

A quick fix that addresses # 1, but not # 2, is:

In ClientImpl.prototype._on_socket_message, move the call to reset the pinger from the start of the function to within the case block for MESSAGE_TYPE.PINGRESP. In other words, only reset the ping handling when we receive a pingrep from the broker.

The proper way to handle keepalive logic is to track last-sent and last-received times separately and send a ping when either one exceeds the keepalive time.

On 2013-06-25 04:59:49 -0400, Andrew Banks wrote:

AQdded extra timer.

Subscribing to multiple topics, doesn't return all retained messages

migrated from Bugzilla #426574
status CLOSED severity normal in component MQTT-JS for ---
Reported in version v0.5 on platform Other
Assigned to: Andrew Banks

On 2014-01-24 08:11:25 -0500, Matthew Bordignon wrote:

Example code I am using, https://gist.github.com/matbor/8596774

Using current master of mqttws31.js

If I subscribe to multiple topics, (all these topics have retained messages & I have tested with another client to make sure of this), the javascript client only returns one of the retained messages for one subscription.

For example;
I have 4 topics, each topic has one retained message.
When I connect and subscribe to each of these topics I might get one or two of the retained messages, not all 4!

I have tired similar code with the older mosquitto-1.1.js client and it will receive ALL the retained messages when you subscribe.

Thanks
Matt.

On 2014-01-25 22:41:26 -0500, Matthew Bordignon wrote:

Update.. Using Mosquitto Broker 1.2.3 and websockets on lighhtp I have this issue, but if I use hivemq with websockets it is fine.

On 2014-02-01 11:36:57 -0500, Nicholas O'Leary wrote:

The fact it works with HiveMQ and not Mosquitto suggests this isn't a problem with the client.

Will get Roger's view on this from Mosquitto.

On 2014-02-01 12:48:47 -0500, Roger Light wrote:

I've tried adding matching retained messages to the broker running on test.mosquitto.org:80 - all of the messages get returned to me.

Could you try using test.mosquitto.org yourself - maybe there is something that isn't working with your lighttpd setup.

On 2014-02-05 22:19:14 -0500, Matthew Bordignon wrote:

ok, retired with broker.mqttdashboard and works fine, must be my lighttpd server causing problems. will have to investigate more,might just leave hivemq for now, so much easier to setup. thx for the follow ups.

On 2014-02-06 04:16:32 -0500, Nicholas O'Leary wrote:

Thanks for checking on that. Will close as there's nothing for us to do.

Client does not handle multiple MQTT messages in single WebSocket payload

migrated from Bugzilla #413579
status RESOLVED severity major in component MQTT-JS for ---
Reported in version v0.5 on platform PC
Assigned to: Nicholas O'Leary

Original attachment names and IDs:

On 2013-07-23 17:14:32 -0400, Darren Clark wrote:

Created attachment 233734
Patch for issue.

It is possible that multiple MQTT payloads will be delivered in a single WebSocket payload when using a bridge. Verified with Mosquitto/lighttpd/mod_websocket using both Chrome and Firefox browsers. Easily reproducible when a subscription request results in multiple retained messages being immediately sent. Result is a single call to onMessageArrived where the payload is the data for the first PUBLISH, concatenated with the raw MQTT protocol byte stream for following PUBLISHes.

Patch attached.

On 2013-09-27 06:08:03 -0400, Ian Craggs wrote:

Assigned to Al.

On 2013-09-27 19:08:00 -0400, Nicholas O'Leary wrote:

Pushed a fix to the develop branch.

Doesn't use Darren's patch as that only handled the case where a single ws frame contains 1 or more whole MQTT packets; it didn't handle fragmented packets.

Handling fragmented packets needed a slightly different approach.

Have tested sending a large body of text in a single MQTT publish, that gets fragmented over multiple ws frames.

On 2013-09-27 19:08:31 -0400, Nicholas O'Leary wrote:

Marking resolved as per previous comment.

WebSocket connect fail with array of protocol

migrated from Bugzilla #437641
status RESOLVED severity normal in component MQTT-JS for 0.9
Reported in version 0.9 on platform PC
Assigned to: Andrew Banks

Original attachment names and IDs:

On 2014-06-18 03:42:44 -0400, Tang Zi Han wrote:

In Firefox 24+,
Connect fail with
new WebSocket(wsurl, ["mqtt","mqttv3.1"]);

The following is ok:
new WebSocket(wsurl, "mqttv3.1");

On 2014-07-03 07:08:52 -0400, Al Stockdill-Mander wrote:

What server were you connecting to and do you have any trace information?
An array of subprotocols is a valid user (https://developer.mozilla.org/en-US/docs/Web/API/WebSocket) Did you also try new WebSocket(wsurl, "mqtt"); ?

On 2014-07-03 22:30:15 -0400, Tang Zi Han wrote:

(In reply to Al Stockdill-Mander from comment # 1)

What server were you connecting to and do you have any trace information?
An array of subprotocols is a valid user
(https://developer.mozilla.org/en-US/docs/Web/API/WebSocket) Did you also
try new WebSocket(wsurl, "mqtt"); ?

The server is MQ telemetry 7.5.0.1.

The trace in console:

"NetworkError: 400 AMQHT0400E: Bad Request. - http://9.119.152.26:1883/mqtt"
mqtt
Firefox can't establish a connection to the server at ws://9.119.152.26:1883/mqtt.

this.socket = new WebSocket(wsurl, ["mqtt","mqttv3.1"]); mqttws31.js (line 968)
"NetworkError: 400 AMQHT0400E: Bad Request. - http://9.119.152.26:1883/mqtt"
mqtt

Connect fail. ErrorCode: 7, ErrorMsg: AMQJS0007E Socket error:undefined. Object { errorCode=7, errorMessage="AMQJS0007E Socket error:undefined.", invocationContext=undefined} TabConn.js (line 845)
Firefox can't establish a connection to the server at ws://9.119.152.26:1883 /mqtt.

this.socket = new WebSocket(wsurl, ["mqtt","mqttv3.1"]);

new WebSocket(wsurl, "mqtt"); is also ok.

It is ok to use MessageSight as server.

On 2014-07-22 11:00:24 -0400, Al Stockdill-Mander wrote:

This appears to be an error in the server, it is legitimate for a client to present an array of sub protocols.

On 2014-07-22 11:33:26 -0400, Karl Palsson wrote:

I would urge you to reconsider. While it is indeed true that the servers are non-compliant, they are unfortunately out there. Given that the code already has support for automatic fallback on protocol version, I see no reason to reject any attempt to support servers that only support a single protocol.

Indeed, connecting to a mqtt3.1.1 server and asking for the "mqttv3.1" is already arguably wrong. Attached is a patch that, if the mqttVersion is set explicitly, only sends the appropriate websockets protocol, instead of the full array each time.

Please consider the patch to public domain

On 2014-07-22 11:34:02 -0400, Karl Palsson wrote:

Created attachment 245273
if mqttVersion is set, only apply the matching websockets protocol

On 2014-07-22 12:05:17 -0400, Al Stockdill-Mander wrote:

Actually there is a good option here for a fallback similar to the way we handle protocol levels

On 2014-07-23 10:00:37 -0400, Al Stockdill-Mander wrote:

Implemented a simple switch so that mqttv3.1 is transmitted when V3 and mqtt is transmitted when V4.

Fix payload assignment for messages.

migrated from Bugzilla #434555
status RESOLVED severity normal in component MQTT-JS for 0.9
Reported in version v0.5 on platform All
Assigned to: Andrew Banks

Original attachment names and IDs:

On 2014-05-09 17:33:42 -0400, Philip Matura wrote:

Created attachment 242915
Proposed patch.

Right now message.payload.length returns an inappropriate lenght if more than one message is parsed in one call.

On 2014-07-09 09:16:31 -0400, Al Stockdill-Mander wrote:

This was fixed in the develop branch in March by Nick; http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.javascript.git/commit/?h=develop&id=SHA: 4798ac2

Unable to get connection status

migrated from Bugzilla #409773
status RESOLVED severity minor in component MQTT-JS for ---
Reported in version v0.5 on platform PC
Assigned to: Andrew Banks

On 2013-06-03 14:30:06 -0400, Alexander Rust wrote:

Hi again,

so far I've been unable to get the connection status of the Messaging.Client.

If one disconnects when the client is not connected, it throws an INVALID_STATE that basically wrecks the client. Thus it would be good to have the possibility to check the connection state of the client to prevent such errors.

Maybe I'm mistaken, but ClientImpl.prototype.connected is also listed below Messaging Client private instance members.

Is there really no method to check the connection status?
If so, is there any reason behind this?

On 2014-06-06 05:43:01 -0400, Al Stockdill-Mander wrote:

The Client object now provides an isConnected() function

Minified version of Javascript client is broken

migrated from Bugzilla #469700
status RESOLVED severity normal in component MQTT-JS for 1.2
Reported in version 1.0 on platform All
Assigned to: Ian Craggs

On 2015-06-09 05:36:46 -0400, James Sutton wrote:

version: 1.0.1

Using the minified client, when publishing a message, the following error is shown:

Uncaught TypeError: Cannot read property 'byteLength' of undefined mqttws31-min.js:15
Paho.MQTT.q.encode mqttws31-min.js:15
Paho.MQTT.v._socket_send mqttws31-min.js:15
Paho.MQTT.v._process_queue mqttws31-min.js:15
Paho.MQTT.v._schedule_message mqttws31-min.js:15
Paho.MQTT.v.send mqttws31-min.js:15
Paho.MQTT.p.send mqttws31-min.js:15

The payloadMessage does not have payloadBytes set at this point when it should.

I think this is a product of the minification process, the script is attempting to call 'payloadBytes' of the message object:

var F = this.payloadMessage.payloadBytes;
K += F.byteLength;

However, in the Message prototype, the function name has been changed

Non Minified version:

get payloadBytes() { return this._getPayloadBytes(); },

Minified version:

get payloadBytesfunction() {
return this._getPayloadBytes()

On 2015-06-09 06:46:01 -0400, James Sutton wrote:

I've tried compressing using Google Closure and JSmin and they seem to compress correctly.

Closure Compressed:

get payloadBytes() {
return this._getPayloadBytes()
},

JSmin Compressed:

get payloadBytes() {
return this._getPayloadBytes();
},

On 2015-06-11 04:56:51 -0400, James Sutton wrote:

I've raised an issue on the YUICompressor as it seems like the fault is with that. yui/yuicompressor#206

On 2015-07-21 05:16:26 -0400, James Sutton wrote:

We manually minified the file using closure, tested it and re-uploaded the download zip on the paho website. This will mean that people can use the minified version for now. Hopefully the YUICompressor bug will be fixed, or we may have to start using another compressor in the long term.

MQTT Javascript Sample Uses Messaging Instead of Paho.MQTT in Getting Started Web Site

migrated from Bugzilla #448136
status RESOLVED severity normal in component MQTT-JS for 1.1
Reported in version unspecified on platform PC
Assigned to: Tang Zi Han

On 2014-10-21 15:14:41 -0400, Adrian Solis wrote:

The 'Getting Started' section of the MQTT Javascript sample is incorrect. http://www.eclipse.org/paho/clients/js/

The sample uses Messaging instead of Paho.MQTT in two instances.

Incorrect
client = new Messaging.Client(location.hostname, Number(location.port), "clientId");

message = new Messaging.Message("Hello");

Correct
client = new Paho.MQTT.Client(location.hostname, Number(location.port), "clientId");

message = new Paho.MQTT.Message("Hello");

The sample needs to be updated to reduce the issues faced by new developers being introduced to using MQTT.

On 2014-11-03 12:11:27 -0500, Roger Light wrote:

Thanks Adrian, I've made the changes.

On 2014-11-04 01:30:07 -0500, Tang Zi Han wrote:

It has been fixed in develop branch , you can use develop branch instead.

blank messages are sent but not retained

migrated from Bugzilla #475302
status UNCONFIRMED severity normal in component MQTT-JS for 1.2
Reported in version unspecified on platform All
Assigned to: Ian Craggs

On 2015-08-18 16:47:35 -0400, Alex Krolick wrote:

Using MQTTWS31.js with Node's Mosca MQTT packages.

Sending a blank string as the message payload with retained=true is fine for connected clients, but the messages don't show up if a new client connects and attempts to read the retained messages.

I am not sure if this is an issue with the client, the Mosca broker or a combination.

On 2015-08-18 17:03:55 -0400, Ian Craggs wrote:

So... in the MQTT 3.1.1 specification, sending a QoS 0 zero length message can be a way of removing a retained message.

"If the Server receives a QoS 0 message with the RETAIN flag set to 1 it MUST discard any message previously retained for that topic. It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time - if this happens there will be no retained message for that topic"

Is that a factor?

websockify support (websocket binary protocol)

Test setup
mosquitto broker listening on 1883
websockify websocket to TCP bridge set up to bridge public-ip:9001 to localhost:1883
sample page subscribing to broker via mqttws31.js
What happens
websockify refuses connection from client:
host17-79-dynamic.183-80-r.retail... - - [31/Mar/2016 15:49:20] code 400, message Client must support 'binary' or 'base64' protocol
Solution
I have been able to fix this issue by patching:
this.socket = new WebSocket(wsurl, ["mqttv3.1"]);
to:
this.socket = new WebSocket(wsurl, ["binary"]);
Request
still I think that a proper option could be added to paho.MQTT.Client class to support this scenario, something like:
var options = { binaryMode: true,
or some explicit string option override.

thank you!

Keepalive processing needs two timers

migrated from Bugzilla #442692
status NEW severity normal in component MQTT-JS for 1.1
Reported in version 1.0 on platform PC
Assigned to: Tang Zi Han

On 2014-08-27 07:13:16 -0400, Ian Craggs wrote:

I realized yesterday that the keepalive processing in the C client was not correct. In discussion with Al we realized that two timers are needed, one for keeping track of the last packet sent, the other to keep track of the last packet received.

This is because they are used for two different purposes. The last packet sent timer is used to stop the server closing the session. A ping must be sent within the keepalive interval if no other packet has been sent to the server, to notify it that the client application is still alive.

The last packet received timer is used to determine that the TCP connection is still active. If you pull the network cable out of a machine, TCP writes will still work until the TCP buffer is full. Even then, you only get a buffer full notification (on Linux at least), not a network error. Only when the TCP keepalive timeout kicks in would the client be notified that the network had failed. So, if packet has not been received from the server within a reasonable amount of time (the keepalive time is a good value), then a ping should also be sent. If a response is not received from the server, then the TCP connection can be assumed to have failed, and the "connection lost" processing should be invoked.

This needs to be checked for the Javascript client.

wireMessage.returnCode.indexOf is not a function

migrated from Bugzilla #470096
status RESOLVED severity normal in component MQTT-JS for 1.2
Reported in version unspecified on platform PC
Assigned to: James Sutton

Original attachment names and IDs:

On 2015-06-12 12:38:51 -0400, Karl Palsson wrote:

Seen with firefox 29. Works fine in newer versions of firefox, chromium and friends. Note that the hive mq websockets demo works just fine in firefox 29, and websockets support should be perfectly usable there, indeed, "caniuse.com" says I should have been able to use websockets all the way back to firefox 11.

AMQJS0005E Internal error. Error Message: wireMessage.returnCode.indexOf is not a function, Stack trace: Paho.MQTT</ClientImpl.prototype._handleMessage@http://localhost:8000/resources/paho/mqttws31.js:1302
Paho.MQTT</ClientImpl.prototype._on_socket_message@http://localhost:8000/resources/paho/mqttws31.js:1149
Paho.MQTT</scope/<@http://localhost:8000/resources/paho/mqttws31.js:157
: 5"

On 2015-06-15 07:52:40 -0400, Karl Palsson wrote:

Tested with released 1.0.1 and current git master, v1.0.1-4-g6ee5ef2. Both fail.
Latest develop branch, v1.0.1-7-gb82756f also fails.

On 2015-06-15 08:03:35 -0400, Karl Palsson wrote:

The stack trace only shows line numbers, the problem area is the SUBACK case in _handleMessage,

wireMessage.returnCode.indexOf = Array.prototype.indexOf;

if (wireMessage.returnCode.indexOf(0x80) !== -1) {

On 2015-06-15 09:39:50 -0400, Karl Palsson wrote:

Created attachment 254438
workaround firefox indexOf problem

clearly however, this only works for subacks for a single subscription.

On 2015-06-15 09:42:05 -0400, Karl Palsson wrote:

After looking at this, I feel that the existing code was doing a poor job of correlating return codes with subscriptions anyway. Shouldn't it be sending a failure message only for the subscriptions that failed anyway? not just if there were any failures?

Or is this a sideaffect of the API issues outlined in https://bugs.eclipse.org/bugs/show_bug.cgi?id=440767 anyway?

On 2015-06-15 09:44:53 -0400, Karl Palsson wrote:

Finally, given that you can't actually subscribe to multiple topics in the same call anyway with the current api, the patch proposed is probably perfectly acceptable.

On 2015-06-15 09:49:11 -0400, Ian Craggs wrote:

James, can you take a look at this?

This page:

https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/indexOf

says that the function may not be supported on all browsers. It also gives an alternative implementation, for when the function is not available.

Options:

  1. Ask for (Eclipse) permission to use the code snippet from the page above.
  2. Reimplement without the Array.prototype.indexOf

(We should sort out the subscribing to multiple topics too)

Karl:
I notice there are other calls to indexOf, on other objects. Presumably all other calls to indexOf methods work ok?

On 2015-06-15 10:09:17 -0400, Karl Palsson wrote:

I don't have an extensive test suite, but my own basic usage works with the patch I attached. I can subscribe, send a message, get messages. But I've not done any heavy testing beyond that.

What's strange is that Array.prototype.indexOf exists as a function in this browser. I just can't set any property on the returnCode object. Playing in the console produced this sort of behaviour

wireMessage.xxx = "blah"
wireMessage.xxx
<== "blah"
wireMessage.returnCode.xxx = "blah" (no errors here)
wireMessage.returnCode.xxx
<== undefined.
Array.prototype.indexOf
<== function.....

Doesn't seem to actually be related to the indexOf call. Possibly related to the underlying Uint8Array being readonly somehow?

I think that without any changes for the multi subscription api, https://bugs.eclipse.org/bugs/show_bug.cgi?id=440767 the patch I've attached is just fine. There's only a possibility of a single rc right now anyway.

On 2015-07-21 05:14:08 -0400, James Sutton wrote:

I've implemented the attached fix in change 52241 as that will resolve the issue for now. When we implement multi-topic support for subscribe and unsubscribe, we will need to check that we don't break this again.

JavaScript Client - New Feature Plan : Automatic Reconnect and Disconnected Buffering

Automatic Reconnect and Disconnected Publishing Plan

Currently, the Paho JavaScript client is lacking two major areas of functionality: Automatic Reconnect and Disconnected (or Offline) Publishing.

The goal is to implement these features in time for the next release Neon.

This issue aims to outline the plan for adding this new functionality into the JavaScript client. The design and implementation will be closely matched to the Java client's plan

Recap: Possible Client States

There are 5 main potential states that the client can be in. The User will usually desire the client to either be in the connected or disconnected states.

  • never connected: This is the initial state of the client where:
    • The client has not yet sent a connect request.
    • The client has never received a CONNACK after it's initial connect request.
  • connecting: A connect request is in progress.
  • connected: The client is connected and ready to send and receive messages.
  • disconnecting: A disconnect request is in progress.
  • disconnected: The client goes from connected to disconnected state when:
    • A disconnect request has been completed
    • As a result of a networking error, or the server is no longer reachable.

What does it do?

Automatic Reconnect

Will automatically attempt to reconnect to the broker (or one of the servers in the host list) while the client is in disconnected state.

  • The client will not perform automatic reconnection if it is not in disconnected state.
  • When the connection is lost, the connectionLost callback is called before the client starts the reconnect process. Since the state of the client is disconnected, the application is allowed to call the connect function with new connection options if they wish.
  • When disconnect is called while connected, the client goes to the disconnected state and automatic reconnect is disabled.
  • If the client application calls connect after it had reconnected, an invalid state error will be thrown.
  • The client library does not subscribe for the application after it successfully reconnects. A callback will be provided to notify the application when it has been reconnected allowing it to make any subscriptions to topics itself.

Disconnected Publishing

Will allow the client to save messages in a buffer whilst the client is in the disconnected state.

  • Once the client is reconnected (To the same or different broker), the buffered messages are scheduled to be sent.
  • To maintain order of messages, the client library must send buffered messages before sending new messages.
  • The client library does not save any messages while the client is in the never connected state. So it cannot send any messages before it connects for the first time.
  • When disconnect is called while connected, the client goes to disconnected state and Disconnected Publishing remains active if enabled.

API Changes

Automatic Reconnect

The following optional attributes will be added to the Connection Options object:

  • reconnect : boolean. If present and True, the client will attempt to reconnect
  • reconnectInterval : number. Time interval in seconds between connect attempts. Default: 10 (seconds).

The following new callback will be added:

  • onConnect - called when the connection is established. A response object is passed to the onConnect callback containing the following fields:
    • reconnect - boolean. True if the connection is the result of a reconnect operation
    • uri - string. Fully qualified WebSocket URI of the server

The existing onConnectionLost callback will be changed as follows:

  • onConnectionLost - called when a connection has been lost. A single response object parameter is passed to the onConnectionLost callback containing the following fields:
    • errorCode - number.
    • errorMessage - string.
    • reconnect : boolean. If present and True, the client will perform automatic reconnection while it is disconnected.

Disconnected Publishing

The following optional attributes will be added to the Messaging Client object:

  • disconnectedPublishing : boolean. If present and True, the client will save messages while it is disconnected. This attribute is independent from the reconnect attribute mentioned above. Thus the application can set this flag to buffer messages and try to reconnect at a later time.
  • disconnectedBufferSize : number. The maximum number of messages that will be stored in memory while the client is disconnected. Default : 5000
  • deleteOldestBufferedMessages : boolean. If present and True, the client will delete oldest messages in the buffer to make room for newer messages.
  • persistDisconnectedBuffer : boolean. If present an True, the client will persist the buffered messages.
    • A persistent buffered message is stored by the client until it is deleted by the application or it is sent after the client reconnected.
    • If persistDisconnectedBuffer is not present or False, the client will save messages in memory.
  • bufferedMessages : number. This read-only attribute is the number of buffered messages.

The following methods will be added:

  • getBufferedMessage(index) : Returns the buffered Message object at the index location (0 based)
  • deleteBufferedMessage(index) : Deletes the buffered message at the index location (0 based)

New Error

When the buffer is full and deleteOldestBufferedMessages is not present or False, the following error will be thrown:

  • errorCode : 18
  • errorMessage : AMQJS0018E Message buffer is full, maximum buffer size: ${0}.

Sample application

This application wants to use both Automatic Reconnect and Disconnected Publising. The Application does not want to persist buffered messages.

    var client;
    var host = "iot.eclipse.org";
    var port = 1883;
    var clientId = "sample-id";
    var sentMsgs = 0;

    // This function creates a new Messaging client and initiates a connect request.
    function doConnect() {
        client = new Messaging.Client(server, port, clientId);
        client.onConnected = onConnected;            // Callback when connected
        client.onConnectionLost = onConnectionLost;  // Callback when lost connection
        client.disconnectedPublishing = true;        // Enable disconnected publishing
        client.disconnectedBufferSize = 100;         //  Buffer size : 100

        client.connect(
            {
                cleanSession : false, 
                onSuccess : onConnectSuccess, 
                onFailure : onFailedConnect, 
                keepAliveInterval: 30, 
                reconnect : true,         // Enable automatic reconnect
                reconnectInterval: 10     // Reconnect attempt interval : 10 seconds
            }
        );
    }

    // This function is called when the initial connect request is successful.
    function onConnectSuccess(resObj) {
        console.log("Initial connect request succeeded.");
    }

    // This function is called when the intial connect request failed.
    function onFailedConnect(err) {
        console.log("Initial connect request failed. Error message : " + err.errorMessage); 
    }

    // This function is called for all successful connection
    function onConnected(resObj) {
        console.log("Connected to " + resObj.uri);
        if (resObj.reconnect) {
            console.log("It was a result of automatic reconnect.");
        }
    }

    // This function is called when the connection is lost.
    function onConnectionLost(resObj) {
        console.log("Lost connection to " + resObj.uri + "\nError code: " + resObj.errorCode + "\nError text: " + resObj.errorMessage);
        if (resObj.reconnect) {
            console.log("Automatic reconnect is currently active.");
        } else {
            alert("Lost connection to host.");.
        }
    }

    function doSend() {
        // Starts timer to send a message every second
        publishTimer = setInterval(function () {sendTimer()}, 1000);
    }

    function sendTimer() {
        var message = new Messaging.Message("Test Message " + sentMsgs);
        message.destinationName = "/test/topic1";
        message.qos = 1;
        try {
            client.send(message);
            sentMsgs++;
            if (client.bufferedMessages > 0) {
                console.log("Buffered messages : " + client.bufferedMessages);
            }
        } catch (err) {
            console.log("Error occured after " + sentMsgs + " messages sent. Error : " + err.message);
        }
    }

Add HTML documentation, samples, and downloadable package

migrated from Bugzilla #423940
status RESOLVED severity major in component MQTT-JS for ---
Reported in version unspecified on platform All
Assigned to: Nicholas O'Leary

On 2013-12-12 12:22:00 -0500, Tim Kellogg wrote:

The JavaScript client needs better documentation.

The current documentation needs to be extracted from the source code into HTML & posted online in an easily accessible location. Doing this as part of a build script is ideal.

Online documentation should have samples for several ways to connect - default, authenticated, raised QoS level, etc; publishing and subscribing.

A minified JS file needs to be built and posted online in an easily accessible location.

On 2013-12-12 12:35:17 -0500, Andy Piper wrote:

Agreed that these issues should be addressed, particularly ahead of release plans for 1.0

On 2014-02-01 11:27:49 -0500, Nicholas O'Leary wrote:

*** Bug 420221 has been marked as a duplicate of this bug. ***

On 2014-02-01 11:28:13 -0500, Nicholas O'Leary wrote:

*** Bug 420222 has been marked as a duplicate of this bug. ***

On 2014-02-01 11:30:36 -0500, Nicholas O'Leary wrote:

*** Bug 420223 has been marked as a duplicate of this bug. ***

On 2014-07-03 08:41:49 -0400, Al Stockdill-Mander wrote:

The generated jsDoc is now linked to from the client page on the Paho website.
A link to the production zip including a minified version is also linked to on the client page.

Add support for CommonJS and AMD

migrated from Bugzilla #437204
status UNCONFIRMED severity normal in component MQTT-JS for 0.9
Reported in version future on platform PC
Assigned to: James Sutton

On 2014-06-11 12:13:50 -0400, Tim-Daniel Jacobi wrote:

Rationale for this request is to be able to load the JavaScript client asynchronously as a dependency as it is often required by larger scaled JavaScript projects. This addition would also ease the use of the client in Dojo based projects.

There are three major patterns of using/loading a JavaScript module nowadays.

Attach your module to the global namespace (global in node, window in the browser), this is the current approach:
// define it
MyModule = { // module code };
// use it
MyModule.myMethod();

Define it as a CommonJS module (like all npm modules do):
// define it (mymodule.js)
module.exports = { // module code };
// use it (app.js)
var mymodule = require('./mymodule');
mymodule.myMethod();

Define it as AMD module (for AngularJS, Dojo, ...)
//define it
define(function(){ // module code });
// use it
require(['mymodule'], function(mymodule){
mymodule.myMethod();
});

The JavaScript MQTT client only supports the first pattern at the moment. Having it support all three patterns is as easy as wrapping the current code with the following. This will also ensure backwards compatibility.

(function(name, definition) {
if (typeof module != 'undefined') module.exports = definition();
else if (typeof define == 'function' && typeof define.amd == 'object') define(definition);
else this[name] = definition();
}('Messaging', function() {
// Current code (mqttws31.js lines 84-2011) goes here
}));

Further reading:
AMD: http://dojotoolkit.org/documentation/tutorials/1.9/modules/
CommonJS: http://dailyjs.com/2010/10/18/modules/

On 2015-08-14 06:36:03 -0400, Ian Craggs wrote:

Assigning to James

onMessageArrived called once for multiple messages, accessing payloadString causes UTF8 errors

migrated from Bugzilla #407909
status CLOSED severity major in component MQTT-JS for ---
Reported in version v0.5 on platform PC
Assigned to: Andrew Banks

On 2013-05-13 11:34:06 -0400, Alexander Rust wrote:

Hi,

I just started playing with the Paho-Js client and tried to plug it into the existing code for a home-automation webinterface that is yet based on the mosquitto.js client. The client is set to subscribe to a some topics, for which it receives ~50 retained messages from a Mosquitto broker (v. 1.1.3) after the subscription.

Sometimes the onMessageArrived method is called with one message for which the destination name and payload string are correct.

In this case my code correctly reports
topic:/devices/158212-Socket-11011-00001/controls/Power/meta/type
payload:switch

However, mostly the method ends up being called once for ~30 message with the destination name and payload string messed up totally.

topic:/devices/158212-Socket-11011-00001/meta/name
payload:Aquarium18,/devices/158212-Socket-11011-00001/meta/roomWohnzimmer1&/devices/294028-solar/meta/roomBucks1//devices/294028-solar/meta/nameSolar Position13,/devices/158212-Socket-11011-00010/meta/roomBucks11,/devices/158212-Socket-11011-00010/meta/nameAmp13,/devices/158212-Socket-11011-01000/meta/roomBucks12,/devices/158212-Socket-11011-01000/meta/nameDesk12,/devices/158212-Socket-11011-00100/meta/roomFlur19,/devices/158212-Socket-11011-00100/meta/nameCampusboard1.#/devices/465632-Ambilight/meta/nameAmbilight1*#/devices

I'm not sure whether I'm just wrongly assuming that the onMessageArrived method is called once for each received message or if message.payloadString has some weirdness going on.

In either case, accessing the payloadString often results in parseUTF8 errors:

Uncaught Error: AMQJS0009E Malformed UTF data:90 -7d . paho.js:598
parseUTF8 paho.js:598
_getPayloadString paho.js:1794
payloadString paho.js:1842
mqttSocketonmessage app.js:681
ClientImpl._receiveMessage paho.js:1281
ClientImpl._receivePublish paho.js:1256
ClientImpl._on_socket_message paho.js:1143
(anonymous function) paho.js:150

Additionally, or related to the above isse the string "cleanSession" seems to end up as the payloadString.

Please let me know if there is additional information that I should provide for this issue.

On 2013-05-13 11:54:57 -0400, Andy Piper wrote:

Thanks, hopefully Andrew can respond on expected behaviour of the JS client.

On 2013-05-15 00:55:19 -0400, Simon Racliffe wrote:

Alexander,

I had similar problems, using Mosquitto server, mod_websocket_mosquitto and mod_websocket. I suspect you are using a similar config. If so upgrade your Mosquitto server to the latest at https://bitbucket.org/oojah/mosquitto/downloads. Also mod_websocket_mosquitto is very simplistic and if the group of published messages is greater than 1024 bytes it WILL break.

I have written a patch for mod_websocket_mosquitto whcih properly parse the stream and passes it on correctly. I have post this on the mod_websocket_mosquitto issues pages, but have not yet had feedback from its author. Have a look at willem4ever/mod_websocket_mosquitto#4

Cheers
Simon

On 2013-05-15 06:01:09 -0400, Alexander Rust wrote:

Thanks Simon,

using a freshly compiled version of Mosquitto showed the same issues.
Note, that I'm not using mod_websocket but https://github.com/stylpen/WSS that is written by a good friend of mine.

It's quite simple and solid, but as it was written and tested with the Mosquitto.js library I'll see whether there are some conditions that just worked with the mosquitto library.

On 2013-05-15 08:36:45 -0400, Simon Racliffe wrote:

Alexander,

It still sounds like a similar problem to what I was having where the software that wrapped the MQTT data into the websocket packets wasn't smart enough to deal with the mosquitto server sending a bunch of publish messages in a group.

I was only able to debug the problems I was having using wireshark, and almost blamed the wrong piece of software for the problem. The latest development version of wireshark also does a much better job of decoding the websocket protocol.

Hope something here helps.

Cheers
Simon

On 2013-05-16 11:50:07 -0400, Alexander Rust wrote:

The Websocket server component looks solid, Simon. I also tried it with a patched version of mod_websocket, which showed the same issues.

Additionally, when I think about it, it was able to deal with the same bunch of published messages before, with the other library.

On 2013-05-18 06:33:51 -0400, Andrew Banks wrote:

Alexander, onMessagearrived should get driven once per message.

Could you capture some client side trace, as illustrated below, so that I can see what is being sent to the client to cause it to do what you are seeing?

// Start the client tracing, the trace records capture the method calls and network flows from now on.
client.startTrace();

... generate the problem

window.location="mailto:helpdesk@"+location.hostname+"?Subject=Web%20Messaging%20Utility%20Trace&body="+client.getTraceLog().join("%0A");
client.stopTrace();

On 2013-05-18 07:05:54 -0400, Alexander Rust wrote:

Hi,

I gathered the following traces by starting them in the connect-onSuccess method, right before I subscribe to my topics that contain retained messages.

Trace a) was stopped in try-catch block around console.log(message.payloadString); in the onMessageArrived method where the Error: AMQJS0009E Malformed UTF data:90 -7d was thrown.

Trace b) was stopped two seconds after the subscribe when all retained messages were received from the broker.

Trace a)
Client.startTrace%0A "2013-05-18T11:02:04.279Z"%0A "0.0.0.0"%0AClient.subscribe%0A "/devices/+/controls/+/meta/+"%0A {}%0AClient._socket_send%0A {"type":8,"topics":["/devices/+/controls/+/meta/+"],"requestedQos":[0],"messageIdentifier":1}%0AClient.subscribe%0A "/devices/+/controls/+"%0A {}%0AClient._socket_send%0A {"type":8,"topics":["/devices/+/controls/+"],"requestedQos":[0],"messageIdentifier":2}%0AClient.subscribe%0A "/devices/+/meta/#"%0A {}%0AClient._socket_send%0A {"type":8,"topics":["/devices/+/meta/#"],"requestedQos":[0],"messageIdentifier":3}%0AClient._on_socket_message%0A {"byteLength":5}%0AClient._on_socket_message%0A {"type":9,"messageIdentifier":1,"grantedQos":{"0":0,"length":1,"byteLength":1,"byteOffset":4,"buffer":{"byteLength":5}}}%0AClient._on_socket_message%0A {"byteLength":803}%0AClient._on_socket_message%0A {"type":3,"payloadMessage":{}}%0AClient._on_socket_message%0A {"byteLength":5}%0AClient._on_socket_message%0A {"type":9,"messageIdentifier":2,"grantedQos":{"0":0,"length":1,"byteLength":1,"byteOffset":4,"buffer":{"byteLength":5}}}%0AClient._on_socket_message%0A {"byteLength":1170}%0AClient._on_socket_message%0A {"type":3,"payloadMessage":{}}%0AClient.getTraceLog%0A "2013-05-18T11:02:04.347Z"%0AClient.getTraceLog in flight messages%0A%0A_sentMessages %0A "3"%0A {"type":8,"topics":["/devices/+/meta/#"],"requestedQos":[0],"messageIdentifier":3}

Trace b)
Client.startTrace%0A "2013-05-18T10:44:48.540Z"%0A "0.0.0.0"%0AClient.subscribe%0A "/devices/+/controls/+/meta/+"%0A {}%0AClient._socket_send%0A {"type":8,"topics":["/devices/+/controls/+/meta/+"],"requestedQos":[0],"messageIdentifier":1}%0AClient.subscribe%0A "/devices/+/controls/+"%0A {}%0AClient._socket_send%0A {"type":8,"topics":["/devices/+/controls/+"],"requestedQos":[0],"messageIdentifier":2}%0AClient.subscribe%0A "/devices/+/meta/#"%0A {}%0AClient._socket_send%0A {"type":8,"topics":["/devices/+/meta/#"],"requestedQos":[0],"messageIdentifier":3}%0AClient._on_socket_message%0A {"byteLength":5}%0AClient._on_socket_message%0A {"type":9,"messageIdentifier":1,"grantedQos":{"0":0,"length":1,"byteLength":1,"byteOffset":4,"buffer":{"byteLength":5}}}%0AClient._on_socket_message%0A {"byteLength":803}%0AClient._on_socket_message%0A {"type":3,"payloadMessage":{}}%0AClient._on_socket_message%0A {"byteLength":555}%0AClient._on_socket_message%0A {"type":9,"messageIdentifier":2,"grantedQos":{"0":0,"1":49,"2":52,"3":0,"4":49,"5":47,"6":100,"7":101,"8":118,"9":105,"10":99,"11":101,"12":115,"13":47,"14":49,"15":53,"16":56,"17":50,"18":49,"19":50,"20":45,"21":83,"22":111,"23":99,"24":107,"25":101,"26":116,"27":45,"28":49,"29":49,"30":48,"31":49,"32":49,"33":45,"34":48,"35":48,"36":48,"37":48,"38":49,"39":47,"40":99,"41":111,"42":110,"43":116,"44":114,"45":111,"46":108,"47":115,"48":47,"49":80,"50":111,"51":119,"52":101,"53":114,"54":48,"55":49,"56":44,"57":0,"58":37,"59"...101,"476":115,"477":47,"478":49,"479":53,"480":56,"481":50,"482":49,"483":50,"484":45,"485":83,"486":111,"487":99,"488":107,"489":101,"490":116,"491":45,"492":49,"493":49,"494":48,"495":49,"496":49,"497":45,"498":48,"499":48,"500":49,"501":48,"502":48,"503":47,"504":109,"505":101,"506":116,"507":97,"508":47,"509":110,"510":97,"511":109,"512":101,"513":67,"514":97,"515":109,"516":112,"517":117,"518":115,"519":98,"520":111,"521":97,"522":114,"523":100,"524":49,"525":46,"526":0,"527":35,"528":47,"529":100,"530":101,"531":118,"532":105,"533":99,"534":101,"535":115,"536":47,"537":52,"538":54,"539":53,"540":54,"541":51,"542":50,"543":45,"544":65,"545":109,"546":98,"547":105,"548":108,"549":105,"550":103,"551":104,"552":116,"553":47,"554":109,"555":101,"556":116,"557":97,"558":47,"559":110,"560":97,"561":109,"562":101,"563":65,"564":109,"565":98,"566":105,"567":108,"568":105,"569":103,"570":104,"571":116,"572":49,"573":42,"574":0,"575":35,"576":47,"577":100,"578":101,"579":118,"580":105,"581":99,"582":101,"583":115,"584":47,"585":52,"586":54,"587":53,"588":54,"589":51,"590":50,"591":45,"592":65,"593":109,"594":98,"595":105,"596":108,"597":105,"598":103,"599":104,"600":116,"601":47,"602":109,"603":101,"604":116,"605":97,"606":47,"607":114,"608":111,"609":111,"610":109,"611":66,"612":117,"613":99,"614":107,"615":115,"length":616,"byteLength":616,"byteOffset":4,"buffer":{"byteLength":620}}}%0AClient.getTraceLog%0A "2013-05-18T10:44:50.542Z"%0AClient.getTraceLog in flight messages%0A

On 2013-05-20 06:02:45 -0400, Andrew Banks wrote:

Alexander, trace b) shows that the server is packing multiple MQTT command messages into a Websocket frame, the client assumes the server is sending it one MQTT message per frame. Your UTF-8 conversion error has probably come about because the following message has been joined on to the publication message. There is an Oasis is discussing whether WebSockets should carry multiple or partial MQTT messages in each frame.

https://tools.oasis-open.org/issues/browse/MQTT-1

On 2013-05-25 06:38:19 -0400, Alexander Rust wrote:

Thanks Andrew,

the Mosquitto library was perfectly happy with that kind of behavior. We modified our Websocket bridge accordingly to just send one MQTT message per Websocket frame which did fix all errors reported previously.

I think this can be closed now, thanks for your help.

MQTT 3.1.1 support for the JavaScript client

migrated from Bugzilla #436052
status RESOLVED severity normal in component MQTT-JS for 1.0
Reported in version 1.0 on platform PC
Assigned to: Al Stockdill-Mander

On 2014-05-28 09:06:34 -0400, Ian Craggs wrote:

Make the client conform to the 3.1.1 spec: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cs01/mqtt-v3.1.1-cs01.html

Should connect at 3.1.1 first, and fall back to 3.1 if that fails.

On 2014-06-12 05:22:19 -0400, Ian Craggs wrote:

Code added by Al. Now need to add tests.

On 2014-06-26 06:10:17 -0400, Al Stockdill-Mander wrote:

Code is in, tested and packages are uploaded and available

Sec-WebSocket-Protocol mismatch with Chrome 30.x

migrated from Bugzilla #419927
status RESOLVED severity major in component MQTT-JS for ---
Reported in version v0.5 on platform PC
Assigned to: Andrew Banks

On 2013-10-20 08:51:08 -0400, Alexander Rust wrote:

Since updating to Chrome 30.0.1599.101 my PahoJS Websocket connection throws the following error

WebSocket connection to 'ws://testhost:18883/mqtt' failed: Error during WebSocket handshake: Sec-WebSocket-Protocol mismatch

For me, this can be fixed by replacing this.socket = new WebSocket(wsurl, 'mqttv3.1') with this.socket = new WebSocket(wsurl);

On 2013-10-21 11:26:16 -0400, Andrew Banks wrote:

The problem is in the server end.
If your server is MQSeries you need a patch for
APAR IC96616 to resolve the problem.

Minified Javascript client

migrated from Bugzilla #420222
status CLOSED severity normal in component MQTT-JS for ---
Reported in version v0.5 on platform All
Assigned to: Andrew Banks

On 2013-10-23 16:58:46 -0400, Obermaier Dominik wrote:

To save bandwidth, Javascript libraries are typically included as minified versions on production websites. Paho doesn't have minified version for download yet, so it should be considered to prepare one for download. A good place for the download would be the main pages download section :-)

On 2014-02-01 11:28:13 -0500, Nicholas O'Leary wrote:

Tidying up the backlog - there is a catch-all bug for doc/download/website improvements - # 423940

*** This bug has been marked as a duplicate of bug 423940 ***

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.