WCF: The socket connection was aborted

CommunicationException was unhandled by user code
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 '02:48:04.9840000'.

I've been testing this application for months and have just seen this error after making a small change to one of the services. It's only a few seconds, so I don't think it's a timeout issue.

InnerException: System.IO.IOException : The read operation failed, see inner exception

开发者_StackOverflow中文版(Inner) InnerException: System.Net.Sockets.SocketException - An existing connection was forcibly closed by the remote host.

Any suggestions are greatly appreciated!

Thanks in advance

Typically I have seen this error when the opposite party does not cleanly shut down the connection. If on the client side you have a class that inherits from ClientBase<T> then you should call Close when you are finished with the service (actually ClientBase<T> implements IDisposable so you can use a using statement).

If you are using a ChannelFactory<T> to create the connection to the service the result is a proxy that implements the contract but also implements ICommunicationObject; you should call Close on this when you are finished.

On the service side things are not the same, the session (and therefore the underlying socket) is managed by the client. If the service is dropping the socket most likely this is the result of an error, in which case Music Magi's suggestion is a good one. Microsoft talks about how to go about this here.

Note that to get a clear picture of what is going on you may have to set up tracing for both the client and the service. In order to view the traces you would use SvcTraceViewer which should be in the Program Files\Microsoft SDKs\Windows\v6.0A\bin or Program Files\Microsoft SDKs\Windows\v7.0A\bin folder. If you have to trace both the client and the service you can open both files together in SvcTraceViewer using the File / Add menu.

You are most likely running into quota issues like the MaxReceivedMessageSize, MaxArrayLength, MaxStringContentLength defined in the binding.

You can also have a look at the MaxItemsInObjectGraph attribute available in the behaviors.

I experienced some socket connection aborted for different reasons that I feel is worth an answer.

In addition to not having high enough values in your MaxReceivedMessageSize, MaxArrayLength, MaxStringContentLength, MaxItemsInObjectGraph as Johann pointed out...

Check to make sure the types that you're serializing play nicely with WCF. For example, I was having the same problem but then realized that I was sending System.DBNull over the wire which caused the service to abort. Once I filtered the DBNull objects out, things started working again.

In my case, there was an enum added to the response object but the stored procedure used to populate the object was not returning the value from the database. It was returning its default value (which is zero) which is not a valid value for the enum that was created. As an example :

using System;

namespace Playground
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            Console.WriteLine((int)new SomeResponse().Enum);
            Console.ReadLine();
        }

        public enum SomeEnum
        {
            Value1 = 1,
            Value2 = 2,
            Value3 = 3
        }

        public class SomeResponse
        {
            public SomeEnum Enum { get; set; }
        }
    }
}

You will see that the value of the enum is zero, even though there is no enum value of zero.

If you try to return the SomeResponse object from a WCF call and it has this state, you end up getting the same error as stated in the question.

in my case I was returning a Stream with a using clause on the stream. That closed the stream before it was sent and created the connection aborted error.

In my case we have two systems - the remoteSystem and the clientSystem

• Both systems have their public/private certificates for authentication.
• Each system has it's own private key, and the public key of it's peer.
• The client authenticates itself with the dev.clientSubsystem.acme cert

At first the firewall was suspected but this was eliminated by testing with

Test-NetConnection -Port 808 -ComputerName dev.remote-system.acme-corp.net-InformationLevel Detailed

It turned out this error was when the clientSystem is configured to authenticate with it's private held certificate (dev.clientSubsystem.acme) but the certificate doesn't exist - or in our case was referencing the wrong certificate for authentication.

<system.serviceModel>
   <client>
      <endpoint name="RemoteSystemService" address="net.tcp://dev.remote-system.acme-corp.net:808/service.svc" behaviorConfiguration="remoteSystemNetTcpBindingBehavior" binding="netTcpBinding" contract="AcmeCorp.RemoteSystem.IRemoteSystemService">
         <identity>
            <dns value="dev.remote-system.acme" />
         </identity>
      </endpoint>
   </client>
   <bindings>
      <netTcpBinding>
         <binding>
            <security mode="Transport">
               <transport clientCredentialType="Certificate" protectionLevel="EncryptAndSign" />
            </security>
         </binding>
      </netTcpBinding>
   </bindings>
   <behaviors>
      <endpointBehaviors>
         <behavior name="remoteSystemNetTcpBindingBehavior">
            <clientCredentials>
               <clientCertificate findValue="CN=dev.clientSubsystem.acme" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectDistinguishedName" />
               <serviceCertificate>
                  <authentication certificateValidationMode="PeerTrust" />
               </serviceCertificate>
            </clientCredentials>
         </behavior>
      </endpointBehaviors>
   </behaviors>
</system.serviceModel>