Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full duplex communication between client and server #28

Open
brunexgeek opened this issue Dec 2, 2024 · 0 comments
Open

Full duplex communication between client and server #28

brunexgeek opened this issue Dec 2, 2024 · 0 comments

Comments

@brunexgeek
Copy link

brunexgeek commented Dec 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant