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

<p>In a distributed untrusted network, asynchronous communications are required for robustness and reliability.</p>

CC BY-SA 3.0
2014-01-27T22:38:00.990Z
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
CC BY-SA 3.0
2014-01-27T23:14:18.077Z
The Bitcoin network could not scale to accommodate higher traffic if that was the case.
John T
CC BY-SA 3.0
2014-01-27T22:14:20.403Z
2014-01-27T22:14:20.403Z
Greg Hewgill
<p>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.</p>

CC BY-SA 3.0
2014-02-27T18:14:25.180Z
2014-02-27T18:14:25.180Z
David Schwartz
<p>Why does the Satoshi client not use blocking synchronous communication with peers? I think that is mush simpler than the current asynchronous scheme.</p>

<p>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?</p>

<bitcoin-core><network>
Why does the Satoshi client not use blocking synchronous communication with peers?
updogliu
# Why does the Satoshi client not use blocking synchronous communication with peers?

(Asked by: username_0 on 2014-01-27)

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?

**Tags:** bitcoin-core, network


---

## 2 answers

### Answer by username_1 on 2014-01-27. Score: 1

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.

> **Comments:**
> **username_0**: 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.  
> **username_2**: The Bitcoin network could not scale to accommodate higher traffic if that was the case.  

---

### Answer by username_3 on 2014-02-27. Score: 0

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.


---

