Re: CSocket, best way to wait for a reply?

You should investigate asynchronous sockets, which do not require you to
poll for results like you're currently doing in your while-sleep loop.
Instead, asynchronous sockets send your application a message when there's
been some socket activity that needs your attention.

See the MFCSocs example at
http://support.microsoft.com/default.aspx?scid=kb;en-us;185728 :

"The MFCSocs sample is a minimal MFC application that demonstrates how to
use the CSocket and CAsyncSocket classes to communicate in a Transmission
Control Protocol (TCP) connection. This sample is a dialog-based
application. Depending on the selection in the user interface, the
application can run either as a TCP server that listens on a certain TCP
port, or as a client that connects to a server on the same TCP port. "

Mike


"simon" <spambucket@xxxxxxxxxxxx> wrote in message
news:%23BVWnAuOFHA.3408@xxxxxxxxxxxxxxxxxxxxxxx
> Hi,
>
> I have a 'client' and a 'server', (both the same sub-classes of CSocket).
> Basically the client sends a message to the server and in turn the server
> sends a message back to the client.
> I allow a few seconds for the server to reply back to the client. Ideally
it
> should not take more than a few milliseconds.
> The client waits for it's reply, (recognized by a special header in the
> message).
>
> So what I have is a function that does something like...
>
> void MyMessage( void *pData, int nSize )
> {
> pMySocket->Send( pData, nSize );
>
> // wait for a reply from the server
> while( pMySocket->pReplyBuffer == NULL ){
> sleep(0); // give time back to the queue
> // wait for a few seconds only
> }
>
> // either timeout or no reply sent
> }
>
> // The server then receives the message sent
> // sends a reply back to the client
> // who in turn fills the void *pReplyBuffer
> //
> // once "pReplyBuffer" is no longer NULL I know that data has returned.
>
> But I have 2 problems
>
> 1) As you can see the wait is totally inadequate. it hangs the system. So
> what would be the best way to wait for a few seconds?
> What I am doing now is ::PeekMessage( &msg, 0, 0, PR_REMOVE), but I don't
> feel good handling ALL the messages that way.
> PeekMessages only for socket ones does not seem to work and still causes
the
> system to hang.
>
> 2) Sometimes the Send(..) -> (who then calls the SendChunk() function),
> simply hangs and waits forever for the PumpMessages(FD_WRITE) to return.
> What could I be doing wrong.
>
> Many thanks
>
> Simon
>
>


.

Relevant Pages

  • Re: Netzwerkproblem GBit -> 100MBit
    ... GBit-Kette - flow control zwingend notwendig sei. ... zwischen Client und Server. ... Das kann TCP an der Stelle nicht mehr leisten. ...
    (de.comp.sys.novell)
  • suspect bug in vge(4)
    ... The high-level view of the problem is that the client seems to stall ... HTTPS server. ... not only printed for TLS/SSL issues but simply also for broken TCP ... To me it sounds like a broken implementation of hardware generated ...
    (freebsd-current)
  • Re: Log Out Issues
    ... UDP is the way to go for internet games. ... Apparently the extra overhead in TCP can cause a lot more lag in your game, ... >> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Log Out Issues
    ... your perormance may be worse than TCP. ... would be if your protocol anticipates packet loss and does not ... >>> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)
  • Re: [2.6.24.3][net] bug: TCP 3rd handshake abnormal timeouts
    ... server via TCP and non-persistent connections and all application level ... "Sometimes" when establishing a TCP connection to the server, ... Here is a simplified version of what _both_ the server and the client ...
    (Linux-Kernel)
Loading