Vishnu Reddy
Vishnu Reddy
The way `sendPacket` handles `writeToStream` return values is built on a number of false assumptions
This code (the way `sendPacket` handles `writeToStream` return values) is built on a number of false assumptions: 1. It assumes that `writeToStream` will only return `false` if the packet was...
For `write()`, we could potentially get stuck at line 11 if the stream is destroyed before the `drain` is emitted: https://github.com/moscajs/aedes/blob/e3e50ded602e7d69bdf8ba15ee07ce3527e004f1/lib/write.js#L5-L22 To solve this problem there is this hack in...
Looks like v8.0.0 is not published on NPM yet, could it be pushed out? EDIT: It's actually on NPM under the 'next' tag. Any reason why it can't put under...
Based on my cursory glance, it looks like specifying a subscription identifier is not supported for the SUBSCRIBE packet. At the very least, it's not part of the `ISubscribePacket` type...
MQTT 5 allows for a password to be set in the CONNECT packet without providing a username. However, it seems like this client does not support this. Would be nice...
Unfortunately, I don't have the cycles to continue working on this rewrite. As a result, my colleagues and I have decided to put this development on hold. I'm writing this...
From the MQTT spec: "Clients typically wait for a CONNACK Packet, However, if the Client exploits its freedom to send Control Packets before it receives a CONNACK, it might simplify...
Have some doubts on what we should name things in ConnectOptions. Making an issue here to track this. - `protocolVersion` or `protocolLevel`? Code currently uses `protocolVersion`, but MQTT spec uses...
Should the sequencer continue to have a write function, or should it emit packets so the upper level client can handle the write?
Currently, it appears that if the client sends a `CONNECT` packet using MQTT 5 extended authentication (i.e., it sets the Authentication Method) and it receives an `AUTH` packet from the...