Partager via

Windows Sockets : utilisation de sockets avec des archives

  • Article

Cet article décrit le modèle de programmation CSocket. La classe CSocket fournit la prise en charge du socket à un niveau d’abstraction supérieur à celui de la classe CAsyncSocket. CSocketutilise une version du protocole de sérialisation MFC pour transmettre des données vers et depuis un objet socket via un objet CArchive MFC. CSocket fournit un blocage (lors de la gestion du traitement en arrière-plan des messages Windows) et vous donne accès à CArchive, qui gère de nombreux aspects de la communication que vous devriez faire en utilisant l'API brute ou la classe CAsyncSocket.

Conseil

Vous pouvez utiliser la classe CSocket seule, en tant que version plus pratique de CAsyncSocket, mais le modèle de programmation le plus simple consiste à utiliser CSocket avec un objet CArchive.

Pour plus d’informations sur le fonctionnement de l’implémentation de sockets avec des archives, consultez Windows Sockets : Fonctionnement des sockets avec archives. Pour obtenir un exemple de code, consultez Windows Sockets : séquence d’opérations et sockets Windows : exemple de sockets à l’aide d’archives. Pour plus d’informations sur certaines fonctionnalités que vous pouvez obtenir en dérivant vos propres classes à partir des classes sockets, consultez Windows Sockets : Dérivation de classes socket.

Remarque

Si vous écrivez un programme client MFC pour communiquer avec des serveurs (non-MFC) établis, n'envoyez pas les objets C++ à l'archive. Sauf si le serveur est une application MFC qui comprend les types d'objets que vous souhaitez envoyer, il ne peut pas recevoir ni désérialiser vos objets. Pour des informations connexes sur le sujet de la communication avec des applications non MFC, consultez également l’article Windows Sockets : Byte Ordering.

Modèle de programmation CSocket

L'utilisation d'un objet CSocket implique la création et l'association de plusieurs objets de classe MFC. Dans la procédure générale ci-dessous, chaque action est effectuée par le socket de serveur et le socket client, sauf à l'étape 3, dans laquelle chaque type de socket requiert une action différente.

Conseil

Au moment de l'exécution, l'application serveur démarre généralement en premier pour être prête et "à l'écoute" lorsque l'application cliente recherche une connexion. Si le serveur n'est pas prêt lorsque le client tente de se connecter, vous aurez généralement besoin que l'application utilisateur tente de se connecter de nouveau ultérieurement.

Pour installer la communication entre un socket de serveur et un socket client

  1. Construisez un objet CSocket .

  2. Utilisez l’objet pour créer le handle SOCKET sous-jacent.

    Pour un CSocket objet client, vous devez normalement utiliser les paramètres par défaut pour Créer, sauf si vous avez besoin d’un socket de datagramme. Pour un CSocket objet serveur, vous devez spécifier un port dans l’appel Create .

    Remarque

    CArchive ne fonctionne pas avec les sockets datagramme. Si vous souhaitez utiliser CSocket pour un socket datagramme, vous devez utiliser la classe comme vous utiliseriez CAsyncSocket, c'est à dire, sans archive. Les datagrammes sont peu fiables (aucune garantie d'arrivée et peuvent être répétés, ou hors de la séquence), ils ne sont pas compatibles avec la sérialisation par le biais d'une archive. Vous vous attendez à ce qu'une opération de sérialisation se termine de manière fiable et dans l'ordre. Si vous essayez d'utiliser CSocket avec un objet CArchive pour un datagramme, une assertion MFC échoue.

  3. Si le socket est un client, appelez CAsyncSocket ::Connecter pour connecter l’objet socket à un socket serveur.

    -ou-

    Si le socket est un serveur, appelez CAsyncSocket ::Listen pour commencer à écouter les tentatives de connexion à partir d’un client. Lors de la réception d’une demande de connexion, acceptez-la en appelant CAsyncSocket ::Accept.

    Remarque

    La Accept fonction membre prend une référence à un nouvel objet vide CSocket comme paramètre. Vous devez construire cet objet avant d’appeler Accept. Si cet objet socket est hors de portée, la connexion se ferme. N’appelez Create pas ce nouvel objet socket.

  4. Créez un objet CSocketFile , en associant l’objet CSocket à celui-ci.

  5. Créez un objet CArchive pour le chargement (réception) ou le stockage (envoi) de données. L'archive est associée à l'objet CSocketFile.

    N'oubliez pas que CArchive ne fonctionne pas avec les sockets datagramme.

  6. Utilisez l'objet CArchive pour passer des données de test entre les sockets client et serveur.

    Gardez à l'esprit qu'un objet donné CArchive déplace les données dans une seule direction : pour charger (recevoir) ou enregistrer (émettre). Dans certains cas, vous utiliserez deux objets CArchive : un pour envoyer des données, l'autre pour recevoir les accusés de réception.

    Après avoir accepté une connexion et la configuration de l’archive, vous pouvez effectuer des tâches telles que la validation des mots de passe.

  7. Détruisez archive, le fichier de sockets et les objets socket.

    Remarque

    La classe CArchive fournit la fonction membre IsBufferEmpty spécifiquement pour une utilisation avec la classe CSocket. Si la mémoire tampon contient plusieurs messages de données, par exemple, vous devez exécuter la boucle jusqu'à ce qu'ils aient tous été lus et que le tampon ait été vidé. Sinon, la notification suivante selon laquelle il y a des données à recevoir peut être retardée indéfiniment. Utilisez IsBufferEmpty pour vérifier que vous récupérez toutes les données.

L’article Windows Sockets : Séquence d’opérations illustre les deux côtés de ce processus avec un exemple de code.

Pour en savoir plus, consultez :

Voir aussi

Windows Sockets dans MFC
CSocket ::Create