what is diff. btwn CSoket and CAsynsocket

Rajesh match

I gone through MSDN it mentioned that CSyncsocket can be used as blocking as well in nonbloicking i,e synchronous and asyncronous both where we can get event notification

while CSocket can used in only blocking mode i.e synchronous mode.

I am not getting this explanation.
Can anybody somebody clear this more briefly

toxcct

blocking sockets are sockets that are waiting for datas to be incoming... while nothing came to the recipient, it is blocked... Asynchronous sockets can set a timeout, that means that when no packets entered after a certain duration, the receive function passes to the next instruction...

TOXCCT >>> GEII power
[toxcct][VisualCalc]

Rajesh match

Thanx TOXCCT.

Could u explain this in terms of CSOcket and CAsyncsocket
according to MSDN CSyncsocket returns WSAEWOULDBLOCK but not CSocket.

As CSocket derived from CAsynsocket why we wold not override OnRecieve and called recieve method as its vitual

i think i am confused abt this operation

Anyone have good link abt this ...

Jim Crafton

read up on how recv/connect/send/etc work. The basics are that they all perform some work on a socket handle (like attempt to read data from it, connect to the address, etc). When the function returns it will return some error code. Typically the error code is 0, -1, or some value that indicates how many bytes were processed. A -1 value is generally an error. The difference in CSocket or CSyncsocket is whether the socket can be set to blocking mode. Blocking mode means that the functions (recv/connect/send/etc )will NOT return until the function is complete. So if you attempt to connect to a blocking socking using connect() (or whatever it's called on CSocket), the connect9) function will NOT return until a connection has been established. Likewise calling recv in blocking mode will mean that the recv() function will NOT return until it has been able to extract the specified number of bytes from the socket. If, however, you are using NON blocking sockets, then the functions will return immediately, and the return code will be -1. But it's not neccessarily an error. You need to call WSAGetLastError() to determine this. If this returns WSAEWOULDBLOCK, then this means that function completed OK, and it's potentially going to complete later on. Typically you create a socket, connect, set it's blocking mode, and then start trying to send/recv from it (assuming this is a client socket). With an asnych, or non blocking socket, you'll need to poll it from time to time to see if you can get any data from it. Polling can be done using a crude while loop, sleeping for X n umber of milliseconds, and then calling recv or send, or you can use the select() function to query if the socket is ready to be read from or written to. Alternately you can even fancier by using overlapped IO, and if you're a complete masochist, migraqte to the madness that is IO completion ports. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!

Rajesh match

Thanx JIM for information Typically you create a socket, connect, set it's blocking mode how we set the blocking mode for that.

Jim Crafton

look up ioctlsocket - this is a BSD style socket function and it operates on a valid socket handle. I don't know what the equivalent with CSocket would be. You might use it like so:

void setBlocking( SOCKET s, const bool& isBlockingSocket )
{
unsigned long val = isBlockingSocket ? 0 : 1;

    int err = ioctlsocket( s, FIONBIO, &val );
    if ( err == SOCKET\_ERROR ) {
            err = WSAGetLastError();
            //do some error handling here...
    }

}

¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!

Rajesh match

ok JIM i go through that Thax for for your explaination