...
Unfortunately a lot of the tests behave as if the implementation can never fail.
Why are we tracking connections at all? Should gRPC be handling that? Why do we care to try to only have one and only one connection for pkiid != pkiid?
Connection Management
| Jira | ||||||
|---|---|---|---|---|---|---|
|
...
TestBasic FAB-13539
Assignee:Morgan Bauer
- Bi-directional connections, one side hangs up the other. Additional connection racing like the below TestAccept case, which is uni-directional.
...
- stopFlag (atomic) and stopCh manage whether the connection is being closed - > We should use one or the other, not both. I think with the way most of the code is, we need the stopCh, so we should get rid of the toDie() function and select on the stopCh as appropriate
- Two peers try to make a connection to each other at the same time, will end up with both connections being closed. Solution: make a deterministic decision on which peer should drop the connection and who should keep making the connection. Logic is in getConnection. Assignee: Swetha Repakula
- Single connection, single direction
- single connection is good for nodes behind a firewall
- single direction (grpc uses either client stream or server stream) was the initial implementation. Changing that now would require a large refactor and may make the peers unable to talk to peers of older versions.
DeMultiplexer
Jira server Hyperledger JIRA serverId 6326cb0b-65b2-38fd-a82c-67a89277103b key FAB-13377
...