On Mon, 10.04.17 12:41, Kai Krakow (hurikha...@gmail.com) wrote: > > Queries and responses in LLMNR are supposed to be delayed by a random > > time up to 100ms according to the RFC. See: > > > > https://tools.ietf.org/html/rfc4795 section 2.7, and section 7. > > > > If you add up the delay for the query and the response you'll get a > > delay up to 200ms for a full transaction. > > Well it seems a bit more complicated: > > The random delays are a combined value of jitter and timeout. And it > depends on whether you're currently the sender or responder: Responders > have shorter timeouts (only jitter), according to section 2.7. > > It also says SHOULD wait (so it is a good idea), and it says the jitter > MAY be ignored if the responder knows the name is unique. Only the > sender MUST wait for timeout+jitter. > > This is where the 200ms come from, but it may even be 1000+100ms if > you are connected to none-IEEE 802.* media, e.g. VPN or PPP interfaces > and LLMNR is configured to listen on these, as far as I understand > section 7. > > According to RFC2119, the terminology SHOULD suggests that systemd could > maybe make this configurable? Maybe taking the proper warnings for this > configuration into account for administrators... Still you would see > delays of at least 100ms then because the sender MUST wait.
I am not a fan of configuration options in zeroconfey technology like this one I must say. I mean "zeroconf" is about "zero configuration", hence making it configurable creates kind of a tautology... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
