Blocked by #1123. Discovered as part of #2188
We only learn the session name after the server starts, at which point the mdns properties are already set. We should be able to integrate mdns better with the server so that the exact set of properties exposed can be chosen by the server (ie: shadow vs seamless) and their values can change. (ie: session name can be changed via xpra control).
mdns moved to server code in r22683, see #1123 for details.
The difficulty is that I see nothing in the API for the various mdns backends we have that would allow us to set the TTL and / or change properties and broadcast them..
The rfc6762: Multicast DNS states: When a Multicast DNS querier receives an answer, the answer contains a TTL value that indicates for how many seconds this answer is valid. After this interval has passed, the answer will no longer be valid and SHOULD be deleted from the cache. Before the record expiry time is reached, a Multicast DNS querier that has local clients with an active interest in the state of that record (e.g., a network browsing window displaying a list of discovered services to the user) SHOULD reissue its query to determine whether the record is still valid.
Also: At any time, if the rdata of any of a host's Multicast DNS records changes, the host MUST repeat the Announcing step described above to update neighboring caches. and A host may update the contents of any of its records at any time, though a host SHOULD NOT update records more frequently than ten times per minute.
The recommended TTL value for other Multicast DNS resource records is 75 minutes.
In the case where a host knows that certain resource record data is about to become invalid (for example, when the host is undergoing a clean shutdown), the host SHOULD send an unsolicited Multicast DNS response packet, giving the same resource record name, rrtype, rrclass, and rdata, but an RR TTL of zero.
Having completed the Probing step, if necessary, the host MUST then send a series of unsolicited announcements to update cache entries in its neighbor hosts.
For avahi: avahi: broadcast that my service has updated information: avahi_entry_group_update_service_txt.
Also https://www.avahi.org/doxygen/html/: When you need to modify your services (i.e. change the TXT data or the port number), use the AVAHI_PUBLISH_UPDATE flag, When changing just the TXT data avahi_entry_group_update_txt() is a shortcut for AVAHI_PUBLISH_UPDATE
python-avahi does have the PUBLISH_UPDATE flag, just not sure how to use it yet.
python-zeroconf has a convenient method:
def update_record(self, now: float, rec: DNSRecord) -> None:
"""Used to notify listeners of new information that has updated
a record."""
for listener in self.listeners:
listener.update_record(self, now, rec)
self.notify_all()
Related: pybonjour has been removed (#2297)
python-zeroconf is a no go:
update_record method doesn't actually send any data: Feature Request: ability to update a registered service
python-avahi: we actually use dbus to talk to it, so the method to call is actually UpdateServiceTxt (see Avahi.EntryGroup)
Added for the avahi backend in r22707 + r22708.
Used this code to expose the number of clients connected in r22709.
This is not as useful as I thought it was going to be - we'll probably need something else for #2125.
This will do for now, will update the zeroconf backend if and when the support for updates is added to python-zeroconf.
This caused a regression, the mdns record update is missing the "mode" attribute, which causes the mdns session browser to display invalid url links. Fixes:
Done for python-zeroconf in r23371.
r23347 introduced a race condition, fixed in r23370
See also #2317
Caused a bug on win32: #2710
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2187