Partager via


CSocketFile, classe

Objet CFile utilisé pour envoyer et recevoir des données sur un réseau via Windows Sockets.

Syntaxe

class CSocketFile : public CFile

Membres

Constructeurs publics

Nom Description
CSocketFile ::CSocketFile Construit un objet CSocketFile.

Notes

Vous pouvez attacher l’objet CSocketFile à un CSocket objet à cet effet. Vous pouvez également attacher l’objet à un CArchive objet pour simplifier l’envoi CSocketFile et la réception de données à l’aide de la sérialisation MFC.

Pour sérialiser (envoyer) des données, vous l’insérez dans l’archive, qui appelle CSocketFile les fonctions membres pour écrire des données dans l’objet CSocket . Pour désérialiser (recevoir) des données, vous extrayez de l’archive. Ainsi, l’archive appelle CSocketFile les fonctions membres pour lire les données de l’objet CSocket .

Conseil

Outre l’utilisation CSocketFile décrite ici, vous pouvez l’utiliser comme objet de fichier autonome, comme vous le pouvez avec CFile, sa classe de base. Vous pouvez également utiliser CSocketFile avec n’importe quelle fonction de sérialisation MFC basée sur archive. Étant donné que CSocketFile ne prend pas en charge toutes les fonctionnalités de CFilela norme, certaines fonctions de sérialisation MFC par défaut ne sont pas compatibles avec CSocketFile. C’est particulièrement vrai de la CEditView classe. Vous ne devez pas essayer de sérialiser des CEditView données par le biais d’un CArchive objet attaché à un CSocketFile objet à l’aide CEditView::SerializeRawde ; utilisez CEditView::Serialize à la place. La SerializeRaw fonction s’attend à ce que l’objet de fichier ait des fonctions, telles que Seek, qui CSocketFile n’ont pas.

Lorsque vous utilisez CArchive CSocketFile et CSocketque vous pouvez rencontrer une situation où CSocket::Receive entre une boucle (par PumpMessages(FD_READ)) en attente de la quantité d’octets demandée. Cela est dû au fait que les sockets Windows n’autorisent qu’un seul appel recv par notification de FD_READ, mais CSocketFile autorisent CSocket plusieurs appels recv par FD_READ. Si vous obtenez un FD_READ lorsqu’il n’y a pas de données à lire, l’application se bloque. Si vous n’obtenez jamais un autre FD_READ, l’application cesse de communiquer sur le socket.

Vous pouvez résoudre ce problème comme suit. Dans la OnReceive méthode de votre classe de socket, appelez CAsyncSocket::IOCtl(FIONREAD, ...) avant d’appeler la Serialize méthode de votre classe de message lorsque les données attendues à lire à partir du socket dépassent la taille d’un paquet TCP (unité de transmission maximale du support réseau, généralement au moins 1 096 octets). Si la taille des données disponibles est inférieure à nécessaire, attendez que toutes les données soient reçues, puis démarrez l’opération de lecture uniquement.

Dans l’exemple suivant, m_dwExpected correspond au nombre approximatif d’octets que l’utilisateur s’attend à recevoir. Il est supposé que vous le déclarez ailleurs dans votre code.

void CChatSocket::OnReceive(int nErrorCode)
{
   CSocket::OnReceive(nErrorCode);

   DWORD dwReceived;

   if (IOCtl(FIONREAD, &dwReceived))
   {
      if (dwReceived >= m_dwExpected) // Process only if you have enough data
         m_pDoc->ProcessPendingRead();
   }
   else
   {
      // Error handling here
   }
}

Pour plus d’informations, consultez Windows Sockets dans MFC, Windows Sockets : Utilisation de sockets avec archives, ainsi que l’API Windows Sockets 2.

Hiérarchie d'héritage

CObject

CFile

CSocketFile

Spécifications

En-tête : afxsock.h

CSocketFile ::CSocketFile

Construit un objet CSocketFile.

explicit CSocketFile(
    CSocket* pSocket,
    BOOL bArchiveCompatible = TRUE);

Paramètres

pSocket
Socket à attacher à l’objet CSocketFile .

bArchiveCompatible
Spécifie si l’objet de fichier est à utiliser avec un CArchive objet. Passez FALSE uniquement si vous souhaitez utiliser l’objet CSocketFile de manière autonome, comme vous le feriez pour un objet autonome CFile , avec certaines limitations. Cet indicateur modifie la façon dont l’objet CArchive attaché à l’objet CSocketFile gère sa mémoire tampon pour la lecture.

Notes

Le destructeur de l’objet se dissocie de l’objet socket lorsque l’objet sort de l’étendue ou est supprimé.

Remarque

Un CSocketFile fichier peut également être utilisé en tant que fichier (limité) sans CArchive objet. Par défaut, le paramètre bArchiveCompatible du constructeur a la CSocketFile valeur TRUE. Cela spécifie que l’objet de fichier est utilisé avec une archive. Pour utiliser l’objet de fichier sans archive, passez FALSE dans le paramètre bArchiveCompatible .

Dans son mode « compatible archive », un CSocketFile objet offre de meilleures performances et réduit le danger d’un « interblocage ». Un interblocage se produit lorsque les sockets d’envoi et de réception sont en attente les uns des autres, ou pour une ressource commune. Cette situation peut se produire si l’objet CArchive a travaillé avec la CSocketFile façon dont il le fait avec un CFile objet. Avec CFile, l’archive peut supposer que s’il reçoit moins d’octets qu’il n’a demandé, la fin du fichier a été atteinte.

Toutefois, les CSocketFiledonnées sont basées sur des messages ; la mémoire tampon peut contenir plusieurs messages. Par conséquent, la réception d’un nombre inférieur au nombre d’octets demandés n’implique pas la fin du fichier. L’application ne bloque pas dans ce cas, car elle peut le faire CFile, et elle peut continuer à lire des messages à partir de la mémoire tampon tant que la mémoire tampon n’est pas vide. La fonction CArchive ::IsBufferEmpty est utile pour surveiller l’état de la mémoire tampon de l’archive dans ce cas.

Pour plus d’informations sur l’utilisation des CSocketFilesockets Windows, consultez les articles Windows Sockets : Utilisation de sockets avec archives et de sockets Windows : exemple de sockets à l’aide d’archives.

Voir aussi

CFile, classe
Graphique hiérarchique
CAsyncSocket, classe
CSocket, classe