none
Question on Notifications RRS feed

  • Question

  • Hello,

    When the client sends a EcDoRpcExt2 request with no rops so that it can receive pending notifications from the server, what should the server do if there are no notifications to send? Should it send a response with no rops or should it hold on to the request till a notification is available?

    I checked MS-OXCNOTIF, but did not find the answer.

    The reason I'm asking is, I'm seeing a case where Outlook is sending the request with no rops, but the Exchange server is not responding. Outlook seems to be waiting for the server to respond as it's not sending any more requests - it's blocked. When you move the cursor over the Outlook icon in the taskbar, you see  'Outlook is requesting data from the server ...' (or something to that effect).

    Thanks,

    Hari

    Monday, March 21, 2011 1:12 AM

Answers

  • Hari,

    I have found some clarifying information on this issue.

    For every request, the server *must* return a response. If the client sends up a request with no Rop(s) and the server has nothing to return then the server returns an empty response. An empty response means the server still must return an RpcHeaderExt header ([MS-OXCRPC]) and the RopSize field of the Rop output buffer ([MS-OXCROPS]). (Please note that the RopSize can never be less than the value of 2 as it must include the RopSize parameter itself). Therefore, if there is no response RopSize field will have the value '2'.

    Also, it is not true that notificatoin information should *only* be returned if the request has no Rops. The server must process all Rops and place the results in the output buffer. After all request Rops have been processed, if there is room the server is FREE to return any server-to-client ROPs; these include RopNotify and RopPending mostly.  So if the request was all RopRelease it just means the output buffer is empty and the server free to return a bunch of server-to-client Rops.  The server is free to place as many RopNotify and RopPending ROPs into the output buffer as it wants.  The only caveat here is if the server is chaining Rop responses.  The server cannot add server-to-client Rops to a chained Rop response buffer.  Also, the server cannot chain a response if it has already added server-to-client Rops to the response.

     

     

    • Proposed as answer by King Salemno Monday, April 18, 2011 2:16 PM
    • Marked as answer by TH00 Monday, April 18, 2011 4:34 PM
    Monday, April 18, 2011 2:16 PM

All replies

  • Hi Hari:

    I have alerted protocol documentation team about your inquiry. A member of the team will be in touch soon.


    Regards, Obaid Farooqi
    Monday, March 21, 2011 4:16 PM
    Owner
  • Thanks Obaid.

    Related question: Isn't the server obligated to respond quickly to all EcDoRpcExt2 requests, even if the request has no rops?

    Hari

    Monday, March 21, 2011 4:56 PM
  • I have more info on this.

    Events from a packet trace made on exchange server (first number below is call-id):

    1039 - empty request for which there was no response

    1042 - FastTransfer request - server responded to this

    ... more requests for which server responded ...

    1077 - empty request - server responded to this with a Notify ROP

    Requests 1039 and 1042 were in the same ethernet packet. I have included the packet below. I have checked out two instances of this issue. In both cases the empty request PDU + the next request PDU were in the same ethernet packet. Is it possible that the server missed processing the empty request? Hard to believe as this would lead you to suspect the TCP stack, but I'm just reporting the pattern I observed. I can send the trace if anyone is interested.

     

    No.     Time        Size  CallId SPort  Source                Destination           Protocol Info
      30024 832.472304  258   10391042 3640   10.90.8.40            10.90.208.40          MAPI     EcDoRpcExt2 request + op_MAPI_FastTransferSourceGetBuffer[Packet size limited during capture]

    Frame 30024: 258 bytes on wire (2064 bits), 258 bytes captured (2064 bits)
    Ethernet II, Src: 00:30:48:8e:34:da (00:30:48:8e:34:da), Dst: 00:50:56:0e:03:54 (00:50:56:0e:03:54)
    Internet Protocol, Src: 10.90.8.40 (10.90.8.40), Dst: 10.90.208.40 (10.90.208.40)
    Transmission Control Protocol, Src Port: 3640 (3640), Dst Port: 45929 (45929), Seq: 1166185653, Ack: 623094955, Len: 204
    DCE RPC Request, Fragment: Single, FragLen: 100, Call: 1039 Ctx: 0
        Version: 5
        Version (minor): 0
        Packet type: Request (0)
        Packet Flags: 0x03
        Data Representation: 10000000
        Frag Length: 100
        Auth Length: 4
        Call ID: 1039
        Alloc hint: 60
        Context ID: 0
        Opnum: 11
        Auth type: SPNEGO (9)
        Auth level: Connect (2)
        Auth pad len: 4
        Auth Rsrvd: 0
        Auth Context ID: 2400816
        GSS-API Generic Security Service Application Program Interface
    Exchange 5.5/2003/2007/2010 EMSMDB, EcDoRpcExt2
        Operation: EcDoRpcExt2 (11)
        Pointer to Handle (policy_handle)
        Pointer to Pulflags (pulFlags)
        RgbIn Size: 10
        Cbin: 10
        Pointer to Pcbout (uint32)
        Pointer to Rgbauxin (mapi2k7_AuxInfo)
        Cbauxin: 0
        Pointer to Pcbauxout (uint32)
        Auth Padding (4 bytes)
    DCE RPC Request, Fragment: Single, FragLen: 104, Call: 1042 Ctx: 0, [Resp: #30025]
        Version: 5
        Version (minor): 0
        Packet type: Request (0)
        Packet Flags: 0x03
        Data Representation: 10000000
        Frag Length: 104
        Auth Length: 4
        Call ID: 1042
        Alloc hint: 0
        Context ID: 0
        Opnum: 11
        [Response in frame: 30025]
    Exchange 5.5/2003/2007/2010 EMSMDB, EcDoRpcExt2
        Operation: EcDoRpcExt2 (11)
        [Response in frame: 30025]
        Pointer to Handle (policy_handle)
        Pointer to Pulflags (pulFlags)
        RgbIn Size: 19
    [Packet size limited during capture: MAPI truncated]

    Frame (258 bytes):

    0000  00 50 56 0e 03 54 00 30 48 8e 34 da 08 00 45 00   .PV..T.0H.4...E.
    0010  00 f4 22 10 40 00 40 06 2a f0 0a 5a 08 28 0a 5a   ..".@.@.*..Z.(.Z
    0020  d0 28 0e 38 b3 69 45 82 94 b5 25 23 ac ab 50 18   .(.8.iE...%#..P.
    0030  20 00 69 1c 00 00 05 00 00 03 10 00 00 00 64 00    .i...........d.
    0040  04 00 0f 04 00 00 3c 00 00 00 00 00 0b 00 00 00   ......<.........
    0050  00 00 be 66 2e 7c 8d 35 6a 45 93 c9 48 b4 c0 69   ...f.|.5jE..H..i
    0060  f4 c1 00 00 00 00 0a 00 00 00 00 00 06 00 02 00   ................
    0070  02 00 a7 a5 00 00 0a 00 00 00 07 80 00 00 00 00   ................
    0080  00 00 00 00 00 00 88 00 00 00 b8 80 00 00 09 02   ................
    0090  04 00 30 a2 24 00 00 00 00 00 05 00 00 03 10 00   ..0.$...........
    00a0  00 00 68 00 04 00 12 04 00 00 00 00 00 00 00 00   ..h.............
    00b0  0b 00 00 00 00 00 be 66 2e 7c 8d 35 6a 45 93 c9   .......f.|.5jE..
    00c0  48 b4 c0 69 f4 c1 00 00 00 00 13 00 00 00 00 00   H..i............
    00d0  04 00 0b 00 0b 00 07 00 4e 00 00 00 7c a8 00 00   ........N...|...
    00e0  00 00 13 00 00 00 07 80 00 00 00 00 00 00 00 00   ................
    00f0  00 00 88 00 00 00 09 02 00 00 30 a2 24 00 00 00   ..........0.$...
    0100  00 00                                             ..


    Monday, March 21, 2011 9:44 PM
  • Did some more analysis. This issue happens with my software between outlook and the exchange server. Sorry for not disclosing this earlier.

    Please ignore the original issue, but the question originally posed is still an interesting one to answer - what should the server do if it receives an empty request but has no notifications to send?

    Below is the explanation for how this problem most probably happened:

    • There are two TCP connections in the same RPC association, say C1 and C2.
    • Outlook sent requests 1037-C1, 1038-C2, 1039-C1, 1042-C2 (call-id and connection).
    • C1 temporarily got held up by intermediate agent when processing 1037.
    • C2 was not held up, causing 1042 to reach the server.
    • C1 resumed, serviced 1037 locally (not sent to server) and sent 1039 to the server, causing the call-id to decrease. This must have caused the server to ignore that request (according to section 3.3.3.5.6 in MS-RPCE the server ignored the request instead of sending a fault response).

    Outlook seems to send parallel requests with different call-ids on different connections. I don't see how a client can do that because you cannot control the order in which these requests reach the server.

    Monday, March 21, 2011 10:22 PM
  • TH00,

    I am the engineer who has taken ownership of your issue and am currently investigating this matter.

    Thursday, March 24, 2011 6:48 AM
  • TH00,

    I am still investigating this matter.

    Thursday, March 31, 2011 4:01 AM
  • Have additional question, which is a corollary to the previous one:

    If a mapi request has only Release rops, the response would have no rops as Release does not have a Respnse rop. In this case, assuming the server has notifications pending, how is the server expected to behave? Send the empty response or nor? You would expect it to send the empty response.

    This question would apply to all rops for which there is no response rop.

    Thanks,

    Hari

    Monday, April 4, 2011 5:24 PM
  • Meant 'server has NO notifications pending' in previous question.
    Monday, April 4, 2011 5:25 PM
  • Hari,

    I am still investigating this matter.

    Tuesday, April 5, 2011 7:29 PM
  • Hari,

    To perform asynchronous notifications, the client sends the EcDoAsyncWaitEx RPC, and then the server waits until there is a notification for the client, or until 5 minutes have passed. (This depends on the version of Exchange Server being used). EcDoAsyncWaitEx is the only asynchronous RPC call. The rest (including EcDoRpcExt2) are all synchronous.

    Thus, the server did ignore the request instead of sending a fault response because there was no notifications to send.

    Please note the following thread: http://social.msdn.microsoft.com/Forums/en/os_exchangeprotocols/thread/217b3485-c70e-402c-9f62-a935e348c920

    I hope this assists you.

    • Proposed as answer by King Salemno Friday, April 8, 2011 6:09 PM
    Friday, April 8, 2011 6:09 PM
  • King,

    Thanks for the response. I was talking only about EcDoRpcExt2, not EcDoAsyncWaitEx.

    I had also described call-id issues, so that might have confused things.

    Let me restate the questions. The assumption is that the requests mentioned below satisfy all call-id requirements imposed by the server, so the server has no reason to ignore them or send a fault response.

    1. What should the server do if it receives an empty EcDoRpcExt2 request (i.e. no request rops) but has no notifications to send? Drop it or send an empty response?
    2. The corollary: If a mapi request has only Release rops, the response would have no response rops as Release does not have a response rop. In this case, assuming the server has no notifications pending, how is the server expected to behave? Send the empty response or not?

    Thanks,

    Hari

    Friday, April 8, 2011 11:24 PM
  • Question #2:

    Saw the exchange server send a response with no rops to a request that had only Release rops (in a packet trace).

    Monday, April 11, 2011 11:15 PM
  • Hari,

    I have found some clarifying information on this issue.

    For every request, the server *must* return a response. If the client sends up a request with no Rop(s) and the server has nothing to return then the server returns an empty response. An empty response means the server still must return an RpcHeaderExt header ([MS-OXCRPC]) and the RopSize field of the Rop output buffer ([MS-OXCROPS]). (Please note that the RopSize can never be less than the value of 2 as it must include the RopSize parameter itself). Therefore, if there is no response RopSize field will have the value '2'.

    Also, it is not true that notificatoin information should *only* be returned if the request has no Rops. The server must process all Rops and place the results in the output buffer. After all request Rops have been processed, if there is room the server is FREE to return any server-to-client ROPs; these include RopNotify and RopPending mostly.  So if the request was all RopRelease it just means the output buffer is empty and the server free to return a bunch of server-to-client Rops.  The server is free to place as many RopNotify and RopPending ROPs into the output buffer as it wants.  The only caveat here is if the server is chaining Rop responses.  The server cannot add server-to-client Rops to a chained Rop response buffer.  Also, the server cannot chain a response if it has already added server-to-client Rops to the response.

     

     

    • Proposed as answer by King Salemno Monday, April 18, 2011 2:16 PM
    • Marked as answer by TH00 Monday, April 18, 2011 4:34 PM
    Monday, April 18, 2011 2:16 PM
  • Thanks King. That closes this topic.

    Monday, April 18, 2011 4:35 PM