I've got there 
It will let a single client connect.
If the client sends a subscribe message, the topic is stored in global context.
If it then receives a publish message (from the same client at the moment) it checks topic against stored topic. If matches, then the messsage is published back to the client.
Next step will be to try and cope with two clients and have one do the subscribing and the other do the publishing
26Oct 10:00 - set up a testing flow on my 2nd client and glad to see that it can connect/subscribe/publish to and from my homemade broker Now for the tricky part !
3 Likes
Technical question
So I have a TCP in node listening on port 2883 and an out node set in reply mode
All good, all works with just a single client
But with two clients, I'm assuming I'll need to store some reference as to which client I want to send a message back to
So a typical incoming message
has the extra properties of ip, port and session
I'm hoping, that by storing them and then adding them back into my sent messages back to the clients then NR will auto magically route it to the right client?
But if true (which I hope it is!) do I need to include all of them or will just say the ip and port be needed?
[post edited slighlty]
Hi @cymplecy
Only the _session object is needed.
1 Like
Ta - I'll try storing that along with the subscribed topic and see what I can do with it
1 Like
The _session object holds the id to a client connection inside an internal collection of connected clients.
2 Likes
Reached the stage of multiple clients and multiple subscribtions so I think we can say I've sucessfully made a simple Qos0/clean session broker in NR itself
Try it out if you want - the injects on the left let you connect/subscribe/unsubscribe/disconnect and a bit further down - publish
uh oh - I forgot how much bloat Blocky nodes add
I'll upload it somewhere
Now you will need to install the Blockly node to try it out - I can't be bothered converting them to pure functions
Apart from that - all core nodes
Here is it is
1 Like
Very nice @cymplecy
This was fun / a pleasure to follow.
I think this exercise actually broadens creativity into achieving more replications of a protocol in Node RED - all in a visual manner mind you
I've wrote a client once in GP - a block programming language - so it wasn't my first rodeo in dealing with the protocol at the byte packet level
2 Likes
Not related, but packet related all the same.
A few years ago, I built a screen sharing application (.NET) that used an rfb approach to sending changes to the...well.... Remote Frame Buffer, it was great fun.
We used it in our corporate mobile devices for some time to help out field engineers, and of course to remove the need to subscribe to hosted services.
Things have obviously changed since then - but it got me more into protocol level investigation - it was great fun, and still enjoy it from time2time
2 Likes
You see that you've triggered me again! Some years ago I ended up writing a software system that BT had failed to deliver after a £1m spend, I wrote a stand-in using formatted Excel spreadsheets, email and a PHP service (no Node.js back then!). The spreadsheets had built-in lookups to PHP API's delivering reference data to help the people filling them in be less stupid. But more to the point, I realised that the PHP IMAP library was pants and wasn't working properly against the Exchange server. So I had to write my own - though admittedly, I did have a bit of help on that part, but my excuse is that even back then, I'd not been a programmer for quite a few years.
Anyway, it all worked OK for the extra 12 months it took BT to deliver a working system. 
1 Like
I wonder what the easiest thing would be to do with it now?
Handle wildcard subscriptions is the one that's coming up in my mind first
I am contemplating opening up 2883 on my router and redirecting it to the machine it's running on and sending my ip by DM to for people here to try it out
I can't see any real security issue but just seeing what @TotallyInformation thinks about that
Nothing else on my router is open to incoming requests
Well, personally, I wouldn't expose a device I wanted to actually use like that. But if you have a spare Pi, it should be OK as long as you change any default id's and passwords. If I were in a particularly paranoid mood, I might put it on an isolated network segment.
Given the recent issues a few people have had, I wouldn't be surprised if there were a hacker lurking in the forum.
2 Likes
I've got a handy VM (all my Pi use default user/passwords 
) that I'll setup and expose for a few hours tomorrow
1 Like
Got it to handle simple xxx/# type wildcard subscriptions
Question is... is this MQTTv5 Compliant 
Great work @cymplecy
It not even MQTTv1 compliant
4 Likes
It's actually proved to be useful!
I've added in websocket nodes which means I can talk to it from a local Snap! install
And I noticed that I was getting an unsubscribe request before each subscribe request
Since I maintain the Snap! MQTT extension - I went and looked and sure enough - it trys to unsubscribe before subscribing
Like I say - I maintain this code but was not the original author (i'm just a JS monkey see/monkey do person)
I imagine it was just used for early debugging but I'll just need to check with original author if there's a deeper significance to behaving in this manner before removing it
Depends if a) you allow changing the topic or broker. Or b) don’t close connection on close (or equivalent ). If so you may need to clean up before you connect to the new one.
