Outlets on random ports can't be found by unicast discovery, without any warning

Open
  • Is something wrong?
#329 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp
Domain
networking

Research direction

Start in src/resolver_impl.cpp: read the port selection that falls back to OS-chosen ports when BasePort..BasePort+PortRange is exhausted, then the resolve_oneshot wave target list and resolve_attempt_udp, where send errors are dropped. A first step is a warning naming PortRange when an outlet falls back to a random port, plus logging of the dropped send errors. Probing MulticastPort for KnownPeers is a design question to raise with maintainers before changing the target list.

Written by the indexing model from the issue text.

Description

bug

When an outlet can't get ports in [BasePort, BasePort+PortRange) (default 16572–16603), for example because more than ~16 outlets (or resolvers, which take ports from the same range) run on one machine, it silently falls back to OS-chosen ports (AllowRandomPorts, default on). Unicast discovery only probes the port range:

  • KnownPeers are queried on BasePort..BasePort+PortRange only, never on MulticastPort (16571) (src/resolver_impl.cpp, resolve_oneshot/wave target list).
  • The machine addresses (127.0.0.1) are probed the same way.

So such an outlet is found only by real multicast/broadcast; with ResolveScope=machine or KnownPeers-only setups it is invisible, and nothing in the logs explains why.

Proposed: log a warning when an outlet falls back to a random port (naming PortRange), and consider also probing MulticastPort for KnownPeers. Separately, resolve_attempt_udp drops send errors without logging them, which makes these cases hard to diagnose.

Dominant language
C++
Stars
182
Forks
91
Avg merge
8h 46m
Merged PRs (30d)
16

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sccn/liblsl

All issues in sccn/liblsl

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.