locked
TCP (callback) channel being faulted when IPv6 network connection gets disabled RRS feed

  • Question

  • Hi there,

    I have a Windows Service hosted WCF Service with a TCP binding, whose ReceiveTimeout and ReliableSession.InactivityTimeout are set to TimeSpan.MaxValue, because the WCF-Endpoint uses a callback-contract, and I want that the server can always call-back to the client, no matter how long the client was idle (not sending anything over that channel).

    I also installed an IErrorHandler-Implementation in the WCFHost, where I write unhandled (server) exceptions to a logfile.

    I also have this client application, that usually runs on the same computer, but should also be able to run on a different pc (therefore I use the NetTcp-Binding).

    So far anything works well.

    Recently we had a customer running the client app on the same computer, and having only one ethernet connection (WiFi) with a USB-WiFi adapter. In the moment, the customer plugged out the USB-Wifi adapter, my ILoggerHandler-Implementation caught the following CommunicationException:

    TAsyncResult End[TAsyncResult](System.IAsyncResult) threw CommunicationException:
    The socket connection was aborted. This could be caused by an error processing your message
    or a receive timeout being exceeded by the remote host, or an underlying network resource issue.
    Local socket timeout was '10675199.02:48:05.4775807'.
      inner Exception: IOException: The read operation failed, see inner exception.
      inner Exception: CommunicationException: The socket connection was aborted. This could be caused
      by an error processing your message or a receive timeout being exceeded by the remote host, or an
      underlying network resource issue. Local socket timeout was '10675199.02:48:05.4775807'.
      inner Exception: SocketException: An established connection was aborted by the software in your host machine

    Because of this, the (callback) Channel to/from the service was faulted, and the server could no longe reach the client.
    In the moment the exception happened no client opertion was pending, so the client did not get any message that his channel to the Service has faulted (and I found no way of how the client could be notified about this).

    I could reproduce this issue by having only one active network connection with IPv6 enabled. Then I start my WCF-Service and the client. When I then disable the last IPv6 support for the network connections, the service gets the above mentioned CommunicationException.

    I checked my pc's IP addresses before and after the last IPv6 support was disabled:
    before:
    IP: fe80::856e:41c8:3efc:5d12%17
    IP: 192.168.223.185
    IP: 172.29.229.81

    after:
    IP: ::1
    IP: 192.168.223.185
    IP: 172.29.229.81

    It seems to me as if WCF uses the IPv6 address to establish the (callback) Channel, and when the IP-Address of that channel "goes away", WCF forcibly shuts down the channel, causing the CommunicationException on the server.

    When I start the server (and client) at the time all IPv6 connections are disabled, and then enable the IPv6 support, no Exceptions are thrown, even if I again disable IPv6 on all network connections.

    This raises two questions:
         * Is there a possibility on the client side to be notified about the channel being faulted at the time this happens (right now I have to send another request to the server to get the information that the "original" channel was faulted) ?
        * Is it possible to configure the TCP channels in such a way that they don't get faulted when the last active IPv6 network connection is being disabled ?

    Any suggestions are highly appreciated.

    Thursday, August 3, 2017 7:07 AM

Answers

  • Hi DSanchen,

    Do you mean you could work around the first issue by IErrorHandler?

    >> Is there a chance to have TCP-Channels not being shut down, when properties of network connections are changed ?

    For this, I am afraid it is impossible. The Channel is shut down by Duplex Channels, there is no properties for Duplex Channels to set network connections.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, August 7, 2017 1:53 AM

All replies

  • Hi DSanchen,

    >> Is there a possibility on the client side to be notified about the channel being faulted at the time this happens (right now I have to send another request to the server to get the information that the "original" channel was faulted) ?

    Based on your description, it seems you are developing with Duplex Service. If so, I am afraid there is no way except send another request to check the connection. Duplex Service is two one-way services. There is no response from service to client.

    >> Is it possible to configure the TCP channels in such a way that they don't get faulted when the last active IPv6 network connection is being disabled ?

    Do you mean you want to service not throw exception when the connection is shut down? If so, I am afraid not, the service will throw exception when it fails to connect to client. I think you could try catch this exception.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, August 4, 2017 7:17 AM
  • Hi Edward,

    thanks for your reply, and yes I am developing a Duplex Service.

    • You say Duplex Service is two one way services, I understand that. So my client is actually also a service just for the callback-channel. Based on that description, I realized that I can install an IErrorHandler into clientRuntime.CallbackDispatchRuntime.ChannelDispatcher to at least get the same CommunicationException in my client, knowing that the channel the client used is no longer usable.
    • The second question was rather that the connection does NOT get shut down in the first place. As this is a connection within one and the same machine, it would be nice if it would stay alive even if some networkt connections to the outside of the machine are changed. I don't understand why "internal" connections have to be shut down.

    Is there a chance to have TCP-Channels not being shut down, when properties of network connections are changed ?

    Best regards

    Friday, August 4, 2017 9:32 AM
  • Hi DSanchen,

    Do you mean you could work around the first issue by IErrorHandler?

    >> Is there a chance to have TCP-Channels not being shut down, when properties of network connections are changed ?

    For this, I am afraid it is impossible. The Channel is shut down by Duplex Channels, there is no properties for Duplex Channels to set network connections.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, August 7, 2017 1:53 AM
  • Hi Edward,

    Thanks for your reply. Yes, I think I can work around the first issue with an IErrorHandler implementation, where I handle the duplex channel being shut down.

    Thanks, and best regards

    Tuesday, August 8, 2017 6:00 AM