1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Treatment of Client Data Areas Seems Pretty Flawed

Discussion in 'SimConnect' started by DocMoriarty, 26/12/06.

  1. DocMoriarty

    DocMoriarty

    Joined:
    20/12/06
    Messages:
    64
    Country:
    germany
    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 ...
    Last edited: 26/12/06
  2. curious

    curious

    Joined:
    21/10/06
    Messages:
    9
    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.
  3. DocMoriarty

    DocMoriarty

    Joined:
    20/12/06
    Messages:
    64
    Country:
    germany
    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.

Share This Page