Ability of slave to announce arbitrary ip/port to master.

This feature is useful, especially in deployments using Sentinel in
order to setup Redis HA, where the slave is executed with NAT or port
fo

Ability of slave to announce arbitrary ip/port to master.

This feature is useful, especially in deployments using Sentinel in
order to setup Redis HA, where the slave is executed with NAT or port
forwarding, so that the auto-detected port/ip addresses, as listed in
the "INFO replication" output of the master, or as provided by the
"ROLE" command, don't match the real addresses at which the slave is
reachable for connections.

show more ...

CLIENT error message was out of date

networking.c minor optimization

additional fix to issue #2948

addReplyHumanLongDouble() API added.

Send a long double or double as a bulk reply, in a human friendly
format.

Removes an extra space in protected mode message

Another typo in protected mode error message.

Fix protected mode error message typo.

New security feature: Redis protected mode.

An exposed Redis instance on the internet can be cause of serious
issues. Since Redis, by default, binds to all the interfaces, it is easy
to forget an in

New security feature: Redis protected mode.

An exposed Redis instance on the internet can be cause of serious
issues. Since Redis, by default, binds to all the interfaces, it is easy
to forget an instance without any protection layer, for error.

Protected mode try to address this feature in a soft way, providing a
layer of protection, but giving clues to Redis users about why the
server is not accepting connections.

When protected mode is enabeld (the default), and if there are no
minumum hints about the fact the server is properly configured (no
"bind" directive is used in order to restrict the server to certain
interfaces, nor a password is set), clients connecting from external
intefaces are refused with an error explaining what to do in order to
fix the issue.

Clients connecting from the IPv4 and IPv6 lookback interfaces are still
accepted normally, similarly Unix domain socket connections are not
restricted in any way.

show more ...

Fix typo in prepareClientToWrite() comment.

MIGRATE: fix replies processing and argument rewriting.

We need to process replies after errors in order to delete keys
successfully transferred. Also argument rewriting was fixed since
it was broke

MIGRATE: fix replies processing and argument rewriting.

We need to process replies after errors in order to delete keys
successfully transferred. Also argument rewriting was fixed since
it was broken in several ways. Now a fresh argument vector is created
and set if we are acknowledged of at least one key.

show more ...

Pipelined multiple keys MIGRATE.

unlinkClient(): clear flags according to ops performed.

Best effort flush of slave buffers before SHUTDOWN.

Use clientHasPendingReplies() in flushSlavesOutputBuffers()

The old version only flushed data to slaves if there were strings
pending in the client->reply list. Now also static buffers are flushed.

Use clientHasPendingReplies() in flushSlavesOutputBuffers()

The old version only flushed data to slaves if there were strings
pending in the client->reply list. Now also static buffers are flushed.
Does not help to free memory (which is the only use we have right now in
the fuction), but is more correct conceptually, and may be used in
other contexts.

show more ...

CLIENT REPLY command implemented: ON, OFF and SKIP modes.

Sometimes it can be useful for clients to completely disable replies
from the Redis server. For example when the client sends fire and forge

CLIENT REPLY command implemented: ON, OFF and SKIP modes.

Sometimes it can be useful for clients to completely disable replies
from the Redis server. For example when the client sends fire and forget
commands or performs a mass loading of data, or in caching contexts
where new data is streamed constantly. In such contexts to use server
time and bandwidth in order to send back replies to clients, which are
going to be ignored, is a shame.

Multiple mechanisms are possible to implement such a feature. For
example it could be a feature of MULTI/EXEC, or a command prefix
such as "NOREPLY SADD myset foo", or a different mechanism that allows
to switch on/off requests using the CLIENT command.

The MULTI/EXEC approach has the problem that transactions are not
strictly part of the no-reply semantics, and if we want to insert a lot
of data in a bulk way, creating a huge MULTI/EXEC transaction in the
server memory is bad.

The prefix is the best in this specific use case since it does not allow
desynchronizations, and is pretty clear semantically. However Redis
internals and client libraries are not prepared to handle this
currently.

So the implementation uses the CLIENT command, providing a new REPLY
subcommand with three options:

CLIENT REPLY OFF disables the replies, and does not reply itself.
CLIENT REPLY ON re-enables the replies, replying +OK.
CLIENT REPLY SKIP only discards the reply of the next command, and
like OFF does not reply anything itself.

The reason to add the SKIP command is that it allows to have an easy
way to send conceptually "single" commands that don't need a reply
as the sum of two pipelined commands:

CLIENT REPLY SKIP
SET key value

Note that CLIENT REPLY ON replies with +OK so it should be used when
sending multiple commands that don't need a reply. However since it
replies with +OK the client can check that the connection is still
active and all the previous commands were received.

This is currently just into Redis "unstable" so the proposal can be
modified or abandoned based on users inputs.

show more ...

Call writeToClient() directly instead of the write handler.

Fix processEventsWhileBlocked() to handle PENDING_WRITE clients.

After the introduction of the list with clients with pending writes, to
process clients incrementally outside of the event loop we al

Fix processEventsWhileBlocked() to handle PENDING_WRITE clients.

After the introduction of the list with clients with pending writes, to
process clients incrementally outside of the event loop we also need to
process the pending writes list.

show more ...

Refactoring: unlinkClient() added to lower freeClient() complexity.

Refactoring: new function to test if client has pending output.

Reverse list of clients with pending writes.

May potentially improve locality... not exactly clear if this makes a
difference or not. But for sure is harmless.

writeToClient(): don't remove write handler if not needed.

handleClientsWithPendingWrites(): detect dead clients.

Move handleClientsWithPendingWrites() in networking.c.

Avoid installing the client write handler when possible.