I have created a client and server, and Im trying to track a packet. The server requests a file, the server picks up some information and throws it back, but the client never receives anything. It compiles fine, no errors/crashes. I can simulate this over and over - I have the process linked to a button on the client. Im using DirectPlay. Everything appears to be working finally, and I have validation that everything is processing up to the time of departure in the server code, but my client DP message handler never gets a message. Any idea how I can start to look for this lost packet?

You can try using a packet sniffer. (However, examining the contents of a DirectPlay packet can often be an exercise in frustration.)

Tried that, I couldnt see anything from it.

use a debugger on the client. Does it ever receive a packet?
Use a sniffer on the client computer - did the computer receive anything on the clients game port?

do the same on the server... You say you see the packet ''depart'' the server? Did you check the return value of the send call you used? Does the packet sniffer on the server show the outbound packet?

For a good packet sniffer, I''d recommend ethereal. It''s saved me a few times.

I got ethereal. I installed it on the server and client machines, it seems the packet isnt even being sent, although the code that would do so IS executing. I guess that would point directly to the Sendto call of my server. However, I cannot for the life of me test the return value. I setup a switch(HRESULT) to test the return value of the IDirectPlay8Server::SendTo call. However, its not finding the return value as any of the below:

DPNERR_CONNECTIONLOST
DPNERR_INVALIDFLAGS
DPNERR_INVALIDPARAM
DPNERR_INVALIDPLAYER
DPNERR_TIMEDOUT
S_OK
DPNSUCCESS_PENDING

Its not finding the return value to be any of these. Is there a better way to do this? Am I doing domething wrong?

> it seems the packet isnt even being sent

That can happen if

a) you haven''t specified the DPNSEND_GUARANTEED and you overwhelm the output queue with tons of messages in a single burst {unguaranteed messages get dropped at the sending end},

b) you have set a packet timeout value that is too short {thus causing them to get dropped before they get a chance to get queued out}, or

c) you are using polling mode {IDirectPlay8ThreadPool with a single thread} and you are not polling fast enough or the time slice is not large enough, or

d) your app is designed to open a comm link, shove data, and then close before exit, and there is simply not enough processing time to do everything {DirectPlay uses UDP, not TCP} before the app quits, or

e) You are using the DP8Sim TCP/IP Service Provider and somehow it has been set to let 0% packets {or some insanely low %} through.

Hope this helps.

-cb

a) My outgoing queue is really just this message, when I get this packet to the client, I will have 2 way communication.

b) How do you set the timeout? I dont know if I have any timeout specified.

c) Ill dont know what this is, but Ill check it out more when I get home.

d) Im safe here, its a continuous server.

e) I dont think this is the case, but Ill investigate it.

Thanks!

b) This isnt the case.

c) This isnt the case

e) This isnt the case.

OK, Im really going nuts here. The validation checks right before and after my SendTo() call go off every time. SendTo() returns a HRESULT value, which I tried checking by a switch statement, and it didnt alert me to any of the normal return handle values. So, checked the HRESULT value by casting an int, and it the value is the same before and after the damn SendTo() call!!! Its like everything before and after the SendTo() execute, but not the SendTo itself!!! If anyone has any more ideas let me know, I may have to post this somewhere to have someone look at it.

What''s the HRESULT ?

f) Async Connect() followed immediately by Send(). The Connect() doesn''t have the chance to get a formal connection established before the Send() is called, thus the packet is not even posted. Wait for the DPN_MSGID_CREATE_PLAYER message before making any transaction.

-cb

I found it. The problem was, I casted the packet wrong; I used an address when I shouldnt have. I guess the SendTo call saw the data as inaccurate and didnt send in response to that. Its funny how a single * can screw up a program like that

Thanks again for all the help!