??? CAsyncSocket

[jim enright]

have followed some sam's ... in 21 days code to make a desktop cleint and server app that should talk to each other - the attempts to connect fail because of WSAEWOULDBLOCK - the gist of the message is that the conneciton attempt is t a non-blockiing socket and it did not get an immediate reply.

reading up on the literature - non-blocking means synchronous and not asynchronous. and CAsyncSocket is supposed to be asynchronous.

how can i enforce blocking on CASyncSocket that i understand it should be doing already?

[ahoodin]

jim WSAEWOULDBLOCK is an error that means in a blocking call it would be blocked right now. The appropriate thing to do is to loop while the error is WSAEWOULDBLOCK. When you use non-blocking calls the responsibility goes to your shoulders to loop or wait for data to arrive.

[Richard.J]

when calling connect() on a non-blocking socket, it is no good advise to repeat that in a loop until success. Instead, call select() with that socket and wait for the appropriate event (the write_fd would contain that socket).

As to CAsyncSocket, there must be an event that is fired when the connection is established. I you want blocking behaviour, use CSocket. I personally must admit that the implementation of CAsyncSocket and especially CSocket seems a really poor one to me.

HTH,
Richard

[jim enright]

presume this is on the server side - the OnAccept() fn is triggered and then what happens?

would i place this in the onaccept fn:?

do while ( GetLastError = WSAEWOULDBLOCK){
;
}

if (GetLastError() = [whatever value says it's ok to proceed]){
}
else{
exit(0);
}


this has been exteremley frustrating since google searches for code that would show what the sam's books erroneously claim a workable
either:

dont work
dont compile
or cost something to suscribe to and i have no guarantee that they would work if i got a subscription to msdn

[ahoodin]

Honestly Jim I would chuck Sams right in the trash and just go with plain vanilla C Sockets.
Buy Practical TCP/IP Sockets in C :
http://cs.ecs.baylor.edu/~donahoo/practical/CSockets/
Heres the source that goes with the book:
http://cs.baylor.edu/~donahoo/PocketSocket/

[Richard.J]

http://msdn.microsoft.com/de-de/library/4th7tt74(VS.80).aspx

inside the OnAccept(), call Accept() and your server establishes (accepts) the connection to the client.

http://msdn.microsoft.com/de-de/library/xfaaxdxe(VS.80).aspx
The client that has called Connect and got an ...WOULDBLOCK will then get the OnConnect event and then knows whether the connection attempt was successful or not.

HTH,
Richard

[jim enright]

well i am confused beause a review of ms notes and blurbs on the subject indicates they favor asynchronous communications which as i understand it means blocking and when i use CAsyncSocket it is complaining that
nonblocking behavoir - ie synchronous activity - is screwing everything up

[jim enright]

if it is clear in my mind i can code it up - here is what am doing sequnece wise:

putting the server in listen mode

making the client attempt to connect to the server

the onaccept fn on the server side is triggered:

then what? the suggestion has been made to execute accept() inside the
onaccept. do i embed this in a while loop since there may not be an instaneous acceptance by the server of the connect request?

[Richard.J]

asynchronous means non-blocking: you call a function like connect, but the function returns immediately and the result can be retrieved only later. Once an asynchronous socket is connected and you call recv() on it (or recvfrom with UDP), there are 2 possibilities: either it returns with a non-error code because data has been available or it returns an error code indicating that there are currently no data in the queue.

synchronous on the other hand means blocking: a connect call will not return until either the connection is established or it is sure that it failed.

Got it?

cheers,
Richard

[Richard.J]

jim, if you receive the OnAccept it is clear that you can call Accept and an connection will be established. What else would the event be good for? Tell you that there might be a connection attempt, or maybe not?

Maybe you should read up on BSD socket first to get a basic understanding of the different types of sockets. CAsyncSocket and CSocket are just an abstraction layer above that (and not a good one, as I already said).
Maybe this is a good starting point:
http://www.tangentsoft.net/wskfaq/

cheers,
Richard

[jim enright]

actually i have been to the tangentsoft.net site and downloaded what was supposed to be a working vc++ project. i have looked at it and found it more useful to study than use because it simply does not compile. however, if it compiled i could examine its behavior and learn a hell of a lot more by observing it in the debugger.

my read of the CAsyncSocket (and i could very well be wrong) is that it is the de facto standard because it is asnchronous/blocking. are you telling me some underlying classes are better and compitable with windows/xp/vista or whatever they are calling what they are doing today?

[Richard.J]

I have not tried any of the samples on the website I recommended, but: asynchronous is non-blocking!
I personally think that if you understand the basics of "sockets" , then this may enable you to understand the intrinsics.

The MFC classes work, but they hide much of the lower layers. One might call that a good thing of abstraction, but my feeling is that you should learn about the basics.

BSD sockets are the basic, even one Windows. Whatever you know about them applies to Windows, the MFC socket classes, ... , with just tiny differences between Windows and any *IX.

[jim enright]

thanks - will dig into the links suggested. just have a healthy fear - borne from experience - when anyone seems to suggest i should dump all things windows and do unix (and vice versa).

not the biggest fan in the world of windos but have to deal with the reality that many things
have to be developed for it.

thanks

[ahoodin]

Winsock and UNIX have pretty much the same API. There are differences but you see the platform is not so much the issue as the API. Some APIs are just uglier and less expressive than others. Hence harder to deal with. Especially in the beginning where the basics are better learned with a purist approach. How does one jump to an advanced API without learning the basics?

[jim enright]

back at it again - this is from tangent soft:

# Blocking sockets - By default, a Winsock call blocks, meaning that it will not return until it has completed its task or has failed while trying.

# Pure Non-blocking sockets - Calls on non-blocking sockets return immediately, even if they cannot complete their task immediately. Although this allows the program to do other things while the network operations finish, it requires that the program repeatedly poll to find out when each request has finished.

# Asynchronous sockets - These are non-blocking sockets, except that you don't have to poll: the stack sends the program a special window message whenever something "interesting" happens.

am using class derived from CAsyncSocket as core of server app and as noted before it is failing. the def provided by tangentssoft states that async sockets do the dirty work of polling for you. if CAsyncSocket is asynchrounous and async sockets pool for you why is WSAEWOULDBLOCK being returned - the ms "dcoumentation" states that the reason this is returned is because the connection request was not returned immediately.

[Richard.J]

as stated in other threads, connect() might take some time to actually establish the connection. In the meanwhile, the TCP stack keeps trying, but the connect() function can not succeed immediately, thus the erro code. Later on, you'll get an event that now the connection is established.

Please read carefully this whole thread again, I already tried to explain what's going on.