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 CFile
la 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::SerializeRaw
de ; 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 CSocket
que 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
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 CSocketFile
donné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 CSocketFile
sockets 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