Separate mDNS records by interface

This change addresses some of the problems with multihomed systems.
First, interface addresses should only be advertised on the interface
for which they are valid.  Second, services are now tied to the first
interface on which they are discovered.  Hostname collisions from
different interfaces are no longer a problem.

Bug: openscreen:20
Change-Id: Icc4ea280143abd22d16baaf748dc49e1019a36e3
Reviewed-on: https://chromium-review.googlesource.com/c/1375025
Reviewed-by: Peter Thatcher <pthatcher@chromium.org>
Commit-Queue: Brandon Tolsch <btolsch@chromium.org>
19 files changed
tree: 3571ae757bc06075425e23beec84ea4ce42941ea
  1. api/
  2. base/
  3. build/
  4. demo/
  5. discovery/
  6. docs/
  7. infra/
  8. msgs/
  9. platform/
  10. sample/
  11. third_party/
  12. tools/
  13. .clang-format
  14. .gitignore
  15. .gitmodules
  16. .gn
  17. advanced_gerrit.md
  18. AUTHORS
  19. BUILD.gn
  20. codereview.settings
  21. LICENSE
  22. PRESUBMIT.py
  23. PRESUBMIT.sh
  24. README.md
README.md

Open Screen Library

This library implements the Open Screen Protocol. Information about the protocol can be found in the Open Screen GitHub repository.

Continuous Build

Open Screen uses LUCI builders to monitor the build and test health of the library.

Coming soon: tryjob and submit queue integration with Gerrit code review.

Build guide

Open Screen Library code should follow the Open Screen Library Style Guide. In addition, you should also run //PRESUBMIT.sh before uploading changes for review (which primarily checks formatting).

Build dependencies

Run ./tools/install-build-tools.sh from the root source directory to obtain a copy of the following build tools:

  • Build file generator: gn
  • Code formatter: clang-format

You will have to obtain and install these yourself:

  • Compiler toolchain: Currently, this is gcc on Linux, and clang on Mac (from Xcode).

  • Builder: ninja

    GitHub releases

Building an example with GN and Ninja

After checking out the Open Screen library, make sure to initialize the submodules for the dependencies. The following commands will checkout all the necessary submodules:

  git submodule init
  git submodule update

The following commands will build the current example executable and run it.

  ./gn gen out/Default    # Creates the build directory and necessary ninja files
  ninja -C out/Default  # Builds the executable with ninja
  ./out/Default/hello     # Runs the executable

The -C argument to ninja works just like it does for GNU Make: it specifies the working directory for the build. So the same could be done as follows:

  ./gn gen out/Default
  cd out/Default
  ninja
  ./hello

After editing a file, only ninja needs to be rerun, not gn.

Gerrit

The following sections contain some tips about dealing with Gerrit for code reviews, specifically when pushing patches for review.

Uploading a new change

There is official Gerrit documentation for this which essentially amounts to:

  git push origin HEAD:refs/for/master

You may also wish to install the Change-Id commit-msg hook. This adds a Change-Id line to each commit message locally, which Gerrit uses to track changes. Once installed, this can be toggled with git config gerrit.createChangeId <true|false>.

To download the commit-msg hook for the Open Screen repository, use the following command:

  curl -Lo .git/hooks/commit-msg https://chromium-review.googlesource.com/tools/hooks/commit-msg

Gerrit keeps track of changes using a Change-Id line in each commit.

When there is no Change-Id line, Gerrit creates a new Change-Id for the commit, and therefore a new change. Gerrit's documentation for replacing a change describes this. So if you want to upload a new patchset to an existing review, it should contain the matching Change-Id line in the commit message.

Adding a new patchset to an existing change

By default, each commit to your local branch will get its own Gerrit change when pushed, unless it has a Change-Id corresponding to an existing review.

If you need to modify commits on your local branch to ensure they have the correct Change-Id, you can do one of two things:

After committing to the local branch, run:

  git commit --amend
  git show

to attach the current Change-Id to the most recent commit. Check that the correct one was inserted by comparing it with the one shown on chromium-review.googlesource.com for the existing review.

If you have made multiple local commits, you can squash them all into a single commit with the correct Change-Id:

  git rebase -i HEAD~4
  git show

where ‘4’ means that you want to squash three additional commits onto an existing commit that has been uploaded for review.