We moved to Redis.io!

Under "Bulk Commands" section: it is unclear how the last argument is parsed. What happens to characters following the number of bytes argument? In particular the CRLF pair and any non-numeric characters. What happens if there are characters following the number specified and the terminal CRLF?

Under "Bulk Commands" section: change "This specify the number of DATA bytes that will follow (note that even this bytes are terminated by two additional bytes of CRLF)." to "This specifies the number of DATA bytes that will follow. Note: a CRLF must follow the data bytes."

Under "Bulk Replies" section: The comment about what a library should or should not return is not appropriate for a protocol specification. The protocol specification should describe the form of the replies. Return values from a library routing is an implementation issue.

An argument can be made that a bulk reply of "-<something>" should be returned if the item(s) were not found. However, errors don't seem to be well documented here.

Pipelineing

If the command from the client doesn't include its own length, nothing provides that the whole command will be read by a single read() on the server side.

Ok, understood. Pipelining is only a performance booster, commands from other clients can be inserted from the server's point of view!

This protocol not useful, because per line reading can be very long. Also sets is very necessary thing, but on 1000 elements it's very slowly. Thank for you work.

What happens if the length for a multi-bulk reply is 0. I assume the client library should not need to read anything?

This protocol doesn't seem to address at all issues of binary vs. text data or character sets... what if I want to send/return large Unicode strings, for example... or is the protocol just limited to what the backend database supports?

Can MULTI-BULK result start with:

*-1

I noticed that currently if I request data from a list that doesn't exist, i.e. "LRANGE inexistent 0 3" I get:

*0

A direct client implementation would translate this into an empty array. I was wondering if it wouldn't be better to return -1 instead, so that clients can return NULL. Not sure existing clients are prepared for this though, but mine is. :-)

The Multi bulk commands section has an example that says that 8 bytes will follow, but 'myvalue' only has 7 bytes.

Connecting to 192.168.0.20:6379... Connection established. Escape character is '^@]'. hmset redis_dic aa aa bb bb cc cc

+OK hmget redis_dic aa bb cc

3 $2 aa $2 bb $-1

why?

shianli: because HMSET is a bulk command. The best thing is using the new protocol btw:

*4
$5
HMSET
$2
aa
$2
bb
$2
cc

Connecting to 192.168.0.20:6379... Connection established. Escape character is '^@]'. flushall +OK

4 $5 hmset $3 dic $2 aa $2 bb +OK keys 1 $3 dic hkeys dic 1 $2 aa antirez:This protocol can not , because the last set of data lost

Connecting to 192.168.0.20:6379... Connection established. Escape character is '^@]'. keys 0 lpush redis_list_aa aa

:1 lpush redis_list_aa bb

:2 lpush redis_list_aa cc

:3 keys 1 $13 redis_list_aa lindex redis_list_aa 1 $0 why?

@shianli.88 sorry your problems are trivially fixable carefully reading this page, obviously you need a byte count as last argument for a bulk command. Please check this page and a simple implementation of a Redis client to gain more information about how to talk the wire protocol.

Regards, Salvatore

I am using Redis version 2.0.3 with Jedis version 1.3.1 and Jedis comes back with an exception saying that there was an Unknown reply : '^@' received from Redis. I understand that an older version of Protocol does return this but any thoughts on why I might be getting this from Redis 2.0.3 ? Thanks !