duplicate mdns browse entries

[TheTechnobear]

this might lead to other issues?

it looks like its the same service twice, and this leads to the error/warning

[2019-11-22T19:31:20Z] [rtpmidid.cpp:181] Trying to add again rtpmidi 192.168.1.94:5004 server. Quite probably mDNS re announce. Maybe somebody ask, or just periodically.

Ive checked its not an Ipv6 vs Ipv4

its feels like there should be a way to differentiate between the the two services, and make them unique?

patch@patchbox:~/projects/rtpmidid/build $ ./src/rtpmidid 
[2019-11-22T19:31:20Z] [main.cpp:46] Real Time Protocol Music Instrument Digital Interface Daemon - alpha 19.05
[2019-11-22T19:31:20Z] [main.cpp:47] (C) 2019 David Moreno Montero <[email protected]>
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:85] watch_new 5 1
[2019-11-22T19:31:20Z] [rtpserver.cpp:84] Listening RTP MIDI connections at 0.0.0.0:5004, with name: 'patchbox'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:290] (Browser) CACHE_EXHAUSTED
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:229] Service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:248] 	bear.local:5004 (192.168.1.94)
	TXT=
	cookie is 0
	is_local: false
	our_own: false
	wide_area: false
	multicast: true
	cached: true
[2019-11-22T19:31:20Z] [rtpmidid.cpp:191] New alsa port: 1, connects to 192.168.1.94:5004 (bear)
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:229] Service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:248] 	bear.local:5004 (192.168.1.94)
	TXT=
	cookie is 0
	is_local: false
	our_own: false
	wide_area: false
	multicast: true
	cached: true
[2019-11-22T19:31:20Z] [rtpmidid.cpp:181] Trying to add again rtpmidi 192.168.1.94:5004 server. Quite probably mDNS re announce. Maybe somebody ask, or just periodically.
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'patchbox' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'patchbox' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:21Z] [mdns_rtpmidi.cpp:58] Service '/Client7/EntryGroup1' successfully established
[2019-11-22T19:31:21Z] [mdns_rtpmidi.cpp:225] Received own announcement
[2019-11-22T19:31:21Z] [mdns_rtpmidi.cpp:225] Received own announcement
[2019-11-22T19:31:21Z] [mdns_rtpmidi.cpp:290] (Browser) ALL_FOR_NOW

[TheTechnobear]

ok, this is caused when you have 2 network interfaces up...
in my case wlan0 and eth0

[TheTechnobear]

so now in mdns_rtpmidi.cpp , I log the interface number, so we can at least see why we are getting duplicates ;)

it does not however resolve the underlying issue.
the underlying issue appear to be are creating a non unique service name, due to creating a service on two different interfaces...
i.e. I end up connecting to the same peer twice, thru different interfaces.

what to do?

a) change warning in OP? (say it could be from a different interface?)
b) use interface as part of definition
c) filter by interface

a - easy, but a bit messy?
b - unnecessary, we dont want to connect to same host twice(!)

c - feels right?
in the same way we can filter by netmask, also allow filter by interface?
is this necessary? can we already do this? (--host?)
(it would be nice for us to say in rtpmidid , i always want to use the eth0 in preference to wlan0)

EDIT: --host does not appear to do the trick... not sure it is suppose to or not ;)

[davidmoreno]

I would go for option B + C.

B because an user might want to export over WiFi and Ethernet at the same time (my DeepMind12D and some other Ethernet Synth). Or serve as a bridge. So at least I would add a "W" or "E" to the connection.. (E1, E2 if there are several?). I would not use full device name as it can be "wlp58s0". If we can mark them using avahi.

On your case you have WiFi and Ethernet. For RTPMidi you might not want WiFi, but it's better to give the option to the user. So if in the port name we have a mark, on the other side you can do an informed decision.

But, as in your case, you already know you don't want to export over WiFi, so if at command line you decide not to export on WiFi (or only export of Ethernet), then no need to also say the interface.

--host might be the way to do it, but you need to know which interface has the given host.. I don't remember if we can force Avahi to only export on some interfaces.

I think that "--host" is legacy code from the old mdns code. I just did a test and we can remove right now --host and everything compiles. Or reuse it.

[davidmoreno]

Hi,

after a lot of work I just relased a new version, but since some time ago it shows only one mDNS entry, and try to connect in order of discovery. Normally the first will be the fastest route, but who knows.

There is still no way to force one path over another, but now that we have them listed (for example using rtpmidid-cli status), it will be easy to develop some control option to disable some specific IP.