tidy Address helper functions,
make ordering of members consistent in allocate and claim,
make linter happier,
remove some unused items, and
update some comments
It's ugly, but beats arg-parsing, inspecting the container and piecing
the address together from exposed ports.
We could just use the host from DOCKER_HOST, but that will fail in the
case of a host with multiple IPs, where the proxy only listens on one.
We erroneously assumed that `docker start` returned the full container
id. It doesn't and as a result we populated DNS with records with ids
other than full container ids. And that's also what we told IPAM. As a
result, DNS and IPAM didn't clean up after the container's death,
resulting in stale DNS entries and leaked IPs.
Fixes#881.
and take extra locks to avoid race conditions.
Also removed the sendPendingGossip() from mockChannelConnection.SendProtocolMsg(),
because waiting in flush now creates a deadlock. Tests will have to
call sendPendingGossip() explicitly if they need it.
This is how fragmentation tests used to happen:
A: conn.stackFrag = false
A->B: StartFragmentationTest
B->A: send large non-DF UDP packet
A->B: FragmentationReceived
B: conn.stackFrag = true
conn.stackFrag = true means "UDP packets sent to the other peer get
correctly fragmented and re-assembled".
Note how A clears its own stackFrag flag, but the test establishes
whether fragmentation works for B->A, and ends up setting stackFrag on
B. Not only is this weird, it also means that if A previously had
stackFrag=true, it will now start fragmenting packets until B
initiates a fragmentation test.
The new sequence is:
A: conn.stackFrag = false
A->B: send large non-DF UDP packet
B->A: FragmentationReceived
A: conn.stackFrag = true
Closes#746.
If the name cannot be resolved, getent fails, which in turn causes
assert_dns_record to just return with a non-zero status at that point,
which causes the whole test to just terminate with a non-zero status,
but no indication whatsoever what had gone wrong.
Bryan Boreham