Replace DialTCP with Dial in reception test 20/188620/4
authorLukasz Wojciechowski <l.wojciechow@partner.samsung.com>
Tue, 4 Sep 2018 10:45:54 +0000 (12:45 +0200)
committerLukasz Wojciechowski <l.wojciechow@partner.samsung.com>
Thu, 13 Sep 2018 15:30:17 +0000 (17:30 +0200)
commitee11489c16e225fa7b95206e1938ca9feb841d7f
tree9db699f4d8c5beb0c878677ac21cc3c30f706ddd
parent522cfd08168bbf5c54f32d5672615093233e7e12
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>
rpc/superviser/reception_test.go