none
Errors in MC-DPL4CS RRS feed

  • Question

  • I hope this is the correct place to report this.

    While comparing the MC-DPL4CS specs with real DirectPlay traffic observed on the wire, I noticed following discrepancies:

     * Page 17, Size does not cover the whole structure, it's 4 bytes too small.
     * Page 17, There is an undocumented dword betweem !PlayerVersion and !ShortName.
     * Page 22, The length of PlayerIDs is PlayerCount * 4 bytes, not 4 bytes
     * Page 23, The length of ShortcutIDs is ShortcutCount * 4 bytes, not 4 bytes
     * Page 26, Reserved1 seems used for a DirectPlayID in all captures I have.
     * Page 34, The Command Value for DPSP_MSG_ADDFORWARDREQUEST is 0x13 not 0x24
     * Page 34, After PasswordOffset, there is a structure almost like PackedPlayer, just without the ParentID
     * Page 35, TickCount looks more like an DirectPlayID.
     * Page 45, The Command Value for DPSP_MSG_CREATEPLAYER is 0x8 not 0x9.
     * Page 46, After PlayerInfo, there seems to be an empty unicode string, probably the password. That is there even if PasswordOffset is 0.
     * Page 47, The Command Value for DPSP_MSG_CREATEPLAYERVERIFY is 0x38 not 0x9.
     * Page 81, The fourth bit of Flags is always 1 in all captures I have.


    Cheers,
    Kai
    Sunday, March 2, 2008 10:49 PM

Answers

  •  

    Kai,

     

    Of the 12 issues that you brought to our attention, 9 of them have resulted in minor changes to our technical documentation.  One of the issues was confirmed as not being a documentation bug.

     

    Here are the details of the changes.  We continue to work on the remaining 2 issues and will post the results to this forum.

     

    Regards,

     

    Jim Reynolds - MSFT

     

    -------------------------------------------------------------------------------------------------------------------------

     

    #1. Page 17, Size does not cover the whole structure, it's 4 bytes too small.

     

    The description of the value for the Size field has been updated.

     

    Correction:

     

    Section 2.2.2 DPLAYI_PACKEDPLAYER

     

    Size (4 bytes): MUST contain the total size of the DPLAYI_PACKEDPLAYER structure, plus the values of the ShortNameLength, LongNameLength, ServiceProviderDataSize, and PlayerDataSize fields.

     

     

    #2.Page 17, There is an undocumented dword between !PlayerVersion and !ShortName.

     

    The ParentID field was incorrectly located in the packet. Its correct location is between the PlayerVersion and ShortName fields.

     

    Correction:

     

    Please see:  Section 2.2.2 DPLAYI_PACKEDPLAYER

     

     

    #3.Page 22, The length of PlayerIDs is PlayerCount * 4 bytes, not 4 bytes

     

    The description of the PlayerIDs field has been updated.

     

    Correction:

     

    Section 2.2.3 DPLAYI_SUPERPACKEDPLAYER

     

    PlayerIDs (variable): If the Player ID Count field is nonzero, this MUST be set to a list of player IDs that are contained in the group. The length of this field is equivalent to the value of the PlayerCount field multiplied by four.

     

     

    #4.Page 23, The length of ShortcutIDs is ShortcutCount * 4 bytes, not 4 bytes

     

    The description of the ShortcutIDs field has been updated.

     

    Correction:

     

    Section 2.2.3 DPLAYI_SUPERPACKEDPLAYER

     

    ShortcutIDs (variable): If the ShortcutIDCount field is nonzero, this MUST be set to a list of shortcut IDs. The length of this field is equivalent to the value of ShortcutIDCount multiplied by four.

     

     

    #5.Page 26, Reserved1 seems used for a DirectPlayID in all captures I have.

     

    The description of the Reserved1 field has been updated. In addition, more information about how player and group identifiers are constructed has been added to section 3.2.5.4.

     

    Correction:

     

    Section 2.2.5 DPSESSIONDESC2

     

    Reserved1 (4 bytes): MUST be set to a unique value that is used to construct the player and group ID values. For more information about how this value is used to construct player and group identifiers, see section 3.2.5.4.

     

    -----------------

    Section 3.2.5.4 DPSP_MSG_REQUESTPLAYERID

     

    Note  32-bit player and group identifiers are constructed as follows:

        1. A zero-based value not shared by an existing identifier is assigned

            in the lowest 16 bits of the identifier.

        2. A zero-based value that is incremented to provide uniqueness for

            each identifier is assigned in the highest 16 bits of the identifier.

        3. The resulting 32-bit identifier value is bitwise XOR'd with the unique

            value specified in the Reserved1 field of the DPSESSIONDESC2 message.

            Although player IDs are allocated sequentially (and starting from a random

            value), because the random value is XOR'd with this unique value, there is

            no guarantee that the distributed player ID values will be sequential. For

            more information, see section 5.1.

     

     

    #6.Page 34, The Command Value for DPSP_MSG_ADDFORWARDREQUEST is 0x13 not 0x24

     

    The content has been updated to identify the correct Command Value for the DPSP_MSG_ADDFORWARDREQUEST message which is 19 (0x13). In addition, the description of the Command Values for all of the DPSP_MSG_* messages has been corrected and expanded to identify decimal and hex values in the message topic files.

     

    Correction:

     

    Section 2.2.11 DPSP_MSG_ADDFORWARDREQUEST

     

    DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 19 (0x13).

     

     

    #7.Page 34, After PasswordOffset, there is a structure almost like PackedPlayer, just without the ParentID

     

    We are still looking into this.

     

     

    #8.Page 35, TickCount looks more like an DirectPlayID.

     

    The technical team confirms that the current document is correct and that this is a TickCount, not a DirectPlayID.

     

     

    #9.Page 45, The Command Value for DPSP_MSG_CREATEPLAYER is 0x8 not 0x9.

     

    The description of the Command Value for the DPSP_MSG_CREATEPLAYER packet has been corrected to 8 (0x08), which is also the value identified in the table in section 2.2.6.

     

    Correction:

     

    Section 2.2.21 DPSP_MSG_CREATEPLAYER

     

    DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 8 (0x08).

     

     

    #10.Page 46, After PlayerInfo, there seems to be an empty unicode string, probably the password. That is there even if PasswordOffset is 0.

     

    We are still looking into this.

     

     

    #11.Page 47, The Command Value for DPSP_MSG_CREATEPLAYERVERIFY is 0x38 not 0x9.

      

    The description of the Command Value for the DPSP_MSG_CREATEPLAYER packet has been corrected to 8 (0x08), which is also the value identified in the table in section 2.2.6.

     

    The description of the Command Value for the DPSP_MSG_CREATEPLAYERVERIFY packet has been corrected to 56 (0x38), which is also the value identified in the table in section 2.2.6.

     

    Correction:

     

    Section 2.2.21 DPSP_MSG_CREATEPLAYER

     

    DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 8 (0x08).

     

    Section 2.2.22  DPSP_MSG_CREATEPLAYERVERIFY

     

    DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 56 (0x38).

     

     

    #12.Page 81, The fourth bit of Flags is always 1 in all captures I have.

     

    The description of the Flags field for the DPSP_MSG_REQUESTPLAYERID packet has been corrected.

     

    Correction:

     

    Section 2.2.49 DPSP_MSG_REQUESTPLAYERID

     

    Flags (4 bytes): Flag values. MUST be set to one or more of the following:

     

        SP (1 bit): The player is the system player.

     

         X (2 bits): All bits with this label SHOULD be set to 0 when sent,

            and MUST be ignored when received.

        PL (1 bit): The player is on the sending machine. This flag does not

            have meaning on other machines and MUST be ignored.

     

        Y (28 bits): All bits

     

     

    Wednesday, March 12, 2008 12:57 AM
  • Hi Kai,

     

    I wanted to let you know that the [MC-DPL4CS] protocol document has been updated to address the discrepancy you found in DPSP_MSG_CREATEPLAYERVERIFY.

     

    The following field updates were made to section 2.2.22 in order to address the discrepancy

     

    2.2.22 DPSP_MSG_CREATEPLAYERVERIFY

    Reserved1 (2 bytes):  SHOULD be set to 0 on transmission and MUST be ignored on reception.

    Reserved2 (4 bytes):  SHOULD be set to 0 on transmission and MUST be ignored on reception.


    Sincerely,
    Will Gregg - MSFT

    Friday, November 14, 2008 9:02 PM

All replies

  • Hello Kai,
     
    Thank you for contacting Microsoft regarding Windows protocol documentation.   
     
    My name is Jim Reynolds and I am the consultant who will work with you and our Microsoft technical teams to resolve this issue.
     
    If possible, I would like to have the following information:
     
    1) Could you make available a Netmon or Wireshark network capture file (with frame numbers) that demonstrate the issues mentioned above?
    2) Can you let me know what systems and versions are at each of the endpoints?
    3) What applications are you running to reproduce this with?

    It is our pleasure to be of service to you.  Have a great day!
     
    Jim Reynolds - MSFT
    Microsoft Consulting Services

     
    Tuesday, March 4, 2008 5:21 AM
  • Hello Jim,

     Jim Reynolds - MSFT wrote:

    If possible, I would like to have the following information:
     
    1) Could you make available a Netmon or Wireshark network capture file (with frame numbers) that demonstrate the issues mentioned above?


    Sure. I can provide pcap dumps. What would be the best place to put them?

     Jim Reynolds - MSFT wrote:

    2) Can you let me know what systems and versions are at each of the endpoints?


    It's been a while since I created the captures I did myself, but I think I was working on Windows 2000 back then,  with and without DirectX9 installed. I have received a couple of traces from other users, I can only guess at their setups.

     Jim Reynolds - MSFT wrote:

    3) What applications are you running to reproduce this with?


    Most of the issues can probably be observed with the chat tool in the DirectX7 SDK. However, that program uses reliable delivery, making the traces a bit harder to read. I also have traces of real-world apps, such as Age of Empires 1, Anno 1602, Heroes of Might and Magic 3 and Stronghold. The issues I reported are consistent across all those programs, regardless of the DirectX version.

    Cheers,
    Kai Blin
    Tuesday, March 4, 2008 7:33 AM
  • Kai,

     

    Thanks for the information.

     

    As you can see, we are just getting started with this forum and are still working out the kinks.  Obviously, the ability to transfer network captures is fundamental to our work.  We are discussing the best way to handle that for now.  I'll get back to you soon and let you know what we have come up with.

     

    It would be great if we could just attach the file like email.  That is what I am accustomed to doing.  That apparently is not possible here.

     

    How do you normally handle this?

     

    Regards,

     

    Jim Reynolds

     

     

     

     

     

     

    Wednesday, March 5, 2008 1:08 AM
  • Jim,

     Jim Reynolds - MSFT wrote:

    It would be great if we could just attach the file like email.  That is what I am accustomed to doing.  That apparently is not possible here.


    How do you normally handle this?



    Most Open Source projects I've filed bug reports for so far have an issue tracker like bugzilla that does allow you to attach patches and other files. So yes, being able to attach files to posts would be a useful and intuitive way to go.

    Cheers,
    Kai Blin
    Wednesday, March 5, 2008 10:17 AM
  • Kai,

     

    Please follow these instructions to transfer your files:

     

    ·         Select the following:

    https://sftus.one.microsoft.com/choosetransfer.aspx?key=c01d53f2-49e3-441d-b22e-d490a56c1d7d

    ·         Specify “send files to Microsoft”

    ·         Enter the following password:  F{%BPOB[BQFC

     

    From there it should be straight forward.

     

    We look forward to receiving this information so that we can help resolve these apparent documentation discrepancies.

     

    Regards,

     

    Jim

     

     

     

    Thursday, March 6, 2008 1:16 AM
  • Jim,

    I'm experiencing some issues trying to upload a capture file.

     Jim Reynolds - MSFT wrote:

    Please follow these instructions to transfer your files:

     

    ·         Select the following:

    https://sftus.one.microsoft.com/choosetransfer.aspx?key=c01d53f2-49e3-441d-b22e-d490a56c1d7d

    ·         Specify “send files to Microsoft”

    ·         Enter the following password:  F{%BPOB[BQFC

     

    From there it should be straight forward.



    Unfortunately nothing happens if I press the "Upload" button on that page. I've tested this from both Firefox and Konqueror.

    Any ideas?

    Kai
    Thursday, March 6, 2008 10:51 PM
  • Kai,

     

    Please use the following procedure to ftp your files to our product support site.

     

    1. At a command prompt, FTP to ftppss.microsoft.com.

    2. Log on as ANONYMOUS, and use your e-mail address as the password. For example, if your e-mail address is JoeSmith@microsoft.com, use that as your password.

    3. You are now logged on to the Microsoft FTP server.

    4. To change the directory, type the following command: cd /incoming/misc

    5. You are now in the correct directory to upload the file.

    6. The command to upload a file may vary based on the utility that you use. Typically the command is similar to the following:

    put filename

     

    Before you perform the command, make sure that you are in binary mode. For more information on how to set the FTP transfer mode to binary, see the following example of an FTP session:

     

    C:\Users\deskmachine>ftp ftppss.microsoft.com

    Connected to ftppss.microsoft.com.

    220 Microsoft FTP Service

    User (ftppss.microsoft.comSadnone)): anonymous

    331 Anonymous access allowed, send identity (e-mail name) as password.

    Password:

    230-This is FTPPSS.MICROSOFT.COM.

    230 Anonymous user logged in.

    ftp> binary

    200 Type set to I.

    ftp> cd /incoming/misc

    250 CWD command successful.

    ftp> put yourfile.txt

    200 PORT command successful.

    150 Opening ASCII mode data connection for yourfile.txt.

    226 Transfer complete.

    ftp: 206 bytes sent in 0.17Seconds 1.25Kbytes/sec.

    ftp> ls

    200 PORT command successful.

    150 Opening ASCII mode data connection for file list.

    yourfile.txt

    226 Transfer complete.

    ftp: 8 bytes received in 0.01Seconds 1.60Kbytes/sec.

    ftp> quit

    221  Thank-you for using Microsoft products!

     

     

    The command sequence for the above session:

     

    ftp ftppss.microsoft.com

    anonymous

    youremail@msn.com                   (any email address)

    binary

    cd /incoming/misc

    put yourfile.txt

    ls

    quit

     

    Also, could you please post the names of the files that you ftp to us?

     

    Regards,

     

    Jim Reynolds - MSFT

     

    Friday, March 7, 2008 7:14 AM
  • Jim,

    thanks to a standardized protocol, ftp worked.

    I've uploaded a file called dplay7_9_chat_three.pcap

    This is a capture of three of the DirectX 7.1 SDK sample game lobby chat programs. One is running on "plain" Win2k, hosting the "game". The two programs that connect to  the game session are the  same binary,  just with DirectX9 installed. The trace should show all issues I reported.

    Cheers,
    Kai Blin
    Friday, March 7, 2008 8:29 AM
  • Hello Kai,

     

    Thanks for uploading your network trace file to our support ftp site.

     

    We are analyzing this information now.

     

    However, I can tell you that at least 9 of the 12 issues that you brought to our attention will result in documentation updates. 

     

    We thank you for pointing out these discrepancies in the current docs.

     

    Next week we'll send out more details of these fixes and update you on the remaining 3 issues.

     

    Regards,

     

    Jim Reynolds - MSFT

     

    Saturday, March 8, 2008 6:10 AM
  •  

    Kai,

     

    Of the 12 issues that you brought to our attention, 9 of them have resulted in minor changes to our technical documentation.  One of the issues was confirmed as not being a documentation bug.

     

    Here are the details of the changes.  We continue to work on the remaining 2 issues and will post the results to this forum.

     

    Regards,

     

    Jim Reynolds - MSFT

     

    -------------------------------------------------------------------------------------------------------------------------

     

    #1. Page 17, Size does not cover the whole structure, it's 4 bytes too small.

     

    The description of the value for the Size field has been updated.

     

    Correction:

     

    Section 2.2.2 DPLAYI_PACKEDPLAYER

     

    Size (4 bytes): MUST contain the total size of the DPLAYI_PACKEDPLAYER structure, plus the values of the ShortNameLength, LongNameLength, ServiceProviderDataSize, and PlayerDataSize fields.

     

     

    #2.Page 17, There is an undocumented dword between !PlayerVersion and !ShortName.

     

    The ParentID field was incorrectly located in the packet. Its correct location is between the PlayerVersion and ShortName fields.

     

    Correction:

     

    Please see:  Section 2.2.2 DPLAYI_PACKEDPLAYER

     

     

    #3.Page 22, The length of PlayerIDs is PlayerCount * 4 bytes, not 4 bytes

     

    The description of the PlayerIDs field has been updated.

     

    Correction:

     

    Section 2.2.3 DPLAYI_SUPERPACKEDPLAYER

     

    PlayerIDs (variable): If the Player ID Count field is nonzero, this MUST be set to a list of player IDs that are contained in the group. The length of this field is equivalent to the value of the PlayerCount field multiplied by four.

     

     

    #4.Page 23, The length of ShortcutIDs is ShortcutCount * 4 bytes, not 4 bytes

     

    The description of the ShortcutIDs field has been updated.

     

    Correction:

     

    Section 2.2.3 DPLAYI_SUPERPACKEDPLAYER

     

    ShortcutIDs (variable): If the ShortcutIDCount field is nonzero, this MUST be set to a list of shortcut IDs. The length of this field is equivalent to the value of ShortcutIDCount multiplied by four.

     

     

    #5.Page 26, Reserved1 seems used for a DirectPlayID in all captures I have.

     

    The description of the Reserved1 field has been updated. In addition, more information about how player and group identifiers are constructed has been added to section 3.2.5.4.

     

    Correction:

     

    Section 2.2.5 DPSESSIONDESC2

     

    Reserved1 (4 bytes): MUST be set to a unique value that is used to construct the player and group ID values. For more information about how this value is used to construct player and group identifiers, see section 3.2.5.4.

     

    -----------------

    Section 3.2.5.4 DPSP_MSG_REQUESTPLAYERID

     

    Note  32-bit player and group identifiers are constructed as follows:

        1. A zero-based value not shared by an existing identifier is assigned

            in the lowest 16 bits of the identifier.

        2. A zero-based value that is incremented to provide uniqueness for

            each identifier is assigned in the highest 16 bits of the identifier.

        3. The resulting 32-bit identifier value is bitwise XOR'd with the unique

            value specified in the Reserved1 field of the DPSESSIONDESC2 message.

            Although player IDs are allocated sequentially (and starting from a random

            value), because the random value is XOR'd with this unique value, there is

            no guarantee that the distributed player ID values will be sequential. For

            more information, see section 5.1.

     

     

    #6.Page 34, The Command Value for DPSP_MSG_ADDFORWARDREQUEST is 0x13 not 0x24

     

    The content has been updated to identify the correct Command Value for the DPSP_MSG_ADDFORWARDREQUEST message which is 19 (0x13). In addition, the description of the Command Values for all of the DPSP_MSG_* messages has been corrected and expanded to identify decimal and hex values in the message topic files.

     

    Correction:

     

    Section 2.2.11 DPSP_MSG_ADDFORWARDREQUEST

     

    DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 19 (0x13).

     

     

    #7.Page 34, After PasswordOffset, there is a structure almost like PackedPlayer, just without the ParentID

     

    We are still looking into this.

     

     

    #8.Page 35, TickCount looks more like an DirectPlayID.

     

    The technical team confirms that the current document is correct and that this is a TickCount, not a DirectPlayID.

     

     

    #9.Page 45, The Command Value for DPSP_MSG_CREATEPLAYER is 0x8 not 0x9.

     

    The description of the Command Value for the DPSP_MSG_CREATEPLAYER packet has been corrected to 8 (0x08), which is also the value identified in the table in section 2.2.6.

     

    Correction:

     

    Section 2.2.21 DPSP_MSG_CREATEPLAYER

     

    DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 8 (0x08).

     

     

    #10.Page 46, After PlayerInfo, there seems to be an empty unicode string, probably the password. That is there even if PasswordOffset is 0.

     

    We are still looking into this.

     

     

    #11.Page 47, The Command Value for DPSP_MSG_CREATEPLAYERVERIFY is 0x38 not 0x9.

      

    The description of the Command Value for the DPSP_MSG_CREATEPLAYER packet has been corrected to 8 (0x08), which is also the value identified in the table in section 2.2.6.

     

    The description of the Command Value for the DPSP_MSG_CREATEPLAYERVERIFY packet has been corrected to 56 (0x38), which is also the value identified in the table in section 2.2.6.

     

    Correction:

     

    Section 2.2.21 DPSP_MSG_CREATEPLAYER

     

    DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 8 (0x08).

     

    Section 2.2.22  DPSP_MSG_CREATEPLAYERVERIFY

     

    DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 56 (0x38).

     

     

    #12.Page 81, The fourth bit of Flags is always 1 in all captures I have.

     

    The description of the Flags field for the DPSP_MSG_REQUESTPLAYERID packet has been corrected.

     

    Correction:

     

    Section 2.2.49 DPSP_MSG_REQUESTPLAYERID

     

    Flags (4 bytes): Flag values. MUST be set to one or more of the following:

     

        SP (1 bit): The player is the system player.

     

         X (2 bits): All bits with this label SHOULD be set to 0 when sent,

            and MUST be ignored when received.

        PL (1 bit): The player is on the sending machine. This flag does not

            have meaning on other machines and MUST be ignored.

     

        Y (28 bits): All bits

     

     

    Wednesday, March 12, 2008 12:57 AM
  • Kai,

     

    We have two remaining issues from your original forum post.  Our developers were not able to resolve these because your previous network trace files apparently did not include examples of these bugs.

     

    Here they are:

     

     

    #7.Page 34, After PasswordOffset, there is a structure almost like PackedPlayer, just without the ParentID

     

     

    [Please upload a network trace file that demonstrates this issue.]

     

     

    #10.Page 46, After PlayerInfo, there seems to be an empty unicode string, probably the password. That is there even if PasswordOffset is 0.

     

     

    [Please upload a network trace file that demonstrates this issue.]

     

     

    Also, could you tell us which version of wireshark you are using to capture this data?

     

     

    thanks,

     

     

    Jim Reynolds -MSFT

     

    Thursday, March 27, 2008 6:36 PM
  •  Jim Reynolds - MSFT wrote:

    We have two remaining issues from your original forum post.  Our developers were not able to resolve these because your previous network trace files apparently did not include examples of these bugs.

     

    ...

     

    Also, could you tell us which version of wireshark you are using to capture this data?


     


    Hm, I might have seen that in another trace, I'll recheck and upload a different trace if it's not in the first one.

    The dissector should be in SVN wireshark > r24535.


    Cheers,

    Kai

    Wednesday, April 2, 2008 10:26 PM
  • Hi Kai,

     

    Thanks for letting us know the Wireshark version number. We'll watch the upload site for an upload from you. If you see the issue in one of the previous captures let us know and we'll take a look

     

    Sincerely,

    Will Gregg - MSFT

    Friday, April 4, 2008 4:30 AM
  • Hi Will, Jim,

    sorry for the long lag in getting back to you.

    I've not been able to find issue #7 in my captures anymore. I'll keep looking, but let's ignore that one for now.

    However, issue #10 is most definitely in the capture I uploaded. Looking at packets 13, 34 and 35. In the DPSP_MSG_PACKET, there's a DPSP_MSG_CREATEPLAYER message. After the 90 bytes of PackedPlayer structure, there are an additional 6 bytes of zero. Given that neither the msg_packet nor the msg_createplayer should have trailing nulls, it seems like that's a discrepancy with the protocol.

    I hope that'll help with the archeology,
    Kai
    Thursday, April 17, 2008 3:15 PM
  • Hi Kai,

     

    No problem at all. Thanks for the additional information. We'll continue to investigate Issue #10 with the information you provided.

     

    Sincerely,

    Will Gregg - MSFT

     

    Tuesday, April 22, 2008 11:34 PM
  • Hi Kai,

     

    I wanted to let you know that the [MC-DPL4CS] protocol document has been updated to address the discrepancy you found in DPSP_MSG_CREATEPLAYERVERIFY.

     

    The following field updates were made to section 2.2.22 in order to address the discrepancy

     

    2.2.22 DPSP_MSG_CREATEPLAYERVERIFY

    Reserved1 (2 bytes):  SHOULD be set to 0 on transmission and MUST be ignored on reception.

    Reserved2 (4 bytes):  SHOULD be set to 0 on transmission and MUST be ignored on reception.


    Sincerely,
    Will Gregg - MSFT

    Friday, November 14, 2008 9:02 PM