First, you can use stl containers for storing the messages that will be received by the direct play message handler, so that you can have them for processing, the way you want. Everytime, when a message will be received, you can put it in your message queue.

The other part of your application can poll the messages from your queue (if any) and process it accordingly.

A good approach is to create a wrapper around the directplay, and put the queue internal to it, application can poll the message from your network layer. This architecture will be ready to fit in any application that require the UDP based connectivity and communication.

The pseudocode will be something like the following.

Code:
int main(void)
{
	// Initialize COM

    	// Create DirectPlay8Peer Object

    	// Create DirectPlay8Address Objects

	// Configure Addresses

	// Configure player info (to add ourselves to the game)

	// Give user option...
	// Options:
	//	1) Host the game (at specific port & host migration, if required)  
	// 	2) Host game by calling IDirectPlay8Peer->Host();

	//	3) Connect any avaialble game session
	//		3.1) Enumerate the game session & join if found any
	// 		3.2) Connect game by calling IDirectPlay8Peer->Connect();


	bool bExit = false;

	while (!bExit)
	{
		while (!kbhit() )
		{
			// Check if any message is available

			// if yes, process it
		}

		// if any key is pressed, see if its your termination key, lets say escape
		// if it is, then make bExit = true;
	}

	// Release resources

    return 0;
}
Few words of caution.

1) Directplay NAT support is only for the loose NAT (you can see the details in the directx sdk)

2) Directplay p2p uses broadcast for communcation with all users/players. You may say, so what? but many people try to use p2p solutions at internet (trust me, I've seen such peoples, and you can't argue with them specially when they are your clients, anyway) but the if you enumerate the game at internet, it will work fine, just the message to DPNID = 0 will be dropped and you may have to spend alot of extra hours to figure out that what the **** is wrong with it. The quick fix is, when you get the broadcast message to send all the players, loop through all the connected players and send the message individually.

3) Directplay support with 3rd party APIs is *not* very good, as you would have seen that, direct play provides you the APIs and strucutures to communicate and never let you go very much deep inside, where-as there are many other libraries that require the socket handles and stuff like that, so you have to develop an additional layer over them, such that they can co-exist with each other. Offcourse this is where performance can be compromised.

4) DirectPlay is being depricated. Yup, thats true (if I'm not mistaken, then last I remember that it was being depricated)

5) If you have to option to switch to some other API, then have a look at RakNet