Alan Cobb

Hi,
I have a simple WCF app using the NetTcp binding and a duplex contract.  I'm using InstanceContextMode.PerSession and the sessioning works fine.  What I don't understand is why I get different values for "SessionId" on the client and service side when using a duplex contract.  For a non-duplex contract the client and service are seeing identical "SessionId", which is what I would expect.  So why not also for a duplex contract  

Thanks,
Alan

Client code:

    String strSessionId =
        CMyService_ClientSideProxy.InnerChannel.SessionId;

    These return identical strings to strSessionId above:

    CMyService_ClientSideProxy . InnerChannel .
                                                          InputSession.Id;
    CMyService_ClientSideProxy . InnerChannel . 
                                                          OutputSession.Id;

    Example:
    "uuid:ea80a87c-df29-4b15-b10b-e241af5a2a56;id=1"


Service code:

    String strSessionId = OperationContext.Current.SessionId;

    Example:
    "uuid:1e8c30f4-b6d1-4816-a90c-0ca1076f2ed1;id=1"

    (Not the same as "ea80..." string the client gets).
   




Re: Windows Communication Foundation (Indigo) Client and service see different SessionId for a duplex contract?

Kavita Kamani - MSFT

For a duplex contract, there are two sessions, one for each side that initiated the session (input and output), thats why those session ids are different.




Re: Windows Communication Foundation (Indigo) Client and service see different SessionId for a duplex contract?

Alan Cobb

Then why do all three of these properties return the same string on the client side (for a duplex contract)   Based on what you said I would expect InputSession and OutputSession to be different.

    IClientChannel.SessionId;
    IClientChannel.InputSession.Id;
    IClientChannel.OutputSession.Id;

Note on the service side all three of the properties below return the same string, but it's different from the string the client sees above.

   OperationContext.SessionId;
   OperationContext.Channel.InputSession;
   OperationContext.Channel.OutputSession;

Thanks,
Alan






Re: Windows Communication Foundation (Indigo) Client and service see different SessionId for a duplex contract?

Kenny Wolf - MSFT

Session-ID is a way for one end of a channel to correlate messages. It is not required that these IDs are the same on both ends (though it is certainly possible and I believe the case for WS-RM) .

When you see the same ID on both ends (your "non-duplex contract" case) are you also using net.tcp Are they in separate app-domains In separate app-domains I'd be surprised if the session IDs are ever the same over net.tcp.






Re: Windows Communication Foundation (Indigo) Client and service see different SessionId for a duplex contract?

Alan Cobb

I did some more tests and you were right about the session IDs never being the same for the net.tcp binding, regardless of whether the contract is duplex or not.  (BTW: All my tests were with the client and service in different processes and hence different app-domains).

What confused me was that I did the tests first with the wsHttpBinding binding, where the session IDs seen by the client and service ARE identical, but that doesn't hold for the net.tcp binding.

So apparently the bottom line is that if you want some kind of per-session id that can be shared by both client and service you need to create it yourself.  Of course, it's not hard to create something like that in the service's constructor and pass it down to the client in response to the client's call that initiates the session.

Thanks,
Alan






Re: Windows Communication Foundation (Indigo) Client and service see different SessionId for a duplex contract?

Kavita Kamani - MSFT

When SecurityBindingElement or RM is on the stack to provide session capability, session id does flow with soap messages and both client/server sync up at that point with the same session id. It is when you use a transport that is sessionful inherently like tcp and you dont use security/RM, the session id will not flow with the message.