Doing a little more lcsync (#multicast file syncing) optimization.

I'm impressed with how responsive MLD triggering is, at least on Linux, where MLDv2 is supported. MLD is not a great protocol, but then it wasn't designed to be abused in this way 😁

Still not getting anything like tcp throughput for a 1 to 1 file transfer, but latency for file comparisons is a *lot* better than I'd expected.

eg. to compare two 4GiB files that are the same, rsync takes just over 1 minute (61s). lcsync: 17s.

@dentangle interesting, why is #lcsync listening on #MLD itself, instead of leaving this fully with the OS?
Is the implementation taking #RFC4541 into consideration? Specifically the part where it says that snooping switches may only forward reports to ports with multicast routers.
@T_X In client mode #lcsync leaves it to the OS, but in server mode it listens to MLD traffic so it knows when to send something, and what. #RFC4541 doesn't apply here, as lcsync is not acting as a switch (lcsync is not switching traffic, but is a source or a sink). This is a prelude to every node becoming a potential multicast router, but that's for another milestone 😉
@dentangle ah, okay, to optimize when to send what as a server. But will the server then also send MRD Advertisements then? If not then I'm wondering if an lcsync server might miss reports. As #RFC4541 creates a forwarding tree for reports in a network with snooping switches. So only hosts which are multicast routers (detected via MLD Queries or MRD) would receive MLD reports then, unless I'm missing something.
@T_X #lcsync sends MLD Queries, so hopefully that will stop any #RFC4541 switches from getting confused. MLDv1 makes a real mess of this - be nice to get rid of it. The very idea of a switch trying to guess what is a router is madness, when the simple answer in IPV6+MLD2 terms is does this port listen to ff02::16 ?
@dentangle ah, yes, #MLD queries should kind of work around this issue. As long as the lcsync server does not lose an MLD querier election to another MLD querier.
I'm wondering if it would be feasible and help to write an #RFC to update MLDv1 which disallows report suppression. At least in theory such a small update would maybe be faster to propagate. Faster than demanding that everyone fully abandons #MLDv1 and migrates to #MLDv2.
#IETF #multicast