none
WCF dual channel problem RRS feed

  • Question

  • Scenario:

    Using nettcpbinding, self-hosted service.  Service endpoint uses fixed port; client endpoint uses any free port (determined at run time and passed to the service).

    Scenario 1:

    • Client opens a listener - OK.
    • Client contacts service (opens/closes channel) - OK
    • Service opens channel and contacts client - OK

    Scenario 2:

    • Client opens a listener - OK.
    • Client opens channel, makes a method call over the channel, then closes channel - OK
    • Service cannot then connect to the client - CommunicationException ("Socket connection aborted") thrown.
    • Client opens channel, makes method call over channel, then closes channel - OK

    So the client will accept connections from the service until the first method call is made from the client to the service.  Once the client has made a call, the service cannot contact the client, but the client can still contact the service.

    • I have examined WCF tracing - just repeats the "Socket connection aborted" message.
    • I have tried closing the client listener before the call to the service and reopening it after - no difference.

    Client is XP, service hosted on Win Svr 2008 R2.  Using .NET 4

    At this juncture, moving to duplex channel isn't an option.

    Any thoughts?

    Friday, June 3, 2011 11:18 AM

Answers

  • The problem appears resolved.  I had used declarative impersonation (i.e.

    [OperationBehavior(Impersonation=ImpersonationOption.Required)]
    public void Method( ... )
    {
    }

    I switched this to imperative impersonation:

    public void Method( ... )
    {
    ...
        using(ServiceSecurityContext.Current.WindowsIdentity.Impersonate)
        {
            ....
        }
    ...
    }


    and the problem went away!  I hope this is helpful to others.


    • Marked as answer by rjcUK Thursday, June 9, 2011 1:54 PM
    Thursday, June 9, 2011 1:54 PM

All replies

  • Hello, if you want the service to call client, do not close the channel on the client side. Leave it open, and you will be fine.
    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Windows Azure Technical Forum Support Team Blog
    Monday, June 6, 2011 2:53 AM
  • Thank you for your suggestion, Yi-Lun.  Unfortunately we have tried this and the problem persists.  We now think that it's related to authentication (we're using impersonation) and results from an initial test support this theory.  I will carry out some further work on this; if it does prove to be related to authentication / impersonation, I'll post my findings here in case anyone else is interested.
    Monday, June 6, 2011 8:10 PM
  • The problem appears resolved.  I had used declarative impersonation (i.e.

    [OperationBehavior(Impersonation=ImpersonationOption.Required)]
    public void Method( ... )
    {
    }

    I switched this to imperative impersonation:

    public void Method( ... )
    {
    ...
        using(ServiceSecurityContext.Current.WindowsIdentity.Impersonate)
        {
            ....
        }
    ...
    }


    and the problem went away!  I hope this is helpful to others.


    • Marked as answer by rjcUK Thursday, June 9, 2011 1:54 PM
    Thursday, June 9, 2011 1:54 PM