Hi Pavel, Let me add my 5 cents.
1. It would be great if both Handshake request & response have some "magic" number (2 or 4 bytes) inside their msg body. That will simplify handling situations when non-Ignite client connects to Ignite server and vice versa. 2. It makes sense to add server version to successful Handshake response as well. It will help to understand & debug possible backward compatibility issues in the field by *.pcap logs analysis & etc. 3. Can we have a more strict header for all message types? As far as I understand, Handshake request has: 1) length - 4 byte 2) Handshake code - 1 byte 3) body - (length - 1) bytes while OP_CACHE_GET request has: 1) length - 4 byte 2) OP_CACHE_GET code - 2 bytes 3) request id - 4 bytes 4) body - (length - 2 - 4) bytes Why some messages have Operation code with 1 byte while others - 2 bytes? Why some requests/responses have request-id while others don't? Let's simplify parser work ) 4. The same comments for success flag (1 byte) and status code (4 bytes) in responses. Let's leave only status code. Thank you, Alexey From: Pavel Tupitsyn Sent: Wednesday, November 22, 2017 4:04 PM To: dev@ignite.apache.org Subject: Thin Client Protocol documentation Igniters, I've put together a detailed description of our Thin Client protocol in form of IEP on wiki: https://cwiki.apache.org/confluence/display/IGNITE/IEP-9+Thin+Client+Protocol To clarify: - Protocol implementation is in master (see ClientMessageParser class) - Protocol has not been released yet, so we are free to change anything - Protocol is only used by .NET Thin Client for now, but is supposed to be used from other languages by third party contributors - More operations will be added in future, this is a first set of them, cache-related Please review the document and let me know your thoughts. Is there anything missing or wrong? We should make sure that the foundation is solid and extensible. Thanks, Pavel
