Why does the Satoshi client not use blocking synchronous communication with peers? I think that is mush simpler than the current asynchronous scheme.

I mean after a node sends out a request, it waits for the response in a blocking manner, with a timeout deadline. After the response has arrived, it starts to send the next request. Doesn't this way have better control of communication context?

2 Answers 2


If all clients in a network used blocking synchronous communications, then a single bad client could potentially bring down the entire network.

In a distributed untrusted network, asynchronous communications are required for robustness and reliability.

  • Cannot a timeout deadline of blocking wait prevent that? Currently, an attacker can occupy a connect with ping/pong command for a long time anyway.
    – updogliu
    Jan 27, 2014 at 22:38
  • The Bitcoin network could not scale to accommodate higher traffic if that was the case.
    – John T
    Jan 27, 2014 at 23:14

It's an inferior design for a lot of reasons. The main one is this -- say you need to do a little bit of work for each of 60 peers. Do you really want to have to do 60 context switches to do it? Also, you'd be letting the scheduler decide what work you do, which is never a good thing, especially for a portable, cross-platform program.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.