#2187 closed enhancement (fixed)
update mdns properties on the fly
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 3.0 |
Component: | server | Version: | 2.4.x |
Keywords: | Cc: |
Description (last modified by )
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).
Change History (13)
comment:1 Changed 2 years ago by
Description: | modified (diff) |
---|---|
Milestone: | 2.5 → 3.0 |
Status: | new → assigned |
comment:2 Changed 22 months ago by
comment:3 Changed 22 months ago by
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.
comment:4 Changed 22 months ago by
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.
comment:5 Changed 22 months ago by
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()
comment:6 Changed 22 months ago by
Related: pybonjour has been removed (#2297)
python-zeroconf is a no go:
- for publishing records: turns out that the
update_record
method doesn't actually send any data: Feature Request: ability to update a registered service - for listening: to get notified when the TXT record is updated, we would need Add support for MyListener call getting updates to service TXT records
python-avahi: we actually use dbus to talk to it, so the method to call is actually UpdateServiceTxt
(see Avahi.EntryGroup)
comment:7 Changed 22 months ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
comment:8 Changed 19 months ago by
comment:13 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2187
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..