PDA

View Full Version : Treatment of Client Data Areas Seems Pretty Flawed


DocMoriarty
26 Dec 2006, 05:32
I don't know whether anyone has worked with client data areas so far and can confirm this but i think the handling of client data areas is "flawed" to put it in diplomatic words (hey ACES!).

I have an exe and a dll client, trying to set data from the exe client into the dll clients data area but whatever i do, when i try to set data from the exe client into the dll clients data area i always get an exception event. The only time i got SetClientData() to work was when i used it right in the dll where i also created the data area. But it's not really thrilling to talk to myself (and no it is not the read only flag, i tried both default and read only).

Look at this declaration (a bit shortened):


_AddToClientDataDefinition(handle, DataDefineID, offset, size, reserved)


Where do i set the client data area id to which this friggin definition applies???
Is this a question of the sequence of calls to MapClientDataNameToID(...) and data definitions being significant??? If so this is plain CRAP, since the UDP transport doesn't guarantee message delivery in the correct order at all.

Edit

I finally got my example to work. It really seems that the order of MapClientDataNameToID() and AddToClientDataDefinition() IS significant. So hopefully the server uses the client/packet id for correct order or the association of a ClientDataDefineID to a ClientDataID won't work correct, especially not in a multiuser setup where clients communicate via internet and UDP packets might not be transferred in correct order.

A declaration that would avoid this problem would be:


_AddToClientDataDefinition(handle, ClientDataID, DataDefineID, offset, size, reserved)


I don't know why the example works now, it might really be the packets weren't transferred in the correct order. The only thing that i changed inbetween was that i initialized the dll clients data area by a call to SetClientData() inside the dll. After i did that i could send from my other clients. Then i took it out and it still worked ...

curious
26 Dec 2006, 10:17
SimConnect uses TCP instead of UDP, so all packets arrive in the order you call the API functions.

You can verify this with tools like Ethereal.

DocMoriarty
26 Dec 2006, 13:17
You are right, i just verified it with netstat. I always thought it uses UDP since that was what i have read in the forums so far.