Client side caching: new developments pending

[antirez]

This is a list of things I'm changing in CSC:

1. Try to rewrite the code to track keys instead of hash slots as per suggestion of @eliblight.
2. Implement the CLIENT TRACKING on OPTIN to only track keys that are fetched after a "CACHING yes" command. Maybe also support OPTOUT and "CACHING no" before the next command. Note that this schema is about race conditions: we want to prepare the next command to be executed+tracked and we don't want to inform later the server that we are tracking a key, otherwise is a nightmare.
3. Make sure keys are invalidated in expireIfNeeded(), @yossigo pinged about that and we need to verity.
4. Implement the BCAST mode plus the PREFIX support as explained in https://www.youtube.com/watch?v=TW9uFIJ9xkc
5. Implement a WITHTTL option for the GET command returning the milliseconds TTL of the fetched key as suggested by @eliblight.
6. Change invalidation messages in order to have an array of elements and not a single element for invalidation messages, this is very important in the case of BCAST, but may also be used to improve the normal tracking feature, accumulating data for clients and sending them only at the end.
7. Send invalidation messages when TTL is reduced, but not if changed otherwise.

Document the following things:

1. Race condition between invalidation messages and data because of the two channels design:

Data: -> GET foo
Notifications: <- Invalidate foo (somebody else touched it)
Data: <- "bar" (foo value)

We need to inform client authors that they need to create the entry for "foo" before sending the command. If an invalidation message is received in the meantime, we need to discard the cached "foo" key (that would be set to "value will arrive" sentinel initially), and when the actual value arrives we don't do anything with it, since the entry is missing in the cache table of the client.

2. Inform the client authors that invalidations because of TTLs may be delayed, but will surely be received, so they may implement either always a maximum TTL depending on the application demands, or implement proper TTL handling in the client, fetching the TTL with the value itself when doing caching.

[AlphaHot]

@antirez Thank you very much for your work. Post videos on YouTube more often 😺

[madolson]

It looks like of these changes we never implemented 5,6,7 of these. @eliblight Do you have any interest in following up here, you suggested many of these improvements?

[eliblight]

Ack... lets see how we can fit it in.