plugeth/swarm/pss/writeup.md

126 lines
4.6 KiB
Markdown
Raw Normal View History

2018-06-20 12:06:27 +00:00
## PSS tests failures explanation
This document aims to explain the changes in https://github.com/ethersphere/go-ethereum/pull/126 and how those changes affect the pss_test.go TestNetwork tests.
### Problem
When running the TestNetwork test, execution sometimes:
* deadlocks
* panics
* failures with wrong result, such as:
```
$ go test -v ./swarm/pss -cpu 4 -run TestNetwork
```
```
--- FAIL: TestNetwork (68.13s)
--- FAIL: TestNetwork/3/10/4/sim (68.13s)
pss_test.go:697: 7 of 10 messages received
pss_test.go:700: 3 messages were not received
FAIL
```
Moreover execution almost always deadlocks with `sim` adapter, and `sock` adapter (when buffer is low), but is mostly stable with `exec` and `tcp` adapters.
### Findings and Fixes
#### 1. Addressing panics
Panics were caused due to concurrent map read/writes and unsynchronised access to shared memory by multiple goroutines. This is visible when running the test with the `-race` flag.
```
go test -race -v ./swarm/pss -cpu 4 -run TestNetwork
1 ==================
2 WARNING: DATA RACE
3 Read at 0x00c424d456a0 by goroutine 1089:
4 github.com/ethereum/go-ethereum/swarm/pss.(*Pss).forward.func1()
5 /Users/nonsense/code/src/github.com/ethereum/go-ethereum/swarm/pss/pss.go:654 +0x44f
6 github.com/ethereum/go-ethereum/swarm/network.(*Kademlia).eachConn.func1()
7 /Users/nonsense/code/src/github.com/ethereum/go-ethereum/swarm/network/kademlia.go:350 +0xc9
8 github.com/ethereum/go-ethereum/pot.(*Pot).eachNeighbour.func1()
9 /Users/nonsense/code/src/github.com/ethereum/go-ethereum/pot/pot.go:599 +0x59
...
28
29 Previous write at 0x00c424d456a0 by goroutine 829:
30 github.com/ethereum/go-ethereum/swarm/pss.(*Pss).Run()
31 /Users/nonsense/code/src/github.com/ethereum/go-ethereum/swarm/pss/pss.go:192 +0x16a
32 github.com/ethereum/go-ethereum/swarm/pss.(*Pss).Run-fm()
33 /Users/nonsense/code/src/github.com/ethereum/go-ethereum/swarm/pss/pss.go:185 +0x63
34 github.com/ethereum/go-ethereum/p2p.(*Peer).startProtocols.func1()
35 /Users/nonsense/code/src/github.com/ethereum/go-ethereum/p2p/peer.go:347 +0x8b
...
```
##### Current solution
Adding a mutex around all shared data.
#### 2. Failures with wrong result
The validation phase of the TestNetwork test is done using an RPC subscription:
```
...
all: new p2p node representation (#17643) Package p2p/enode provides a generalized representation of p2p nodes which can contain arbitrary information in key/value pairs. It is also the new home for the node database. The "v4" identity scheme is also moved here from p2p/enr to remove the dependency on Ethereum crypto from that package. Record signature handling is changed significantly. The identity scheme registry is removed and acceptable schemes must be passed to any method that needs identity. This means records must now be validated explicitly after decoding. The enode API is designed to make signature handling easy and safe: most APIs around the codebase work with enode.Node, which is a wrapper around a valid record. Going from enr.Record to enode.Node requires a valid signature. * p2p/discover: port to p2p/enode This ports the discovery code to the new node representation in p2p/enode. The wire protocol is unchanged, this can be considered a refactoring change. The Kademlia table can now deal with nodes using an arbitrary identity scheme. This requires a few incompatible API changes: - Table.Lookup is not available anymore. It used to take a public key as argument because v4 protocol requires one. Its replacement is LookupRandom. - Table.Resolve takes *enode.Node instead of NodeID. This is also for v4 protocol compatibility because nodes cannot be looked up by ID alone. - Types Node and NodeID are gone. Further commits in the series will be fixes all over the the codebase to deal with those removals. * p2p: port to p2p/enode and discovery changes This adapts package p2p to the changes in p2p/discover. All uses of discover.Node and discover.NodeID are replaced by their equivalents from p2p/enode. New API is added to retrieve the enode.Node instance of a peer. The behavior of Server.Self with discovery disabled is improved. It now tries much harder to report a working IP address, falling back to 127.0.0.1 if no suitable address can be determined through other means. These changes were needed for tests of other packages later in the series. * p2p/simulations, p2p/testing: port to p2p/enode No surprises here, mostly replacements of discover.Node, discover.NodeID with their new equivalents. The 'interesting' API changes are: - testing.ProtocolSession tracks complete nodes, not just their IDs. - adapters.NodeConfig has a new method to create a complete node. These changes were needed to make swarm tests work. Note that the NodeID change makes the code incompatible with old simulation snapshots. * whisper/whisperv5, whisper/whisperv6: port to p2p/enode This port was easy because whisper uses []byte for node IDs and URL strings in the API. * eth: port to p2p/enode Again, easy to port because eth uses strings for node IDs and doesn't care about node information in any way. * les: port to p2p/enode Apart from replacing discover.NodeID with enode.ID, most changes are in the server pool code. It now deals with complete nodes instead of (Pubkey, IP, Port) triples. The database format is unchanged for now, but we should probably change it to use the node database later. * node: port to p2p/enode This change simply replaces discover.Node and discover.NodeID with their new equivalents. * swarm/network: port to p2p/enode Swarm has its own node address representation, BzzAddr, containing both an overlay address (the hash of a secp256k1 public key) and an underlay address (enode:// URL). There are no changes to the BzzAddr format in this commit, but certain operations such as creating a BzzAddr from a node ID are now impossible because node IDs aren't public keys anymore. Most swarm-related changes in the series remove uses of NewAddrFromNodeID, replacing it with NewAddr which takes a complete node as argument. ToOverlayAddr is removed because we can just use the node ID directly.
2018-09-24 22:59:00 +00:00
triggerChecks := func(trigger chan enode.ID, id enode.ID, rpcclient *rpc.Client) error {
2018-06-20 12:06:27 +00:00
msgC := make(chan APIMsg)
ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()
sub, err := rpcclient.Subscribe(ctx, "pss", msgC, "receive", hextopic)
...
```
By design the RPC uses a subscription buffer with a max length. When this length is reached, the subscription is dropped. The current config value is not suitable for stress tests.
##### Current solution
Increase the max length of the RPC subscription buffer.
```
const (
// Subscriptions are removed when the subscriber cannot keep up.
//
// This can be worked around by supplying a channel with sufficiently sized buffer,
// but this can be inconvenient and hard to explain in the docs. Another issue with
// buffered channels is that the buffer is static even though it might not be needed
// most of the time.
//
// The approach taken here is to maintain a per-subscription linked list buffer
// shrinks on demand. If the buffer reaches the size below, the subscription is
// dropped.
maxClientSubscriptionBuffer = 20000
)
```
#### 3. Deadlocks
Deadlocks are triggered when using:
* `sim` adapter - synchronous, unbuffered channel
* `sock` adapter - asynchronous, buffered channel (when using a 1K buffer)
No deadlocks were triggered when using:
* `tcp` adapter - asynchronous, buffered channel
* `exec` adapter - asynchronous, buffered channel
Ultimately the deadlocks happen due to blocking `pp.Send()` call at:
// attempt to send the message
err := pp.Send(msg)
if err != nil {
log.Debug(fmt.Sprintf("%v: failed forwarding: %v", sendMsg, err))
return true
}
`p2p` request handling is synchronous (as discussed at https://github.com/ethersphere/go-ethereum/issues/130), `pss` is also synchronous, therefore if two nodes happen to be processing a request, while at the same time waiting for response on `pp.Send(msg)`, deadlock occurs.
`pp.Send(msg)` is only blocking when the underlying adapter is blocking (read `sim` or `sock`) or the buffer of the connection is full.
##### Current solution
Make no assumption on the undelying connection, and call `pp.Send` asynchronously in a go-routine.
Alternatively, get rid of the `sim` and `sock` adapters, and use `tcp` adapter for testing.