diff options
author | Lukasz Wojciechowski <l.wojciechow@partner.samsung.com> | 2018-09-04 12:45:54 +0200 |
---|---|---|
committer | Lukasz Wojciechowski <l.wojciechow@partner.samsung.com> | 2018-09-13 17:30:17 +0200 |
commit | ee11489c16e225fa7b95206e1938ca9feb841d7f (patch) | |
tree | 9db699f4d8c5beb0c878677ac21cc3c30f706ddd | |
parent | 522cfd08168bbf5c54f32d5672615093233e7e12 (diff) | |
download | boruta-ee11489c16e225fa7b95206e1938ca9feb841d7f.tar.gz boruta-ee11489c16e225fa7b95206e1938ca9feb841d7f.tar.bz2 boruta-ee11489c16e225fa7b95206e1938ca9feb841d7f.zip |
Replace DialTCP with Dial in reception test
The DialTCP command called with a pair of addresses can be used only
for setting a 'simultaneous connection', when two TCP clients dial
each other, without calling listen on any side.
On some of the machines this behaviour can be buggy as described below.
In boruta no such functionality as simultaneous connection is used.
There is a server client architecture with Listen and Dial.
The DialTCP can be also used by such approach,
when only a single address is passed to the call.
The client code in boruta uses Dial function, not a DialTCP.
So it is better to replace the DialTCP function used in test
with Dial making tests code more similar to the boruta's source code
and eliminating possibility of the bug.
Details copied from go/src/net/tcpsock_posix.go:64:
TCP has a rarely used mechanism called a 'simultaneous connection' in
which Dial("tcp", addr1, addr2) run on the machine at addr1 can
connect to a simultaneous Dial("tcp", addr2, addr1) run on the machine
at addr2, without either machine executing Listen. If laddr == nil,
it means we want the kernel to pick an appropriate originating local
address. Some Linux kernels cycle blindly through a fixed range of
local ports, regardless of destination port. If a kernel happens to
pick local port 50001 as the source for a Dial("tcp", "", "localhost:50001"),
then the Dial will succeed, having simultaneously connected to itself.
This can only happen when we are letting the kernel pick a port (laddr == nil)
and when there is no listener for the destination address.
It's hard to argue this is anything other than a kernel bug. If we
see this happen, rather than expose the buggy effect to users, we
close the fd and try again. If it happens twice more, we relent and
use the result. See also:
https://golang.org/issue/2690
http://stackoverflow.com/questions/4949858/
Change-Id: I9a9825c85c8903c0842347b8e9c9644a26e631e1
Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
-rw-r--r-- | rpc/superviser/reception_test.go | 5 |
1 files changed, 3 insertions, 2 deletions
diff --git a/rpc/superviser/reception_test.go b/rpc/superviser/reception_test.go index ac38912..1010fb7 100644 --- a/rpc/superviser/reception_test.go +++ b/rpc/superviser/reception_test.go @@ -47,7 +47,7 @@ var _ = Describe("superviserReception", func() { It("should get IP from connection", func() { uuid := boruta.WorkerUUID(uuidStr) - conn, err := net.DialTCP("tcp", &net.TCPAddr{IP: net.IPv4(127, 0, 0, 1)}, addr.(*net.TCPAddr)) + conn, err := net.Dial(addr.Network(), addr.String()) Expect(err).ToNot(HaveOccurred()) c := NewSuperviserClient(rpc.NewClient(conn)) @@ -56,7 +56,8 @@ var _ = Describe("superviserReception", func() { addr, err := wl.GetWorkerAddr(uuid) Expect(err).ToNot(HaveOccurred()) - Expect(addr).To(Equal(refAddr)) + Expect(addr.Port).To(Equal(refAddr.Port)) + Expect(addr.IP.IsLoopback()).To(BeTrue()) }) It("should get IP from argument", func() { |