-
Thanks! Available memory and size is the next thing that I want to focus on.
Good question about QoS1! So does TCP/IP quarantee that all packets are delivered at least once? I am not an expert on that field... And could the MQTT client miss packets if it is too busy at a certain point of time? Actually it might make sense to track the DUP flag, just to to be sure.
I am not sure about your remark about staying connected. In the end the client will have to sent a Connect packet again, not?
Gordon, about the new module, you're helping me more than enough with your comments. Helps me to think things trough. If TypeScript compilation is an issue than I can also consider to add the compiled/minified JavaScript to GitHub. Or mabe we can add an extra step to the TravisCI build? Whatever works best.
You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
Rovale
@Gordon
Nice, the last will really doesn't take much! I wonder whether subscribing wasn't really used/tested? I guess most people have been using MQTT just to push data - I know that's all I did for the initial proof of concept, and as you note, the message parsing looks extremely rough around the edges.
Hopefully fixes for what you suggested wouldn't be too hard though...
To check available memory, just upload and type
process.memory()-.usageis what you're interested in. Check out http://www.espruino.com/Performance for some info on getting code that works well - one of the biggest things is making sure that code minifies well - which is why the MQTT lib uses private functions where it can.I'm afraid I really don't have time to help out with a new module though. If you did want to contribute this as a new module, the fact that it's in TypeScript makes life quite difficult - I guess TypeScript compilation (and all its dependencies) would need adding to the build process, just for this one module.
I'm surprised about the need for QoS1 - surely TCP/IP handles all that for you?
In terms of staying connected, that might be better as a separate module? Ideally an MQTT lib would be capable of running over any connection type, so if possible you probably won't want transport-specific code in there.