I decided that dealing with an unexpected unsubscribe request was probably something that my broker should be able to handle
So I'm just leaving the Snap! end alone as all other brokers I've used it with can handle unsubs where no sub exists
I decided that dealing with an unexpected unsubscribe request was probably something that my broker should be able to handle
So I'm just leaving the Snap! end alone as all other brokers I've used it with can handle unsubs where no sub exists
In other news - I'm well chuffed that despite my NR instance failing overnight - when I restarted it - an existing MQTT session between it and my local running Snap! project just carried on working
It may become a real Aedes rival for a pop-up broker
I can now deal with messages > 127 chars having implemented (Found some JS code to do it and re-did in blockly) a function to cope with the unique MQTT variable length value
FYI This was my transcoding of a JS snippet found on github
function decode(bytes = []) {
let multiplier = 1;
let value = 0;
let currentIndex = 0;
let encodedByte;
do {
encodedByte = bytes[currentIndex];
value += (encodedByte & 127) * multiplier;
multiplier *= 128;
if (multiplier > 128 * 128 * 128) {
throw new Error('Malformed Remaining Length');
}
currentIndex++;
} while ((bytes[currentIndex] !== undefined && (encodedByte & 128 !== 0)))
return value;
}