soypat
commented
1 year ago Hey again! Fixing this is high on my priority list this week. I'm thinking of breaking the Client API to reach a much better usage pattern- how would you feel about this?
My reasons for this change are because I wrote this library before learning about the connection state pattern which I feel would make the library more robust and easier to use concurrently like you say.
Basically this would allow you to call ping asynchronously without worrying about the race condition which would be taken care by the connection state type. I've started work on the ~dev~ client-rewrite branch
brutella
My MQTT client is using this library to abstract the communication with a broker. At first this library looks pretty straight forward to use, but I do find it hard to use with go routines.
Why go routines? Some parts of the MQTT protocol requires you to read and write simultaneously. For example once you are connected to a broker, you have to send a
Pingmessage after n seconds to keep the connection alive. But also when you're subscribed to a topic, you have to keep reading from the connection usingReadNextPacket(). This means you have to use a go routine to either send or receive messages.The problem is that when you call
Ping()on a different go routine, you will get a data race – thePing()implementation callsReadNextPacket(). Within this method theLastReceivedHeaderfield is written – you get a data race because this field is written on 2 different go routines.Any ideas on how to avoid that?