Ich arbeite daran, eine Anwendung zu erstellen, die Network Service Discovery verwendet. Ich habe diesen Beitrag Ссылка verfolgt und die Anwendung funktioniert, aber ich habe ein paar Fragen basierend auf dem unten gezeigten Code.
WifiP2pDnsSdServiceInfo.newInstance ("_ test", "_presence._tcp", Datensatz);
Es scheint, dass der Datensatz nicht viele Daten enthalten kann. Wenn die Datensatzgröße beispielsweise 20 ist, wird die Information nicht gesendet. Kannst du mir von der Größenbeschränkung erzählen? Wie viel Daten kann ich senden?
Ich bin mir nicht sicher über die verfügbaren Servicetypen wie presence._tcp . Ist es herstellerspezifisch? Eine Liste der unterstützten Servicetypen ist sehr hilfreich. Gibt der Diensttyp die Menge der Informationen an, die ich senden kann? Wenn ja, welche Diensttypen sind für das Senden einer Karte in guter Größe vorzuziehen.
Ein Update: Ich habe diesen Entwurf in Ссылка überprüft und bitte sehen Abschnitt 6.2 DNS-SD TXT-Datensatzgröße . Es sieht so aus, als sei die Größenbeschränkung klein wie angegeben. "Die Gesamtgröße eines typischen DNS-SD-TXT-Datensatzes soll klein sein - 200 Bytes oder weniger. In Fällen, in denen mehr Daten gerechtfertigt sind (z. B. LPR-Druck [BJP]), Wenn die Gesamtgröße unter 400 Byte bleibt, sollte sie in eine einzige 512-Byte-DNS-Nachricht passen. "Irgendwelche Gedanken?
Ich bin ein Neuling in Java / Android, aber ich konnte einige Experimente durchführen.
Die DNS-Dienst-API erwartet eine Zuordnung von <String, String> für Datensatz . Wenn wir uns ausschließlich auf Daten konzentrieren wollen, verwenden wir nur ein Paar und setzen den Schlüssel auf "". In diesem Fall können Sie 92 Zeichen übertragen:
Dies ist das Maximum, das Sie über die Luft senden (oder besser gesagt, empfangen) können. Ich war neugierig, was passiert, wenn ich einige Binärdaten senden möchte. Die Verwendung eines byte[] -Arrays anstelle von String ist keine gute Idee (Absturz), daher müssen wir uns an Strings halten:
Interessanterweise ist dies das Maximum, das Sie senden können (30 Unicode-Zeichen / 60 Byte). Der Grund dafür ist, dass die Wi-Fi-API alle Zeichenfolgen in UTF-32 konvertiert, dh während das erste Beispiel nur ASCII-Werte verwendete (dh in UTF-32 ein Zeichen = ein Byte), verwendete das zweite Beispiel alle Werte aus dem Bereich 0x8000 - 0xffff (dh in UTF-32 ein Zeichen = 3 Bytes).
Wenn Sie die Mathematik machen, sehen Sie 30 x 3 Bytes = 90 Bytes, d. h. es sollten 2 Bytes (Zeichen) übrig und indeseed sein:
%Vor%funktioniert immer noch und erreicht das Limit von 92 Bytes. Bitte beachten Sie, dass Sie die zwei Ersatzbytes für generische Daten (d. H. Etwa 0x1234) nicht verwenden können, da sie als 3-Byte-Wert codiert werden und dies nicht mehr funktioniert.
Interessant ist die Frage, ob die Daten besser mit der Binärmethode oder mit etwas wie base64 codiert werden. Wikipedia sagt, base64 konvertiert drei Oktette in vier codierte Zeichen, d. H. Für 92 ASCII-Zeichen würden wir 69 Byte Daten erhalten, was base64 für diesen kleinen Datensatz viel effizienter macht.
Soweit ich weiß, fehlt der Android NSD Api die richtige Unterstützung für txt records.
Ich wurde dazu aufgefordert, zu jmdns für ein neues Projekt zu wechseln, in dem ich die txtrecords verwenden musste.
Weitere Informationen zur Verwendung von jmdns finden Sie hier: Ссылка
Tags und Links android service-discovery