Design docs
- ircb nodes come up and register themselves to a datastore.
- ircb nodes are behind a load balancer and are also exposed to public.
- Handling client connection:
- A client connects to a random ircb_node_1 (say) via load balancer to connect to a IRC network
- ircb_node_1 queries datastore to find if connection to IRC network for the client is already active in
some ircb node.
- If yes, ircb_node_1 sends a REPL_BOUNCE code to the client with the details of discovered ircb_node_2 (say), so that the client can directly connect to ircb_node_2 directly.
- else
- ircb_node_1 queries datastore to find the best ircb node instance, say, ircb_node_3, to create a new connection to the IRC network (based on number of active connections to the IRC network, maximum connections limit per IP to the IRC network).
- ircb_node_1 then sends REPL_BOUNCE code to the client with details of ircb_node_3 for the client to connect to it directly.
- client connects to the specified and ircb node to connect to the requested IRC network
- Self discovery across ircb node
- With the minimal overhead of setting up initial connection to proper ircb node, there is no extra hop (as would have been if ircb nodes randomly chosen by load balancer were to forward messages to the ircb node connected to the network) within the ircb cluster between the client and IRC network.
- Chances are there that non standard ports are exposed to the world, which might be blocked by network providers. This can be solved using virtual hosts exposed over 80/443 ports instead of random ports.
