[Résolu]Temps de chargement 10.5 et 10.6
Ceetix
Membre
J'ai une petit app qui fait serveur en cherchant les devices connectés sur le réseau wifi. Sur mes deux mac en 10.6 quand je lance l'application il faut environ 5 minutes pour qu'elle se lance, alors que sur le mac de mon école qui est sous 10.5 l'application se lance directement. Je ne comprends pas pourquoi et d'où ça pourrait venir. C'est assez gênant vu que je travaille le plus souvent sur mes Mac -_-
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Une fois fait,ça en dira un peu plus sur le soucis, non ?
Tu peux utiliser le débogueur ?
Ou bien c'est une application tiers qui te sert de serveur ?
Quand tu dis "il faut 5mn pour qu'elle se lance", tu parles de quoi ? Entre le moment où tu as cliqué sur l'icône de ton appli et le moment où elle arrête de rebondir dans le dock ? Ou le moment où elle est "lancée" (au sens où il a chargé l'appli et lancé le main et tout quoi) et celui où elle toruve les devices connectés au réseau wifi ?
D'ailleurs, tu as un bouton dans ton appli pour lancer le scan, ou ça lance le scan direct dès le lancement ? Si tu as un bouton, tu pourras tout de suite nous dire si ces 5mn c'est entre le double-clic de l'appli et l'affichage de l'UI ou si c'est entre le clic du bouton et le résultat du scan. A moins que ce ne soit une appli sans UI (si elle fait serveur, c'est probable), ... et dans ce cas, si tu mets des logs, à quel endroit ça coince ?
Une fois les logs mis tu pourras nous dire : c'est un truc qui bloque 5mn sans rien faire, c'est un truc qui boucle pendant 5mn à la recherche de qqch, c'est plusieurs trucs qui bloquent chacun un peu de temps (avec un temps total cumulé de 5mn, donc) ?... etc
La méthode le permet autant essayé dès fois que ...
Essaye aussi de modifier ceci:
" type:@remote._tcp.
" type:@_remote._tcp.
Ce ne sont que les noms d'instances qui ne prennent pas de underscores, tous les noms de services Bonjour doivent commencer par "_"
Là , à mon avis, il n'arrive pas à trouver le périphérique associé au NSNetService, du coup ça bloque.
Et attention, le type de service _remote._tcp. est déjà utilisé. http://www.dns-sd.org/servicetypes.html Est-ce le même type de service ?
Sinon, en supprimant le port cela donne quoi ? Il y a peut être un conflit à ce niveau.
Autrement dit, c'est réellement l'appel à cette méthode de NSNetService qui bloque l'appli et la gèle, et donc que le code juste après n'est jamais exécuté ? ou c'est juste la callback de ton delegate qui n'est appelée qu'au bout de 5mn parce qu'il ne trouve pas de device sur le wifi avant ça ? (et donc que l'appli ne fait rien de particulier tant qu'elle n'a pas détecté de client sur le réseau, ce qui te donne l'impression qu'elle a gelé) ?
C'est un peu pour ça que je te demande ce que tu appelles "ça met 5mn à se lancer" : à quel endroit exactement ça bloque, juste après ta ligne, par un effet de bord de la présence de ta ligne, ...? Tu as mis des logs dans toutes les méthodes de delegate liées à ton NSNetService, voir si elles étaient appelées ?
Et si tu émules la présence d'un service (en utilisant dns-sd en ligne de commande) de type "_remote._tcp" sur ton mac, est-ce qu'il démarre plus vite ?
Concernant la précision la zone .local, hors cas très particulier ce n'est pas vraiment à toi développeur de dire si ton appli doit être enregistrée sur la zone local ou ailleurs, mais à la machine et son administrateur de décider si la zone d'enregistrement recommandé est la zone local ou une zone de type Wide Area Bonjour (WAB). D'autant que si l'administrateur réseau a décidé de publier sur un WAB il peut l'imposer. Donc autant faciliter l'intégration dans de gros parcs en laissant le système choisir.
Sinon pour tes lenteurs, je n'ai pas fait de test, mais je ne pense pas que ton problème vienne du 10.5 ou 10.6, mais de son environnement. Le réseau de ton école doit être bien configuré et avoir un DNS local qui tient la route. Toi chez toi tu dois être derrière une livebox ou quoi et ça perturbe grandement !
J'avais travaillé avec Bonjour & cie sur 10.5, le problème que je rencontrais se situait au niveau de la classe NSHost pour la résolution de nom. Je ne sais pas comment elle est implémentée, mais le fait est qu'elle n'utilise pas le même système qu'host ou dig en ligne de commande. J'avais fait des bench avec un collègue ayant un réseau derrière une Airport Extrem et moi derrière une livebox, chez moi NSHost attendait le timeout réseau pour me renvoyer la réponse (aucune idée du pourquoi).
Je n'avais pas creusé l'histoire plus que ça, à voir si le problème est équivalent dans ton cas !
Change tes serveurs DNS sur le mac, au lieu de laisser l'air port en relais DNS met directement ceux de Google par exemple (8.8.8.8 et 8.8.4.4). ça devrait t'aider.