Hacker News Reader

Assuming of course that each connection is bidirectional, and if you are modelling the network like a graph then you may not have bidirectional links in order to capture some asymmetric edge weighting for routing purposes :)

View on HN

The historic reason I give this as an interview question is:

My first distributed networking framework (in our Keyspace product) used unidirectional connections, eg. I had two connections per node-pair (n(n-1) total). This was OK because Keyspace was meant to run on 3 nodes, and it's very easy to handle in terms of code.

However in ScalienDB, which is a generic sharded database meant to be run on 10-100s nodes, I wanted to get that /2 in the formula, after all "easy to handle in terms of code" is not a good excuse for having 2x as many TCP connections on the switch! It was surprisingly error-prone to get this right. The basic problem is both sides initiating connections, and then figuring out which one to drop.

Maybe just ask the question you want to ask? Modern stacks can handle hundreds of thousands of connections these days, so this concern may be outdated. Then you could have a conversation about if there's enough CPU, is there enough RAM to handle the connections, network bandwidth, how you handle replication, failover, structuring software to handle lots of connections, etc, all of which indicate someone may actually know something, but you'll never get to that point because of the magic formula. Often these problems are used as a proxy for something else when you can actually talk about at that something else. Sometimes I think it's just because most people are covering for not knowing about that something else.

Reply on news.ycombinator.com