Separate protocol from client
Dmcz opened this issue · 5 comments
I suggest separating the protocol into its own standalone repository because the client can be implemented in various ways, but the protocol parsing remains consistent and exclusively relies on binary string interpretation.
That is already the case if you look at the
If you have concrete changes in mind, I'm open to discuss them though.
What I mean is creating a dedicated repository for the protocol. Because protocols can be used to implement different clients or server.
For example, you can use php sockets to implement an mqtt client like this repository, or I can use coroutine to implement another client, but these clients can share the same protocol package.
And I recommend defining packet classes such as Connect, Connack, Publish, Puback, aligning with the corresponding MQTT protocol packets. Additionally, consider naming the protocol classes using versions like V3, V4, V5. These protocol classes should handle packing packet class into binary strings and unpacking received strings into packet class. This can more enhance consistency with the MQTT protocol.
For example, you can use php sockets to implement an mqtt client like this repository, or I can use coroutine to implement another client, but these clients can share the same protocol package.
You can use the loopOnce() method to integrate the client with other event loops or coroutines.
However, implementing a WebSocket based client would be a good argument to move the protocol to its own package. At least if you don't want it be integrated in the current client.
And I recommend defining packet classes such as
Connect,Connack,Publish,Puback, aligning with the corresponding MQTT protocol packets. Additionally, consider naming the protocol classes using versions likeV3,V4,V5. These protocol classes should handle packing packet class into binary strings and unpacking received strings into packet class. This can more enhance consistency with the MQTT protocol.
I've thought about this before, but there are two things I'm not so happy about:
- A class should either be responsible for de-/serializing data or for storing data (DTO), not both.
- Wrapping messages in objects costs both cpu and memory, which might not be desirable in high-traffic scenarios. Since PHP is mostly single threaded, scaling the MQTT subscribers is already a challenge and reducing throughput is not going to solve this.
The hard part about all of this is not publishing messages (i.e. the serialization), but the deserialization of data and addressing the correct handlers. What you suggest is basically a rewrite of most parts of the client. And I don't think I have the time and motivation to do this right now. Which doesn't mean I won't consider contributions though. If you want to give it a shot, I'm also ok at looking at a draft with one or two implemented messages as proof of concept.
I'll try it, thanks for your reply.