Windows Sockets: Secuencia de operaciones

En este artículo se muestra, en paralelo, la secuencia de operaciones de un socket de servidor y un socket de cliente. Dado que los sockets usan los objetos CArchive, estos son necesariamente sockets de flujo.

Secuencia de operaciones para una comunicación del socket de flujo

Hasta el punto de construir un objeto CSocketFile, la siguiente secuencia es precisa (con algunas diferencias de parámetro) para CAsyncSocket y CSocket. A partir de ese momento, la secuencia es estrictamente para CSocket. En la tabla siguiente se muestra la secuencia de operaciones para la configuración de la comunicación entre un cliente y un servidor.

Configuración de la comunicación entre un servidor y un cliente

Server Remoto
// construct a socket

CSocket sockSrvr;
// construct a socket

CSocket sockClient;
// create the SOCKET

sockSrvr.Create(nPort);1,2
// create the SOCKET

sockClient.Create( );2
// start listening

sockSrvr.Listen( );
// seek a connection

sockClient.Connect(strAddr, nPort);3,4
// construct a new, empty socket

CSocket sockRecv;

// accept connection

sockSrvr.Accept( sockRecv ); 5
// construct file object

CSocketFile file(&sockRecv);
// construct file object

CSocketFile file(&sockClient);
// construct an archive

CArchive arIn(&file, CArchive::load);

o bien

CArchive arOut(&file, CArchive::store);

- o ambos -
// construct an archive

CArchive arIn(&file, CArchive::load);

o bien

CArchive arOut(&file, CArchive::store);

- o ambos -
// use the archive to pass data:

arIn >> dwValue;

o bien

arOut << dwValue;6
// use the archive to pass data:

arIn >> dwValue;

o bien

arOut << dwValue;6
  1. Donde nPort es un número de puerto. Para obtener más información sobre los puertos, consulte Windows Sockets: Puertos y direcciones de socket.

  2. El servidor siempre debe especificar un puerto para que los clientes puedan conectarse. La llamada a Create también especifica una dirección de vez en cuando. En el lado del cliente, use los parámetros predeterminados, que solicitan a MFC que usen cualquier puerto disponible.

  3. Donde nPort es un número de puerto y strAddr es una dirección de máquina o una dirección de protocolo de Internet (IP).

  4. Las direcciones de la máquina pueden tener varias formas: "ftp.microsoft.com", "microsoft.com". Las direcciones IP usan el formato "número de puntos" "127.54.67.32". La función Connect comprueba si la dirección es un número de puntos (aunque no comprueba si el número es un equipo válido en la red). Si no es así, Connect asume un nombre de equipo de uno de los otros formularios.

  5. Cuando se llama a Accept en el lado del servidor, se pasa una referencia a un nuevo objeto del socket. Primero se debe construir este objeto, pero no llamar a Create por ello. Tenga en cuenta que si este objeto de socket se sale del ámbito, la conexión se cierra. MFC conecta el nuevo objeto a un manipulador SOCKET. Se puede construir el socket en la pila, como se muestra o en el montón.

  6. Tanto el archivo como el archivo de socket se cierran cuando se salen del ámbito. El destructor del objeto del socket también llama a la función miembro Close para el objeto del socket cuando este se sale del ámbito o se elimina.

Notas adicionales sobre la secuencia

La secuencia de llamadas que se muestran en la tabla anterior es para un socket de flujo. Los sockets de datagrama, que no tienen conexión, no requieren las llamadas CAsyncSocket::Connect, Listen y Accept (aunque opcionalmente se puede usar Connect). En su lugar, si se usa la clase CAsyncSocket, los sockets de datagrama usan las funciones miembro CAsyncSocket::SendTo y ReceiveFrom. (Si se usa Connect con un socket de datagramas, use Send y Receive). Dado que CArchive no funciona con datagramas, no use CSocket con un archivo si el socket es un datagrama.

CSocketFile no admite toda la funcionalidad de CFile; los miembros CFile como Seek, que no tienen sentido para una comunicación de socket, no están disponibles. Por este motivo, algunas funciones Serialize de MFC predeterminadas no son compatibles con CSocketFile. Esto es especialmente cierto en la clase CEditView. No se debe intentar serializar los datos CEditView a través de un objeto CArchive adjunto a un objeto CSocketFile mediante CEditView::SerializeRaw; use CEditView::Serialize en su lugar (no documentado). La función SerializeRaw espera que el objeto de archivo tenga las funciones, como Seek, que CSocketFile no admite.

Para más información, consulte:

Consulte también

Windows Sockets en MFC
CSocket (clase)
CAsyncSocket::Create
CAsyncSocket::Close