Protocol specification.

[kafkiansky]

Is there an existing proposal for this?

• I have searched the existing proposals

Is your feature request related to a problem?

I want to implement a client to your broker.

Describe the solution you'd like

Will there be a protocol specification added?

Alternatives you considered

No response

[willhoy]

+1
Until there's something better you'd have to derive it from the bmqp module dox and the control message schema: https://github.com/bloomberg/blazingmq/blob/93e6426d474a4293d38244a9ada6dc8cbafe5711/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd

https://github.com/bloomberg/blazingmq/blob/93e6426d474a4293d38244a9ada6dc8cbafe5711/src/groups/bmq/bmqp/bmqp_protocol.h

These give you a good sense of the structure of the messages, but less so whats a valid response to a particular communication to the broker.

[quarter-note]

Hi @kafkiansky, thanks for your interest in the product! What @willhoy has pointed out are basically the two files which capture the wire protocol containing low level structs and control messages (encoded requests/responses).

However, these files don't explain the order of exchange of these structs/messages/requests/responses, as well as any contract between client and broker around that exchange.

We have not documented this yet. However, we have a sample producer and consumer implementation which does not use client library. Instead, it simply uses socket APIs to connect/read/write to the broker and sends/receives messages to/from the broker.
For example, one can see that after connecting to the broker, client library sends NegotiationMessage as the first message (see comment Step 3. Send the negotiation message to the Broker in the producer file), etc.

While this is not a formal spec, it should be enough to get you started to have a rudimentary working prototype.

I would also like to add that in order to provide a good experience, the C++ and Java client libraries are quite stateful. Asychronous nature of the APIs also adds complexity in the implementation. Generally speaking, implementing a batteries-included library is a non-trivial effort. However, we are happy to help you out if you decide to implement one.

Out of curiosity, what language do you have in mind for the client library?

[kafkiansky]

Hi, @quarter-note. Thanks for the explanation. I would like to implement the libraries in rust, go and php. I will try to use the information from those files you gave, or will watch tcpdump as a last resort.

[quarter-note]

Ok great, I will try to write a high level overview of the message flow and some other relevant details.

[kafkiansky]

Thank you so much for your help.

[quarter-note]

Hi @kafkiansky Just wanted to mention that we have started working on documenting the protocol. It's WIP but it can be found here. Hoping to wrap it up in the coming weeks.

[kafkiansky]

Hi, @quarter-note. Great, thank you. I've already started reverse-engineering your protocol using a Java library, but it would be much easier with a formal specification.

[quarter-note]

Hi @kafkiansky I have added some more details in the document. It's still WIP, but you may find newly added info useful.

[kafkiansky]

Hi @quarter-note. Yes, I am following the changes and going to continue development this weekend. Thank you for your work!

[kafkiansky]

@quarter-note, I didn't see any information about what order you write the bytes in: little endian or big endian?