You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: