Discussion :

[draiis]

Bonjour à tous

je souhaiterais échanger avec vous quelques point de vue sur l'implémentation du NSD "network service discovery" sur le wifi direct suite à quelques difficultés que j'ai pu rencontré en voulant intégré un échange de data entre deux application.

1 ) petit introduction

Le NSD ou ssdp (Simple Service Discovery Protocol) fournit un mécanisme par lequel les clients peuvent découvrir des services disponibles sur le réseau.
Dans le cas de figures ou les devices sont connectés à un réseau (access point) il est très simple à implémenter sur Android
http://developer.android.com/trainin...essly/nsd.html.

il est donc facile de récupérer l'adresse IP du service en question pour ce connecter dessus.


2) Contexte

Mobile (A) doit pouvoir ce connecter au service de Mobile (B) pour envoyer un fichier
Mobile (B) doit pouvoir ce connecter au service de Mobile (A) pour envoyer un fichier
Mobile (A) et Mobile (B) peuvent éventuellement utilisé d'autre service différent via wifi direct (exemple imprimante ect)


3 ) Android fournis une documentation pour utilisé ce protocole par le wifi-direct voir ce lien : http://developer.android.com/trainin...fi-direct.html

Pour ma part et par définition un service héberge le "serveur" que ce soit un server socket(tcp) /web(http) ect....
donc après découverte en multicast d'un service sur un device il serait logique de se connecter à son serveur.

Mais c'est la que l'implémentation de wifi-direct sous android complique les choses.
on sait que la seul adresse IP disponible en wifi-direct est celle du "Group owner" disponible à la création des pair/groups.

il serait donc encore une fois logique que le mobile voulant ce connecter à un service ne soit PAS le groups owner afin de récuper l'adresse IP du server.

j'ai donc essayé de forcer le poids de la variable groupOwnerIntent pour que mon client ne soit pas le group owner

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
WifiP2pConfig config = new WifiP2pConfig();
config.deviceAddress = service.device.deviceAddress;
config.groupOwnerIntent=0;
  anager.connect(channel, config, new ActionListener() {

afin que le scénario idéal soit:

SCÉNARIO 1:

Mobile (A) : Recherche des services disponible -----> Service trouvés -----> Choix du service ou ce connecter(MOBILE B/C/D) ----->Configuration de ( A) groupOwnerIntent=0 (pour ne pas etre groups owner)----
---> Connection au sevice de l'ip groups owner(en theorie le service).

mais en conclusion l'attribution du groups owner est difficilement gérable. car après la première connexion le groupe est mémorisé par les mobiles et l'attribution du group owner reste fixe si on ne reset par la configuation.

donc si

Mobile (B) tente de connecté à mobile (A) mobile B restera le groups owner et il ce connectera sur lui même.



4) en conclusion , la plupart des exemples que l'on peut trouvés sur le net utilise un socket pour la bidirection des donnée. il n'ya pas de rôle server/client attribué c'est le groups owner qui décide qui sera le server ou le client.

Ce pattern fonctionne pour une application et un protocole propriétaire basé sur la communication socket mais imaginons que notre service soit un serveur HTTP ou autre. ou même un service tierce n'integrant pas la possibilité d'utiliser les socket cliente ?



je me pose pas mal de question sur ma vision de ce pattern et je suis actuellement dans le flou merci d'avance pour vos avis et idées



Draiis

[Feanorin]

Ben c'est du P2P pas de l'Http classique (serveur/client hein), je ne vois pas ce qui te dérange ?