Rilevamento servizio di rete Android

Question

Sto lavorando per creare un'applicazione che utilizza Network Service Discovery. Ho seguito questo post http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html e l'applicazione sta funzionando, ma ho un paio di domande basate sul codice mostrato di seguito.

WifiP2pDnsSdServiceInfo.newInstance ("_ test", "_presence._tcp", record);

Sembra che il record non possa contenere molti dati. Ad esempio se la dimensione del record è 20, le informazioni non vengono inviate. Puoi dirmi la limitazione delle dimensioni? Quanti dati posso inviare?

non mi è chiaro circa i tipi di servizio disponibili come _ presence._tcp. È specifico del venditore? Un elenco dei tipi di servizi supportati sarà utile sapere. Il tipo di servizio determina la quantità di informazioni che posso inviare? In tal caso, quali tipi di servizio sono preferibili per l'invio di una mappa di buone dimensioni.

Aggiornamento: ho controllato questo progetto allo http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt e vedere la sezione 6.2 Dimensione record TXT DNS-SD. Sembra che il limite di dimensioni sia piccolo, come indicato "La dimensione totale di un tipico record TXT DNS-SD è intesa come piccola - 200 byte o meno Nei casi in cui sono giustificati più dati (ad esempio stampa LPR [BJP]) , mantenendo la dimensione totale inferiore a 400 byte dovrebbe consentirgli di adattarsi a un singolo messaggio DNS da 512 byte ". qualche idea?

Answer 1

Sono un principiante in Java/Android ma sono stato in grado di condurre alcuni esperimenti.

L'API del servizio DNS prevede una mappa di <String, String> per record. Se vogliamo concentrarci esclusivamente sui dati, usiamo solo una coppia e impostiamo la chiave su "". In questo caso, è possibile trasferire 92 caratteri:

record.put("", "123456789"); 

Questo è il massimo che si può inviare (o per meglio dire, ricevere) via etere. Ero curioso di sapere cosa succede se voglio inviare dei dati binari. Utilizzando un byte[] matrice anziché String non è una buona idea (arresto) per cui dobbiamo attaccare con le stringhe:

record.put("", "\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u1234\u5678\u9012\u3456\u7890\u1234\u5678"); 

È interessante notare che questo è il massimo che si può inviare (30 caratteri Unicode/60 byte). Il motivo è che l'API Wi-Fi sembra convertire tutte le stringhe in UTF-32, cioè mentre il primo esempio utilizzava solo valori ASCII (cioè in UTF-32 un carattere = un byte), il secondo esempio utilizzava tutti i valori dell'intervallo di 0x8000 - 0xffff (cioè in UTF-32 un carattere = 3 byte).

Se fate i conti, si vede 30 x 3 byte = 90 byte, cioè ci deve essere di 2 byte (caratteri) a sinistra e indeeed:

record.put("", "\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u0031\u0032"); 

funziona ancora, raggiungendo il limite di 92 byte . Si noti che non è possibile utilizzare i due byte di riserva per dati generici (ad esempio qualcosa come 0x1234) perché viene codificato come valore a 3 byte e questo non funzionerà più.

La domanda interessante è se i dati sono meglio codificati usando il metodo binario o usando qualcosa come base64. Wikipedia dice che base64 converte tre ottetti in quattro caratteri codificati, cioè per 92 caratteri ASCII otterremmo 69 byte di dati, rendendo base64 molto più efficiente per questo piccolo insieme di dati.

Answer 2

Per quanto ne so, Android NSD Api manca del supporto adeguato per i record txt.

Mi è stato chiesto di passare a jmdns per un progetto recente in cui avevo bisogno di utilizzare le txtrecords.

Maggiori informazioni sull'utilizzo jmdns può essere trovato qui: http://home.heeere.com/tech-androidjmdns.html