`test_remote_address` fails

[Marcel Telka]

I'm packaging websockets for OpenIndiana and when I ran tests I found following failures:

======================================================================
FAIL: test_remote_address (tests.sync.test_connection.ClientConnectionTests)
Connection has a remote_address attribute.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "$(BUILD_DIR)/tests/sync/test_connection.py", line 665, in test_remote_address
    self.assertIsNotNone(self.connection.remote_address)
AssertionError: unexpectedly None

======================================================================
FAIL: test_remote_address (tests.sync.test_connection.ServerConnectionTests)
Connection has a remote_address attribute.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "$(BUILD_DIR)/tests/sync/test_connection.py", line 665, in test_remote_address
    self.assertIsNotNone(self.connection.remote_address)
AssertionError: unexpectedly None

----------------------------------------------------------------------
Ran 1297 tests in 9.735s

FAILED (failures=2, skipped=8)

[Aymeric Augustin]

This is likely related to the implementation of socket.socketpair and/or socket.socket.getpeername on OpenIndiana.

That's what I'm using for testing and how remote_connection is implemented respectively.

The documentation of getpeername acknowledges that it isn't supported on some systems. OpenIndiana may be one of those systems.

Do you a concrete proposal that doesn't make the code or the tests more complex?

[Aymeric Augustin]

For clarity: to me this is an OpenIndiana and/or Python issue; websockets isn't the right level to fix this.

If there's an easy solution that adds no maintenance cost and helps you, of course I'll consider it.

The onus of proposing it is on you, though, because you're the one who wants to run the tests on OpenIndiana (and I wish you didn't, as explained in #1426).

[Marcel Telka]

This is likely related to the implementation of socket.socketpair and/or socket.socket.getpeername on OpenIndiana.

Could you please suggest some simple test that would prove the problem is either in socket.socketpair and/or socket.socket.getpeername on OpenIndiana?

I tried this:

$ python
Python 3.9.16 (main, Feb 19 2023, 15:42:40) 
[GCC 10.4.0] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.socketpair()
(<socket.socket fd=5, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0>, <socket.socket fd=4, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0>)

But that's apparently not enough.

Thank you.

[Aymeric Augustin]

Try this:

>>> local, remote = socket.socketpair()
>>> local.getpeername()
''
>>>

I expect that you'll get None instead of the empty string.

This shows that the test isn't very good... I will think about it.

[Aymeric Augustin]

Perhaps I should rewrite that test to use a real IP socket.

[Marcel Telka]

Yes, exactly, None:

$ python
Python 3.9.16 (main, Feb 19 2023, 15:42:40) 
[GCC 10.4.0] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> local, remote = socket.socketpair()
>>> local.getpeername()
>>> print(local.getpeername())
None
>>>

[Aymeric Augustin]

Thank you for confirming.

Honestly this test doesn't test anything beyond the existence of a remote_address method that doesn't crash. I could remove the assertion that it doesn't return None. Anyway the return value is "whatever getpeername returns"; that's platform specific.

[Aymeric Augustin]

I mocked socket methods with platform-specific behavior to make the tests more robust. Hopefully that'll do the job on OpenIndiana. Please let me know if it doesn't.

[Marcel Telka]

I just tested websockets 12.0 + b3c5195 and I can confirm that the issue is gone.

Thank you!