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

Feature request: RESP3 protocol support #156

Open
matobet opened this issue Oct 28, 2020 · 8 comments
Open

Feature request: RESP3 protocol support #156

matobet opened this issue Oct 28, 2020 · 8 comments

Comments

@matobet
Copy link
Contributor

matobet commented Oct 28, 2020

Are there any plans to support the new RESP3 protocol introduced in Redis 6?

Supporting it (along with its PUSH messages) would be helpful in supporting the Server-assisted client side caching in the future.

@k-bx
Copy link
Collaborator

k-bx commented Oct 29, 2020

@matobet would you care enough to work on it? ;)

@matobet
Copy link
Contributor Author

matobet commented Oct 29, 2020

I suppose with the proper guidance I could give it a shot 😅

@k-bx
Copy link
Collaborator

k-bx commented Oct 30, 2020

Sure, feel free to ask for help or a review, happy to assist!

@aravindgopall
Copy link
Collaborator

Hi @matobet, have you got any chance to work on this?

@matobet
Copy link
Contributor Author

matobet commented Mar 16, 2023

@aravindgopall unfortunately no :-(

@414owen
Copy link

414owen commented Jan 21, 2024

I wrote a RESP3 parser here: https://github.com/414owen/resp

RESP3 adds quite a lot of new syntactic forms, but it's still possible to parse it without backtracking.

It should be complete, but tomorrow I'll double-check the spec, write a few more property tests, and upload it to hackage.

@414owen
Copy link

414owen commented Jan 26, 2024

I have a branch of hedis that uses the RESP3 protocol here. It passes all the tests, apart from one of the protocol pipelining ones.

I'm not yet convinced that it's possible to do automatic pipelining with a pub/sub connection, but I need to think about it a bit more.

The changeset is here. If anyone can figure out an easy way to do it, let me know. At the moment I'm considering splitting the connection into pipelined, and not pipelined (for pub/sub use).

@414owen
Copy link

414owen commented Jan 27, 2024

Yeah the pub/sub listener needs to inspect messages constantly, to know if they're a push message. This means we don't get pipelining.

One way around that is to have a connection type specifically for pub.sub with commands. This would amount to one pipelined connection, and one not. It could be fairly transparent to the user, which is nice.

I think that splitting the connection up (again, there's already the clustered one), really necessitates fixing this issue and parameterizing operations over the connection types they can run on.

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

4 participants