There are two different ideas that are not to be confused with each other. There is the Redis server itself, and then a component’s connection to Redis. The ‘SICRedis’ class is a component's connection to Redis. The Redis server itself is ran with the redis-server command and has a configuration defined in redis.conf.
Redis server
SICRedis looks in environment for DB_IP and DB_PASS
DB_IP defaults to localhost and DB_PASS defaults to ‘changemeplease’
Messages and requests
A component can implement two callbacks, on_message() and on_request().
A request must be met with a reply
Redis channel specification
output channel format:
{name}:{ip} e.g. DialogflowService:192.168.0.181
request-reply channel format:
{name}:reqreply:{ip} e.g. DialogflowService:reqreply:192.168.0.181
Knowing the IP of the device and the service we expect is running, the request reply channel and output channel are known. Using the request reply channel we can request the component to start listening to input channels (using a ConnectRequest).
- Deterministic channel names simplify the structure of the framework significantly. Communication with the component is optional, as one can simply assume it is running on the remote device and listen to the output channel or send requests. There are some consequences
1. Only one instance of a service can run on a device at once