Débogage et résolution des problèmes liés aux connexions réseau (applications Windows Runtime)

[ Cet article est destiné aux développeurs de Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Les problèmes de réseau peuvent avoir des conséquences sur les applications. Elles peuvent cesser de répondre ou de fonctionner, ou bien encore afficher des boîtes de dialogue non actionnables ou des messages d’erreurs déroutants. Le débogage et la résolution de ces erreurs sont parfois difficiles car les erreurs peuvent se produire n’importe où dans la pile réseau.

Qui est concerné ?

Toutes les applications Windows Runtime qui utilisent le réseau, que ce soit directement (à l’aide de sockets par exemple) ou indirectement (à l’aide d’une API qui utilise le réseau), sont potentiellement impactées par les problèmes de réseau. Idéalement, le système d’exploitation traite automatiquement les conditions d’erreur réseau au nom de l’application et, lorsque cela ne fonctionne pas, les applications doivent être prêtes à traiter les erreurs.

Sélection de la fonctionnalité réseau appropriée

Pour qu’une application Windows Runtime puisse accéder au réseau, certaines fonctionnalités d’isolement réseau doivent être activées dans le manifeste de l’application. Ces fonctionnalités sont en principe configurées avec Microsoft Visual Studio 2013 au moment du développement de l’application. Elles sont appliquées par Windows. Si la fonctionnalité réseau appropriée n’a pas été définie, l’accès réseau risque d’être bloqué.

Ainsi, la première étape lors de la résolution des problèmes réseau consiste à vérifier que les fonctionnalités réseau appropriées ont été configurées pour l’application.

Fonctionnalité réseau Description

privateNetworkClientServer

  • Il s’agit généralement d’un profil privé (qui inclut le sous-réseau local et la fonctionnalité de bouclage). Dans une entreprise, le sous-réseau local et le site/domaine Active Directory sont inclus.

  • Lorsque ce paramètre est activé, l’application est destinée à être utilisée sur le réseau privé domestique ou sur un réseau privé professionnel

internetClient

  • Cette fonctionnalité permet la communication entre plusieurs services Internet (via un proxy, si nécessaire). Elle est similaire à la fonctionnalité internetClientServer, mais toutes les communications doivent être à l’initiative du client. Le client n’écoutera pas les connexions provenant d’autres hôtes. Les connexions au sous-réseau local et le bouclage ne sont pas autorisés.

internetClientServer

  • Cette fonctionnalité permet la communication entre plusieurs services Internet (via un proxy, si nécessaire). Elle permet à la fois la connectivité/accessibilité entrante depuis Internet et les opérations sortantes à l’initiative du client.

Remarque  Bien que cette fonctionnalité permette les communications entrantes, la communication peut échouer si des proxys et pare-feu de périmètre installés sur le réseau d’une entreprise continuent de bloquer les communications entrantes.
 

proximity

Cette fonctionnalité permet à deux ordinateurs physiquement très proches (jusqu’à environ 30 cm) d’interagir l’un avec l’autre en utilisant les fonctionnalités de l’espace de noms Windows.Networking.Proximity.

 

Une fois que vous avez déterminé l’accès réseau requis pour votre application, vérifiez que les paramètres de fonctionnalités réseau appropriés ont été configurés. À défaut, l’accès réseau risque d’être bloqué.

Pour plus d’informations sur l’activation du bouclage pour l’accès réseau et sur la résolution des problèmes d’isolement réseau, voir Comment activer le bouclage et déboguer l’isolement réseau.

Comportement en réponse aux changements d’état du réseau

Quand Windows 8.1, Windows Phone 8.1 ou Windows Server 2012 R2 détecte de nouveaux réseaux, il fournit automatiquement de nouvelles options de connectivité. Par exemple, si un utilisateur utilise son réseau 3G pour transmettre des données et qu’il rentre ensuite dans la portée d’un réseau Wi-Fi, la nouvelle option de connectivité sera disponible pour l’application si cela est logique.

Quels que soient les appareils mobiles utilisés, l’offre de réseaux varie. Un réseau 3G peut sortir de portée au domicile d’un utilisateur ou sur le lieu de travail alors que le Wi-Fi est toujours disponible. De la même manière, le Wi-Fi peut sortir de portée lorsqu’un utilisateur quitte son domicile ou son lieu de travail. Parfois aussi, aucun réseau n’est disponible. En raison de la multiplication actuelle des réseaux haut débit mobiles et Wi-Fi, les changements de réseau (réseaux nouveaux, retirés ou non disponibles) seront bientôt courants. Les connexions ne passent pas automatiquement et de façon transparente sur un nouveau réseau : l’application doit le faire de manière explicite. Notez que la stratégie par défaut dans Windows 8.1, Windows Phone 8.1 et Windows Server 2012 R2 consiste à donner la priorité au réseau non restreint sur la connexion réseau limitée et de sélectionner le réseau le plus rapide.

L’accès réseau peut être affecté chaque fois que des changements de réseaux se produisent. Une application peut s’inscrire aux notifications de changement de statut des réseaux (onNetworkStatusChanged) de manière à être avertie lorsque ces changements de réseaux se produisent. Si la connexion utilisée jusque-là par l’application n’est plus disponible (avec indication d’une erreur), l’application devra peut-être effectuer l’une des actions suivantes :

  • Réessayer l’opération. Si cela échoue, attendre la prochaine notification NetworkStatusChanged.
  • Vérifier le coût réseau et essayer de se connecter à un autre réseau.

Instructions élémentaires de résolution des problèmes

Assurez-vous que les applications Windows Runtime permettent les actions suivantes :

  • En cas d’erreur de réseau, vous devez pouvoir réessayer l’opération. Par exemple, ne réessayez pas l’opération si l’authentification échoue, mais réessayez si un réseau sans fil avec lequel vous communiquiez a disparu car un nouveau réseau sans fil est apparu. De nombreuses erreurs disparaissent lorsque l’opération est réessayée. Veillez à suivre les recommandations fournies précédemment dans Comportement en réponse aux changements d’état du réseau.

  • Utilisez des API asynchrones afin d’empêcher la présence d’appels de blocage sur le thread d’interface utilisateur. Si une opération réseau prend beaucoup de temps ou si une erreur se produit, votre application ne doit pas cesser de répondre. N’émulez pas un comportement synchrone sur le comportement asynchrone de Windows Runtime.

  • Planifiez à l’avance un modèle de gestion des erreurs. Lors de la conception de votre application, réfléchissez à la façon dont vous souhaitez signaler les erreurs à l’utilisateur. Par exemple, Outlook utilise un indicateur réseau discret, Communicator se sert d’un modèle de « remplacement de l’intégralité de l’interface utilisateur », tandis qu’Internet Explorer intègre une boîte de dialogue orientée vers les tâches de téléchargement qui affiche les erreurs de réseau. Collectez les erreurs et les exceptions qui sont levées. Cherchez à comprendre chaque chaîne d’erreur et informez l’utilisateur de manière appropriée.

  • Testez votre application dans différents environnements réseau en essayant plusieurs opérations (déconnexion de votre réseau ou nouvelle connexion à votre réseau, interruption ou reprise de la connexion, ou encore changement de réseau).

  • Si lors de ce test, vous trouvez des erreurs qui ne sont pas immédiatement évidentes, vous pouvez activer le suivi ETW afin de collecter davantage d’informations sur le problème.

Rubriques associées

Ajout d’une prise en charge de réseau

Suivi ETW

Comment configurer les fonctionnalités d’isolement réseau

Comment activer le bouclage et déboguer l’isolement réseau