Description
According to the documentation, RESP supports pipelining, but this requires that responses are sent back to the client in the same order as its requests. I'm wondering if we could change the protocol to allow out-of-order responses and achieve full duplex communication. This could be useful to further reduce the number of connections (even compared to pipelining), since we could use it with blocking commands with no penalties.
One possibility is to introduce a prefix to the array used to encode commands. This prefix would include an integer ID to identify the message and this ID would need to be unique only within the same connection. For simplicity, we could assume that it always increments until it reaches a certain limit and overflows to zero again.
In the following hypothetical example, we prefix the command with an integer-like value (with "@" as first byte) to encode the ID.
Message without ID: *3\r\n$5\r\nLPUSH\r\n$5\r\nmykey\r\n$5\r\nhello\r\n
Message with ID 12: @12\r\n*3\r\n$5\r\nLPUSH\r\n$5\r\nmykey\r\n$5\r\nhello\r\n
The response would include the same ID so the client could associate it with the corresponding request.
This extension would be optional and could be enabled in the client handshake.