Windows message loops and Network code.

[KatieL]

I'm normally a UNIX developer and when doing X based code, integrating message handling and network handling is pretty simple; the message queue from X and the sockets are all effectively file descriptors, and then one can just select over the set of queues and sockets, and when that times out, you can paint the window pretty much when you feel like it.


I'm looking at doing some Windows code, and I'm wondering how one is supposed to integrate the network operations into the windows message loop. (I've done windows coding before, just nothing that's used both message handling AND networking..)

I can think of several solutions;

Let data queue up in the network ports and handle it in the idle message by polling for available data. (Though this is reliant on timely arrival of "idle" messages; which may not be that timely if the system is busy).

Handle it similarly in the paint message (that feels naughty somehow).

Have a thread doing the network comms, and posting custom messages to the main loop to get it to handle the data when complete network messages arrive.

Or can one get windows to have the sockets post messages when there's data available? (is this what IO completions are for? And are they available for connectionless sockets[1]?).


I'm really just after getting a handle on what's best practice in this area that's not going to upset the OS or other applications.





[1] I'm still pondering which to use. A solution that works for both would be good. To be honest, I've never had issues with connected links, but then I normally only run code over either local networks, or very carefully managed wans.

[MikeVitt]

Hello,

You can actually set Winsock to post messages when data or a connection is available. You should look into the WSA functions. I used this method when I first created my Winsock 2.2 library. Here is a good reference site for Winsock.

However, I ended up changing the design to allow for API-independent code. I poll for data and connections 50 times per second. I do this in my ProcessFrame() function, which also handles my input, game update, rendering, etc. I peek for messages and call the function when there aren't any in the queue. In addition, I call it if I receive a WM_PAINT message.

Hope that helps.

[Huge]

Hi,
There are a couple of ways of going.

You can create "events" to listen for incoming data, and use "MsgWaitForMultipleObjects" to act very much like a "select" call - it will return on an event, OR a windows message.

The easiest way is probably to start a thread for each network connection, and block in a "recv" call. When you get a complete data instruction, add it to the "incoming" stack.

Your main loop then goes flat-out doing something like:

while(PeekMessage( ))
{
// handle messages ...
}
while(incoming_stack( ))
{
// process network messages
}
Render()

If you force a render, and ignore wm_paint events, you will run as fast as possible. (if you ignore wm_paint, don't forget to do BeginPaint()/EndPaint() or else you will get flooded with wm_paint messages).

[KatieL]

"If you force a render, and ignore wm_paint events"

It's legal to paint the window without having received a WM_PAINT? Ah. Doing that and peeking for the windows messages, would mean the X11 and Windows code would have practically the same structure..

while(1)
{
While(events) {pull event, process event}
Poll network connections.
Non-painting work.
Paint the window.
}

I was trying to work out how to do all the various things inside the message handling, because I thought you could /only/ paint if you got a paint notification but if you can legally paint the window outside it, that tidies things up a lot - it sort of becomes an app which uses the message queue when it feels like it rather than one being driven by the queue.

[Fabio]

I think you can paint whenever you want, but you "MUST" paint if you get a WM_PAINT message, otherwise your window will remain corrupted by some other window that overdrew it.

Can anyone confirm? GDI is not my arena.

Also, as Huge said, even if you don't want to paint in response of a WM_PAINT message, do anyway BeginPaint / EndPaint so the OS thinks at least that you did.