MNT: Bind to PORT 0

[ke-zhang-rd]

Goal
This PR is trying to solve #540 and #514 related socket error only reported on windows.

Solution
It looks like Linux and Mac will assign ('0.0.0.0', 0) to socket, if we didn't explicit bind.

bind argument in this PR is based on

• https://eklitzke.org/binding-on-port-zero (I also have same concern mentioned in this article)
• https://docs.python.org/3/library/socket.html#socket.create_connection

Test
This PR solved scenario in those two issues(#540, #514) but may need further tests.

[danielballan]

The concern mentioned in the article is that if you bind to the port, close the socket and then try binding to the same port again (perhaps in a separate “program”) the port may not still be available. Does that apply here?

[danielballan]

Actually I think there is a deeper problem here. We use this socket to broadcast to multiple interfaces

caproto/caproto/threading/client.py

Line 459 in a3fb3d5

self.udp_sock.sendto(bytes_to_send, (host, specified_port))

so there is no single “our address”. I have an unfinished branch I worked on at ICALEPCS that might be helpful. Will push when I’m back to a laptop.

[ke-zhang-rd]

The concern mentioned in the article is that if you bind to the port, close the socket and then try binding to the same port again (perhaps in a separate “program”) the port may not still be available. Does that apply here?

I don't think so and want to double check with you.

[danielballan]

Gotcha. I don't think so either but wanted to double-check with you! :-D

[danielballan]

I think #544 and especially the change from our_address and their_address to our_addresses and their_addresses at the top of this commit ff8a91a will help.

[danielballan]

I don't think it fixes the issue, but it's the right framework in which to fix the issue. Can you test and see if the bug is still there, to be sure?

[ke-zhang-rd]

I was trying to say bind socket with ''(empty string) might be right based figure I found here
https://realpython.com/python-sockets/#using-hostnames. Then we use getsockname to access address when we need it and we don't need to init our_address in __init__

I might also totally wrong.
I will check #544

[danielballan]

This won't work until #544 is merged, right? I don't think client_address exists yet.

$ git grep client_address
caproto/_commands.py:    .. attribute:: client_address
caproto/_commands.py:    def __init__(self, client_address='0.0.0.0'):
caproto/_commands.py:            ipv4_to_int32(str(client_address)))
caproto/_commands.py:    def client_address(self):
caproto/tests/test_serialization.py:    'client_address': [ip],
doc/source/command-line-client.rst:    [D 20:00:47.564 _broadcaster:74] 1 of 1 RepeaterRegisterRequest(client_address='0.0.0.0')
doc/source/shark.rst:   1550679067.619182 192.168.86.21:55928->255.255.255.255:5065 RepeaterRegisterRequest(client_address='0.0.0.0')

[ke-zhang-rd]

I mean using our_address here. #544 isn't required.

[danielballan]

Revisiting this, I think your first approach was the right one. Refining that a bit, if we bind right after we create the socket we can avoid getting tangled up in the our_addresses vs client_address code that follows. We can be sure that all calls to getsockname() from then on will work. See #551.

[klauer]

Is there still work to do here now that #551 is in?

[danielballan]

I think not. Please reopen if I am mistaken, @ke-zhang-rd.