Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo y dos artículos complementarios se explican varios problemas en la programación de Windows Sockets. En este artículo se describe el bloqueo. Los otros problemas se tratan en los artículos : Windows Sockets: Orden de bytes y Windows Sockets: Convertir cadenas.
Si usa o deriva de la clase CAsyncSocket, deberá administrar estos problemas usted mismo. Si usa o deriva de la clase CSocket, MFC los administra por usted.
Bloqueos
Un socket puede estar en "modo de bloqueo" o "modo de bloqueo". Las funciones de sockets en modo de bloqueo (o sincrónico) no devuelven hasta que puedan completar su acción. Esto se denomina bloqueo porque el socket cuya función se llamó no puede hacer nada , se bloquea hasta que se devuelve la llamada. Una llamada a la Receive función miembro, por ejemplo, puede tardar mucho tiempo en completarse arbitrariamente, ya que espera a que se envíe la aplicación de envío (es decir, si usa CSocketo usa CAsyncSocket con bloqueo). Si un CAsyncSocket objeto está en modo de no bloqueo (funciona de forma asincrónica), la llamada devuelve inmediatamente y el código de error actual, recuperable con la función miembro GetLastError , es WSAEWOULDBLOCK, lo que indica que la llamada habría bloqueado si no se devolviera inmediatamente debido al modo . (CSocket nunca devuelve WSAEWOULDBLOCK. La clase administra el bloqueo por usted).
El comportamiento de los sockets es diferente en sistemas operativos de 32 y 64 bits (como Windows 95 o Windows 98) que en sistemas operativos de 16 bits (como Windows 3.1). A diferencia de los sistemas operativos de 16 bits, los sistemas operativos de 32 y 64 bits usan multitarea preventiva y proporcionan multiproceso. En los sistemas operativos de 32 y 64 bits, puede colocar los sockets en subprocesos de trabajo independientes. Un socket de un subproceso puede bloquearse sin interferir con otras actividades de la aplicación y sin dedicar tiempo de proceso al bloqueo. Para obtener información sobre la programación multiproceso, consulte el artículo Multithreading.
Nota:
En las aplicaciones multiproceso, puede usar la naturaleza de bloqueo de CSocket para simplificar el diseño del programa sin afectar a la capacidad de respuesta de la interfaz de usuario. Al controlar las interacciones del usuario en el subproceso principal y CSocket el procesamiento en subprocesos alternativos, puede separar estas operaciones lógicas. En una aplicación que no es multiproceso, estas dos actividades deben combinarse y controlarse como un único subproceso, lo que normalmente significa usar CAsyncSocket para poder controlar las solicitudes de comunicaciones a petición o invalidar CSocket::OnMessagePending para controlar las acciones del usuario durante una actividad sincrónica prolongada.
El resto de esta discusión es para programadores destinados a sistemas operativos de 16 bits:
Normalmente, si usa CAsyncSocket, debe evitar el uso de operaciones de bloqueo y operar de forma asincrónica en su lugar. En las operaciones asincrónicas, desde el punto en el que recibe un código de error WSAEWOULDBLOCK después de llamar Receivea , por ejemplo, espera hasta OnReceive que se llame a la función miembro para notificarle que puede leer de nuevo. Las llamadas asincrónicas se realizan llamando a la función de notificación de devolución de llamada adecuada del socket, como OnReceive.
En Windows, las llamadas de bloqueo se consideran un procedimiento incorrecto. De forma predeterminada, CAsyncSocket admite llamadas asincrónicas y debe administrar el bloqueo usted mismo mediante notificaciones de devolución de llamada. La clase CSocket, por otro lado, es sincrónica. Bombea mensajes de Windows y administra el bloqueo por usted.
Para obtener más información sobre el bloqueo, consulte la especificación de Windows Sockets. Para obtener más información sobre las funciones "Activado", vea Windows Sockets: Notificaciones de socket y Windows Sockets: derivación de clases de socket.
Para obtener más información, consulte: