Windows Sockets: Como funcionam os soquetes com arquivos

Este artigo explica como um objeto CSocket , um objeto CSocketFile e um objeto CArchive são combinados para simplificar o envio e o recebimento de dados por meio de um Windows Socket.

O artigo Windows Sockets: Exemplo de soquetes usando arquivos apresenta a PacketSerialize função. O objeto archive no PacketSerialize exemplo funciona muito como um objeto archive passado para uma função MFC Serialize . A diferença essencial é que, para soquetes, o arquivo não é anexado a um objeto CFile padrão (normalmente associado a um arquivo de disco), mas a um CSocketFile objeto. Em vez de se conectar a um arquivo de disco, o objeto se conecta CSocketFile a um CSocket objeto.

Um CArchive objeto gerencia um buffer. Quando o buffer de um arquivo de armazenamento (envio) está cheio, um objeto associado CFile grava o conteúdo do buffer. Liberar o buffer de um arquivo anexado a um soquete equivale a enviar uma mensagem. Quando o buffer de um arquivo de carregamento (recebimento) está cheio, o objeto para de CFile ler até que o buffer esteja disponível novamente.

A classe CSocketFile deriva de CFile, mas não suporta as funções membro de CFile, como as funções de posicionamento (Seek, GetLength, SetLength, e assim por diante), as funções de bloqueio (LockRange, UnlockRange), ou a função GetPosition. Tudo o que o objeto CSocketFile deve fazer é gravar ou ler sequências de bytes de ou para o objeto associado CSocket . Como um arquivo não está envolvido, operações como Seek e GetPosition não fazem sentido. CSocketFile é derivado de CFile, por isso normalmente herdaria todas essas funções de membro. Para evitar isso, as funções de membro sem suporte CFile são sobrescritas em CSocketFile para lançar um CNotSupportedException.

O objeto CSocketFile chama funções de membro do seu objeto CSocket para enviar ou receber dados.

A figura a seguir mostra as relações entre esses objetos em ambos os lados da comunicação.

CArchive, CSocketFile e CSocket

O objetivo dessa aparente complexidade é protegê-lo da necessidade de gerenciar os detalhes do soquete por conta própria. Você cria o soquete, o ficheiro e o arquivo, e depois começa a enviar ou receber dados, inserindo-os no arquivo ou extraindo-os do arquivo. CArchive, CSocketFile e CSocket gerenciam os detalhes nos bastidores.

Um CSocket objeto é, na verdade, um objeto de dois estados: às vezes assíncrono (o estado usual) e às vezes síncrono. Em seu estado assíncrono, um soquete pode receber notificações assíncronas da estrutura. No entanto, durante uma operação, como receber ou enviar dados, o soquete torna-se síncrono. Isso significa que o soquete não receberá mais notificações assíncronas até que a operação síncrona seja concluída. Como ele alterna de modo, você pode, por exemplo, fazer algo como o seguinte:

void CMySocket::OnReceive(int nErrorCode)
{
   if (0 == nErrorCode)
   {
      CSocketFile file(this);
      CArchive ar(&file, CArchive::load);
      CString str;

      ar >> str;
   }
}

Se CSocket não foram implementados como um objeto de dois estados, talvez seja possível receber notificações adicionais para o mesmo tipo de evento enquanto você estava processando uma notificação anterior. Por exemplo, poderá receber uma OnReceive notificação enquanto processa um OnReceive. No fragmento de código acima, extrair str do arquivo pode levar à recursão. Ao alternar estados, CSocket evita a recursão impedindo notificações adicionais. A regra geral é a ausência de notificações nas notificações.

No seu modo "compatível com arquivo", um objeto CSocketFile oferece melhor desempenho e reduz o perigo de um "deadlock". Um deadlock ocorre quando os soquetes de envio e recebimento estão à espera um do outro ou aguardando um recurso comum entre si. Essa situação pode ocorrer se o CArchive objeto funcionasse com a CSocketFile da mesma maneira que funciona com um CFile objeto. Com CFile, o arquivo pode assumir que, se receber menos bytes do que os bytes solicitados, o fim do arquivo foi alcançado. Com CSocketFile, no entanto, os dados são baseados em mensagens; o buffer pode conter várias mensagens, portanto, receber menos do que o número de bytes solicitados não implica no fim do arquivo. A aplicação não bloqueia neste caso, como poderia fazer com CFile, e pode continuar a ler mensagens do buffer até que esteja vazio. A função IsBufferEmpty em CArchive é útil para monitorar o estado do buffer do arquivo em tal caso.

Para obter mais informações, consulte Windows Sockets: Usando soquetes com arquivos

Ver também

Windows Sockets no MFC
CObject::Serialize