none
Logon Flags of multiple associated TCP Connections RRS feed

  • Question

  • I have used loadsim 2003 to geneate some outlook 2003 traffic. Supposed there are 10 TCP connections established which belong to the same association group, namely T1, T2, .... T10. 

    From the test I have observed different behavior in terms of issuing RopLogon(0xFE) ROP for a given logonid on a connection.

    Lets say T1 through T5 set the logon flag through its RopLogon(0xFE) ROP as following:

    T1: logonid=0 logonflag=0x00; logonid=1 logonflag=0x01; logonid=2 logonflag=0x01

    T2: logonid=0 logonflag=0x00; logonid=1 logonflag=0x01

    T3: logonid=0 logonflag=0x00; logonid=1 logonflag=0x01

    T4: logonid=1 logonflag=0x01; logonid=2 logonflag=0x01

    T5: logonid=0 logonflag=0x00; logonid=1 logonflag=0x01; logonid=2 logonflag=0x01

    However T6 through T10 skip issuing RopLogon ROP hence no logonflags are set for those connections.

    From the above the logonflags looks like the following within this association group:

    - logonid=0 logonflag=0x00

    - logonid=1 logonflag=0x01

    - logonid=2 logonflag=0x01

    Here comes my questions:

    1. Later on T2 issues RopSetMessageReadFlag(0x11) ROP for logonid(2).  Since there is no logonflags being set for this logonid(2) within T2. How will T2 behave in terms of setting ClientData field of ROP 0x11? Shall T2 always treat the logonflags as private for this logonid(2)? Or will T2 looks up the logonflags set by other connections within the same association group to determine?

    2. Later on when any of T6 through T10 issues RopSetMessageReadFlag(0x11) ROP for a given logonid, how will it treat its ClientData field? Do they also look up their association group logonflags for the logonid or just simply treat it as private?

    3. Would the above observation true for outlook 2k7 and 2k10 as well?

    Thanks,

    Baihan

     

    Friday, June 17, 2011 6:24 AM

Answers

  • Baihan,

    There is no connection between Logons and TCP connections within an association group.  There are logical sessions established on top of an association group (i.e. EcDoConnectEx).  These sessions are promiscuous across all TCP connections within the association group.  A RopLogon (and all its flags) are then built on top of the virtual session.  If you issue a RopLogon which happens to use one TCP connection in the association group it doesn't assign anything to a specific TCP connection, etc.  The logon like the session are a logical concept built up on top of the pooled TCP connections in the association group.

    I hope this helps.

    • Marked as answer by King Salemno Tuesday, July 19, 2011 5:11 PM
    Tuesday, July 19, 2011 5:11 PM

All replies

  • Baihan,

    Thank you for this inquiry. One of our engineers will look into this and follow-up with you soon.

    Thanks,

    Edgar

    Friday, June 17, 2011 2:59 PM
    Moderator
  • Baihan,

    I am the engineer who has taken ownership of your issue. I am currently investigating this and will update you as things progress.

    Tuesday, June 21, 2011 3:23 PM
  • Baihan,

    It is not clear what you are asking in regards to your scenario.

    Could you provide a more in-depth explanation of what you are inquiring?

    Thank you.

    Tuesday, June 28, 2011 2:23 PM
  • Baihan,

    Also, please check out the following forum thread: http://social.msdn.microsoft.com/Forums/en-US/os_exchangeprotocols/thread/34c2e52d-485a-498f-b81c-97d933df18c5

    Someone previously inquired about Outlook 2003's use of multiple TCP connections.

    Tuesday, June 28, 2011 2:49 PM
  • King,

    Thanks for the response. I have seen the thread above. 

    If the following conditions are true:

    T1, T2....T10 belong to an association group, which T1 through T5 create individual RPC context handle namely CXH1 through CXH5. Those connections issue RopLogon ROPs and set their logon flags indicated in the example. Therefore the logon flags would be the following:

    T1-CXH1: logonid=0 logonflag=0x00; logonid=1 logonflag=0x01; logonid=2 logonflag=0x01

    T2-CXH2: logonid=0 logonflag=0x00; logonid=1 logonflag=0x01

    T3-CXH3: logonid=0 logonflag=0x00; logonid=1 logonflag=0x01

    T4-CXH4: logonid=1 logonflag=0x01; logonid=2 logonflag=0x01

    T5-CXH5: logonid=0 logonflag=0x00; logonid=1 logonflag=0x01; logonid=2 logonflag=0x01

    In this example T6 through T10 do not create their own context handles. Since context handles are scoped to the association group the context handles CXH1-CXH5 can be shared by T1 through T10. 

    Based on the above please let me know whether my understanding is true for the below two scenarios:

    1. Since T2 sets logon flags for logon id 1 and 2 which belong to CXH1. Any RopSetMessageReadFlag(0x11) ROPs issued within this context handle shall only use logon flags from these logon ids to determine its ClentData field. When T2 jumps to CXH2 it shall follow logon flags setting within that context handle instead.

    2. For T6-T10 the similar behavior would be true. T6-T10 connection shall follow logon flags setting within the given context handle(CXH1-CXH5) to determine its ClientData field for ROP 0x11.

    Would the above understanding explain what I saw during testing with loadsim2003?

    Thanks,

    Baihan

     




    Tuesday, June 28, 2011 8:41 PM
  • Hi King,

    Could you please let me know if I misunderstood anything?

    Thanks,

    Baihan

    Saturday, July 9, 2011 12:22 AM
  • Baihan,

    I am looking into this.

    Monday, July 18, 2011 4:02 PM
  • Baihan,

    There is no connection between Logons and TCP connections within an association group.  There are logical sessions established on top of an association group (i.e. EcDoConnectEx).  These sessions are promiscuous across all TCP connections within the association group.  A RopLogon (and all its flags) are then built on top of the virtual session.  If you issue a RopLogon which happens to use one TCP connection in the association group it doesn't assign anything to a specific TCP connection, etc.  The logon like the session are a logical concept built up on top of the pooled TCP connections in the association group.

    I hope this helps.

    • Marked as answer by King Salemno Tuesday, July 19, 2011 5:11 PM
    Tuesday, July 19, 2011 5:11 PM
  • Thanks King for the answer.

    My earlier obserrvation was only based on TCP connections within an association group.  From what you've described and the document that I revisited such as MS-OXCRPC section 1.3.1. The following might be the right way to explain what I have seen:

    To acces EMSMDB interface the 10 loadsim users established 10 session contexts namely CXH1-CH10 via making call to EcDoConnectEx. These sessions are shared by all TCP conections within the same association group.  For a given session context a set of logon flags are established on a set of logon ids via any TCP connection from the pool.  These logonflags are scoped to the given session context. When a RopSetMessageReadFlag ROP is issued on a given logon id it shall determine its Clientdata field based on the logon flag set through RopLogon for the same session context handle.

    It looks like that we need to look at ROP processing in the context of this virtual session context rather than in the context of TCP conection. Please correct me if misinterpret what you've described.

    Thanlks,

    Baihan

    Thursday, July 21, 2011 9:49 PM
  • Hi King,

    I have one thing to be confirmed from you. Although the above test was conduced under loadsim 2003. What you've described is applicable for normal outlook operations as well. Please let me know.

    Thanks,

    Baihan

    Tuesday, July 26, 2011 7:35 PM