Non-blocking socket question

[MasterDucky]

Im sorry it might not be the brightest question but when we talking about asynchronous or non-blocking (i think its the same) sockets,
we only talking about the server side, right?

I mean we can connect to it with the same client that we connected to blocking sockets?

[hoxsiew]

It doesn't matter. You can use a non-blocking socket on either side.

Asynchronous (as defined by MS) is technically different in that uses message triggers and callbacks to handle data asynchronously rather than using the TCP/IP stack mechanisms.

[MasterDucky]

Thanks a lot! :)

[MikeAThon]

Just to emphasize what hoxsiew has said ...

Asynchronous and non-blocking refer to two entirely different concepts. Non-blocking refers to the notion that a call to a socket function is guaranteed to return immendiately, even if there is no current activity on the socket. In contrast, for a blocking socket, a call to a socket function will block indefinitely, until there is some appropriate form of activity on the socket.

Asynchronous refers to the manner in which your sockets notify your application that there has been some activity. By way of explanation, suppose you have a blocking socket and you call recv(). The call to recv() will block until there is data in the buffer, so when the call to recv() returns, your application is notified (implicitly) that there has been activity. In contrast, for a non-blocking socket, the call will return immediately, even if there has not been any activity at all. In this scenario, the only way for your application to know that there has been activity is to poll for it (i.e., by calling recv() in a loop until it succeeds) or by using the select() function. Both of these activities are "synchronous" since it is your own application that determines for itself whether there has been activity on the socket, and since because it is the application that makes these determinations, the timing of these determinations is known precisely.

(Incidentally, polling for activity is a very bad idea and should never be done in an actual program. It's given here only to make the contrast with "asynchronous" more clear.)

In contrast, with asynchronous notifications, it's the OS that makes the determination that there has been activity on the socket, and it's the OS that sends some sort of trigger to your application that notifies your application of this activity. These notifications can arrive at any time, regardless of the current state of execution of your application. For this reason, the notifications are called "asynchronous".

The precise nature of the trigger depends on context. Usually, when speaking of asynchronous sockets, programmers are referring to GUI-based applications that run a message loop, and that use the WSAAsyncSelect() function so that the OS sends ordinary Windows messages to your app to notify it of socket activity. The content of the message identifies the socket for which there has been activity, as well as the nature of the activity.

Mike

[Payne747]

Thanks MikeAThon for the clarification, I've also been struggling to get to grips with non-blocking\Asynchronous sockets, though I do have a question about the following statement...

In this scenario, the only way for your application to know that there has been activity is to poll for it (i.e., by calling recv() in a loop until it succeeds) or by using the select() function.

I understand why polling is a bad idea, so when using non-blocking sockets, looping is the only way forward right? I assume you loop on recv() until it returns EWOULDBLOCK (suggesting there's nothing in the TCP buffer. Does this sound right?

Therefore, select() shouldn't be used (polling), what's the equilevent call on Linux systems for Asynchronous checks (WSAAsyncSelect())?

Thank you,

Payne747

[hoxsiew]

You've got it backwards. Looping is polling. select() blocks, but only for a specified time. If nothing happens during the timeout period, control returns to the program and it can do other things.

Since linux has no native messaging API like windows, you pretty much have to use select, or implement your own asynchronous system with threads.

[Payne747]

got it, so select() isn't really a bad thing, it's just not as good as an asynchronous solution, whatever that may be.

[MasterDucky]

Thank you very much Mike, thats exactly what i was wanting to know.

So for a Windows GUI application even select() will block the program, we should use asynchronous connection.

[Red Squirrel]

It took me a long time to figure out how to code non blocking sockets but I managed to figure it out and write a class for it. As long as you used a reasonable delay between the polls, it will be efficient. In fact, I was able to handle about 4000 connections streaming random data, in a single thread! Non blocking sockets are a real dream once you get a basic engine going. You can go a step further and add a couple threads to help take the load, to take advantage of multi cpu and make high performance server apps. That gets a bit more complicated though and you CAN run into performance issues if not done right.

[Payne747]

It took me a long time to figure out how to code non blocking sockets but I managed to figure it out and write a class for it.

I don't suppose you'd be willing to share the code for this class, or at least point me in the right direction to using the would-be blocking functions within? :)