Android, NSD / DNS-SD: NsdManager unzuverlässige Erkennung und IP-Auflösung

Im Laufe der letzten Wochen hat Androids NSD-Implementierung mich verrückt gemacht:

Aus der Sicht eines Benutzers treten die folgenden Probleme auf:

• Geräte entdecken sich gegenseitig völlig unbestimmt. Wenn ich meine NsdManager -basierte App starte, funktioniert sie mehr oder weniger, wenn nur zwei Geräte beteiligt sind. Wenn ein drittes Gerät beitritt, wird es selten die ersten beiden entdecken und die ersten beiden werden das dritte nicht sehen. Wenn ich die Apps verlasse (die Registrierung der NSD-Listener aufheben) und sie in einer anderen Reihenfolge neu starte, ist das Erkennungsmuster nicht genau dasselbe, aber ähnlich.

• In meinem Heimnetzwerk funktioniert die IP-Auflösung der erkannten Geräte im Grunde wie erwartet. Bei der Arbeit löst Gerät A, selbst wenn nur zwei Geräte (A und B) verwendet werden, den Dienst von Gerät B mit der IP-Adresse von A und dem Port von B auf und umgekehrt. Irgendwie scheinen die IP-Adresse und der Service-Name auf einer niedrigeren Ebene durcheinander zu liegen (wahrscheinlich der NsdManager).

Ich habe jetzt einen Fehlerbericht für Google-Code eingereicht ( Ссылка ). Ich poste das hier auch in der Hoffnung, mehr Feedback zu bekommen; vielleicht habe ich etwas in meiner Nsd-Helferklasse falsch verstanden.

Nach dem endlosen Debugging habe ich nun Hinweise im Logcat gefunden, dass Androids zugrunde liegendes NsdService selbst fehlerhaft ist, während MDnsDS korrekt zu funktionieren scheint. Aber ich bin unsicher ...

Hier ist eine Protokollausgabe, die das Problem veranschaulicht (einige Nachrichten, die nach Lesbarkeit gefiltert wurden):

Einige Hinweise zum Kontext:

• Mein NSD-Diensttyp ist _tusync._tcp.
• Ich erstelle eindeutige Servicenamen für alle Knoten im Format TuSync-0. [lokale Portnummer] , um Benennungskonflikte zu vermeiden und das Debugging zu erleichtern.
• In diesem Testszenario gibt es drei Geräte. Die IP des Protokollierungsgeräts ist 10.0.0.4, Port 57392.

Das Protokoll zeigt, dass der zugrunde liegende MDnsDS -Daemon alle Knoten korrekt erkennt und auflöst. Das obige NsdService verteilt jedoch nicht die Auflösung für alle von ihnen. Es scheint einen ID-Konflikt bei 16: 57: 04.627 zu geben, wo beide Peers des Geräts (TuSync-0.36230 und TuSync-0.60493) eine interne ID von 107 bekommen (wenn ich die Mechanismen richtig interpretiere, nur indem ich die Logs betrachte) . Die discoveryListener I, die mit NsdManager registriert wurde, wird bei der Erkennung beider Knoten benachrichtigt. Die Auflösung funktioniert jedoch nur für eine der beiden Knoten, die andere löst einen Fehler aus:

Ich habe auch weitere Fälle erlebt, in denen mein NsdService eine Meldung "SERVICE_FOUND Raw" in den Protokollen ausgibt und mein Discovery-Listener nicht benachrichtigt wird. Ein beispielhaftes Protokoll (stark gefiltert; gleicher Testaufbau wie oben):

In diesem Fall löst der erkannte Peer 10.0.0.5 (Port 36230) keine Erkennungsbenachrichtigung aus. Nach der letzten Protokollnachricht passiert nichts. Also hat mein Logging-Knoten 10.0.0.4 nur einen anderen Peer, 10.0.0.6:60493, entdeckt.

Die geringe Anzahl ähnlicher Fehlerberichte lässt mich fragen, ob ich der Einzige bin, der diese Probleme hat oder ob der NsdManager völlig instabil ist und niemand es trotzdem benutzt?

Als Referenz hier ist der Code meiner Helferklasse - es ist ähnlich dem Android NSD Chat-Tutorial, aber ich habe versucht, es wegen einiger anderer Fehler zu verbessern, die das Tutorial zu provozieren scheint.

Beachten Sie, dass ich sogar einen Semaphor implementiert habe, der auf 1 gesetzt werden kann, um zu verhindern, dass mehrere Dienste parallel aufgelöst werden, da sonst jemand Probleme mit der parallelen Auflösung gemeldet hat. Die Einstellung auf 1 funktioniert jedoch nicht, da die fortlaufende Auflösung manchmal nicht erfolgreich ist oder fehlschlägt. Dadurch wird der Semaphor nicht freigegeben und der NsdManager-Thread bleibt bei der nächsten Auflösungsanforderung dauerhaft hängen.

Hat jemand andere solche Probleme? Ich würde mich freuen, wenn auch Leute, die den NsdManager erfolgreich einsetzen, einen Kommentar abgeben würden - das würde zumindest bedeuten, dass ich ein Problem habe, das ich beheben kann:)

Ich habe bereits darüber nachgedacht, NSD aufzugeben und meinen eigenen Broadcast / Multicast-Erkennungsmechanismus zu implementieren. Das könnte theoretisch ein Kinderspiel sein, aber ich habe gelesen, dass Multicast auf Android auch eine PITA ist, weil einige Geräte es verhindern ...