DirectPlay questions

[MrDoomMaster]

Of course my professor forces me to create a program using the worst network API ever made! lol.

Anyway, on to my questions:

I am creating a console program that will act as a server for a game. The thing is, when I call IDirectPlay8Peer->Host, it returns immediately and the program exits. To explain further, here is a rough outline of my program. Please keep in mine I'm using Peer to Peer networking:

int main(void)
{
    // Initialize COM

    // Create DirectPlay8Peer Object

    // Create DirectPlay8Address Objects

    // Configure Addresses

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

    // Host game by calling IDirectPlay8Peer->Host()

    system("pause");
    return 0;
}

Do you see the problem? See, when you host a peer to peer session, you initiate a message handler that intercepts all of the IDirectPlay8 messages. The program needs to continue handling these messages until it is somehow instructed to close, either by a remote disconnection or by the user closing the console window.

As soon as the host() function is called, it returns... causing the program to return after the user presses 'any key'.

I need a way to make the main() function not return (therefore terminating the program) after the host function is called, but I don't want to hender the program from handling DirectPlay networking messages.

Any ideas?

[Arjay]

Have you checked out the "DirectPlay C/C++ Tutorials" in MSDN?

Arjay

[MrDoomMaster]

None of those tutorials help.

In fact, this has nothing to do with DirectPlay. It has more to do with knowing how to keep the application from terminating until I signal it to.

[Arjay]

I didn't look at these tutorials real close, but they seemed to be complete applications, albeit windows apps. No matter, create an event and in your PFNDPNMESSAGEHANDLER, call SetEvent for the appropriate message(s) you wish to exit on. After the call to Host, use WaitForSingleObject() to wait on your event.

Arjay

[Ejaz]

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.

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

[ting88]

It is a nice sharing......