Windows Sockets: Cómo funcionan los sockets con archivos

En este artículo se explica cómo se combina un objeto CSocket , un objeto CSocketFile y un objeto CArchive para simplificar el envío y la recepción de datos a través de Windows Socket.

El artículo Windows Sockets: Ejemplo de sockets usando archivos presenta la PacketSerialize función. El objeto de archivo del PacketSerialize ejemplo funciona de forma muy similar a un objeto de archivo pasado a una función Serialize de MFC. La diferencia esencial es que para los sockets, el archivo se adjunta no a un objeto CFile estándar (normalmente asociado a un archivo de disco), sino a un CSocketFile objeto . En lugar de conectarse a un archivo de disco, el CSocketFile objeto se conecta a un CSocket objeto .

Un CArchive objeto administra un búfer. Cuando el búfer de un archivo de almacenamiento (envío) está lleno, un objeto asociado CFile escribe el contenido del búfer. Vaciar el búfer de un archivo adjunto a un socket equivale a enviar un mensaje. Cuando el búfer de un archivo de carga (recepción) está lleno, el CFile objeto deja de leer hasta que el búfer vuelve a estar disponible.

La clase CSocketFile se deriva de CFile, pero no admite funciones miembro de CFile como las funciones de posicionamiento (Seek, GetLength, SetLengthetc.), las funciones de bloqueo (LockRange, UnlockRangeo ) o la GetPosition función . Todo el objeto CSocketFile debe realizar es escribir o leer secuencias de bytes en el objeto asociado CSocket o desde él. Dado que un archivo no está implicado, las operaciones como Seek y GetPosition no tienen sentido. CSocketFile se deriva de CFile, por lo que normalmente heredaría todas estas funciones miembro. Para evitar esto, las funciones miembro no admitidas CFile se invalidan en CSocketFile para iniciar una excepción CNotSupportedException.

El CSocketFile objeto llama a funciones miembro de su CSocket objeto para enviar o recibir datos.

En la ilustración siguiente se muestran las relaciones entre estos objetos en ambos lados de la comunicación.

CArchive, CSocketFile y CSocket

El propósito de esta aparente complejidad es protegerte de la necesidad de gestionar los detalles del socket por ti mismo. Cree el socket, el archivo y el archivo de archivos y luego empiece a enviar o recibir datos insertándolos en el archivo o extrayéndolos del archivo. CArchive, CSocketFile y CSocket administran los detalles en segundo plano.

Un CSocket objeto es realmente un objeto de dos estados: a veces asincrónico (el estado habitual) y a veces sincrónico. En su estado asincrónico, un socket puede recibir notificaciones asincrónicas del marco. Sin embargo, durante una operación como recibir o enviar datos, el socket se vuelve sincrónico. Esto significa que el socket no recibirá más notificaciones asincrónicas hasta que se haya completado la operación sincrónica. Dado que cambia los modos, puede, por ejemplo, hacer algo parecido a lo siguiente:

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

      ar >> str;
   }
}

Si CSocket no se implementaron como un objeto de dos estados, es posible recibir notificaciones adicionales para el mismo tipo de evento mientras estaba procesando una notificación anterior. Por ejemplo, puede obtener una OnReceive notificación al procesar un OnReceive. En el fragmento de código anterior, la extracción str del archivo podría provocar recursividad. Al cambiar de estado, CSocket evita la recursividad evitando notificaciones adicionales. La regla general es no tener notificaciones dentro de otras notificaciones.

En su modo "compatible con archivos", un objeto CSocketFile ofrece un mejor rendimiento y reduce el riesgo de un "interbloqueo". Un interbloqueo ocurre cuando los sockets de envío y recepción están esperando el uno al otro o esperando un recurso común. Esta situación puede producirse si el objeto CArchive funcione con la forma en que CSocketFile lo hace con un objeto CFile. Con CFile, el archivo puede suponer que si recibe menos bytes de los solicitados, se ha alcanzado el final del archivo. Sin embargo, con CSocketFile, los datos se basan en mensajes; el búfer puede contener varios mensajes, por lo que recibir menos del número de bytes solicitados no implica el final del archivo. La aplicación no se bloquea en este caso, ya que puede con CFile, y puede continuar leyendo mensajes desde el búfer hasta que el búfer esté vacío. La función IsBufferEmpty de CArchive es útil para supervisar el estado del búfer del archivo en tal caso.

Para obtener más información, vea Windows Sockets: Using Sockets with Archives (Uso de sockets con archivos).

Consulte también

Windows Sockets en MFC
CObject::Serialize