Skip to content

Fixes for OS X #188

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Fixes for OS X #188

wants to merge 1 commit into from

Conversation

estyrke
Copy link

@estyrke estyrke commented Sep 25, 2019

  • Listen on respond_sockets in addition to listen_socket
  • Do not bind to respond_sockets in multicast mode

Without either of these changes, I get no replies at all when browsing for services using the browser example. I'm on a corporate network, and when connecting to a different network it works without these changes, so maybe it's something about the network configuration in this particular network that breaks the previous behavior.

Unfortunately, I have no idea how this affects other platforms, or what the changes really mean. However, it works for me and it seems reasonable to get replies back on the same socket where they are sent.

* Listen on respond_sockets in addition to listen_socket
* Do not bind to respond_sockets in multicast mode
@jstasiak
Copy link
Collaborator

Thanks @estyrke. With this patch you can discover services in both corporate and other networks, right?

@estyrke
Copy link
Author

estyrke commented May 28, 2020

@jstasiak, I'm afraid I have not tested for any regressions in other cases, or indeed very much at all. It's just something that seemed to work for me at the time.

@jstasiak
Copy link
Collaborator

@estyrke I rebased this PR in #270 to resolve conflicts.

jstasiak added a commit that referenced this pull request Jul 7, 2020
This contains two major changes:

* Listen on data from respond_sockets in addition to listen_socket
* Do not bind respond sockets to 0.0.0.0 or ::/0

The description of the original change by Emil:

<<<
Without either of these changes, I get no replies at all when browsing for
services using the browser example. I'm on a corporate network, and when
connecting to a different network it works without these changes, so maybe
it's something about the network configuration in this particular network
that breaks the previous behavior.

Unfortunately, I have no idea how this affects other platforms, or what
the changes really mean. However, it works for me and it seems reasonable
to get replies back on the same socket where they are sent.
>>>

The tests pass and it's been confirmed to a reasonable degree that this
doesn't break the previously working use cases.

Additionally this removes a memory leak where data sent to some of the
respond sockets would not be ever read from them (#171).

Co-authored-by: Emil Styrke <emil.styrke@axis.com>
@jstasiak
Copy link
Collaborator

jstasiak commented Jul 7, 2020

Merged in fc92b1e.

@jstasiak jstasiak closed this Jul 7, 2020
@jstasiak
Copy link
Collaborator

jstasiak commented Jul 7, 2020

This has been released in 0.28.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants