c # - Der er allerede en lytter på IP endpoint 0.0.0.0:13000. ?? (TCP bruger WCF)

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg forsøger at finde ud af, hvorfor havnen bliver brugt selv efter genstart af computeren!



  System.ServiceModel.AddressAlreadyInUseException: Der er allerede en lytter på IP endpoint 0.0.0.0:13000. Dette kan ske, hvis der findes en anden applikation, der allerede lytter på dette endepunkt, eller hvis du har flere serviceendemål i din servicevært med samme IP-endepunkt, men med inkompatible bindings konfigurationer. ---> System.Net.Sockets.SocketException: Kun en brug af hver sok-adresse (protokol/netværksadresse/-port) er normalt tilladt
         på System.Net.Sockets.Socket.DoBind (EndPoint endPointSnapshot, SocketAddress socketAddress)
         på System.Net.Sockets.SocketBind (EndPoint localEP)
         på System.ServiceModel.Channels.SocketConnectionListener.Listen ()
         --- Slut på indre undtagelse stak spor ---
         på System.ServiceModel.Channels.SocketConnectionListener.Listen ()
         på System.ServiceModel.Channels.TracingConnectionListener.Listen ()
         på System.ServiceModel.Channels.ConnectionAcceptor.StartAccepting ()
         på System.ServiceModel.Channels.ExclusiveTcpTransportManager.OnOpen ()
         på System.ServiceModel.Channels.TransportManager.Open (TransportChannelListener channelListener)
         på System.ServiceModel.Channels.TransportManagerContainer.Open (SelectTransportManagersCallback selectTransportManagerCallback)
         på System.ServiceModel.Channels.TcpChannelListener`2.OnOpen (TimeSpan timeout)
         på System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout)
         på System.ServiceModel.Dispatcher.ChannelDispatcher.OnOpen (TimeSpan timeout)
         på System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout)
         på System.ServiceModel.ServiceHostBase.OnOpen (TimeSpan timeout)
         på System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout)
         på Microsoft.Tools.SvcHost.ServiceHostHelper.OpenService (ServiceInfo info)
      System.Net.Sockets.SocketException (0x80004005): Kun én brug af hver stikkontakt (protokol/netværksadresse/port) er normalt tilladt
         på System.Net.Sockets.Socket.DoBind (EndPoint endPointSnapshot, SocketAddress socketAddress)
         på System.Net.Sockets.SocketBind (EndPoint localEP)
         på System.ServiceModel.Channels.SocketConnectionListener.Listen ()



Hvordan finder du ud af, hvilken proces der lytter til den havn (13000)? Netstat viser intet på den port.


Her er min App.config:


  <system.web>
    <compilation debug="true" />
  </system.web>
  <!-- When deploying the service library project, the content of the config file must be added to the host's 
  app.config file. System.Configuration does not support config files for libraries. -->
  <system.serviceModel>
    <services>
      <service name="SomeTarget.SomeTargetService">
        <endpoint address="" binding="customBinding" bindingConfiguration="NetTcpBinding"
          contract="SomeTarget.ISomeTargetService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexTcpBinding" bindingConfiguration=""
          contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="net.tcp://localhost:13000" />
          </baseAddresses>
        </host>
      </service>
    </services>

    <bindings>
      <customBinding>
        <binding name="NetTcpBinding" sendTimeout="00:05:00" closeTimeout="00:00:30" openTimeout="00:00:30" receiveTimeout="00:05:00">
          <transactionFlow />
          <binaryMessageEncoding />
          <windowsStreamSecurity protectionLevel="None" />
          <tcpTransport maxBufferPoolSize="524288"
                        maxReceivedMessageSize="1024"
                        maxBufferSize="1024" >
            <connectionPoolSettings groupName="default" leaseTimeout="00:05:00"
                                    idleTimeout="00:02:00" maxOutboundConnectionsPerEndpoint="20" />
          </tcpTransport>
        </binding>
      </customBinding>
    </bindings>

    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="false" httpsGetEnabled="false" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

</configuration>

Bedste reference


Jeg har oplevet dette problem efter installationen .Net 4.5 og er ved at sende en løsning her for at hjælpe andre, hvis de snuble i det. @berkayks svar ovenfor fungerede (eksponering af mex på en anden port), men jeg havde brug for at udsætte begge endepunkter gennem samme port.


Antag at du har to endepunkter, en der bruger netTcpBinding og en, der bruger mexTcpBinding.
Når du bruger standardbindingerne, beregnes nogle af standardværdierne ved hjælp af OSEnvironmentHelper.ProcessorCount i stedet for hardkodede værdier som de var i. Net 4.0.


I mit tilfælde, når du bruger en navngivet netTcpBinding-bindingskonfiguration, var værdien, der blev leveret til MaxConnections-ejendommen, 20 år. Indstillingen af ​​MaxConnections-egenskaben på NetTcpBinding indstiller også det s TcpTransportBindingElements s MaxPendingConnections-ejendom og TcpTransportens ConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint-ejendom til det samme værdi.


Når du ikke bruger en navngivet netTcpBinding-bindingskonfiguration og kun bruger standardværdien, blev egenskaben MaxPendingConnections beregnet ved hjælp af følgende algoritme:


 return (12 * OSEnvironmentHelper.ProcessorCount);


MexTcpBinding'ens transport har også beregnet det s MaxPendingConnections-egenskab ved hjælp af ovennævnte algoritme, så når ingen af ​​dem bruger en navngivet bindende konfiguration, matcher standardværdierne, og der er ikke noget problem.


Ved brug af en navngivet netTcpBinding-bindingskonfiguration var transportens MaxPendingConnections 20, og MaxPendingConnections på mexTcpBinding'ens transport var på min maskine 96. Forskellen i værdierne for MaxPendingConnections mellem disse to endepunkter, der deler samme port, er inkompatible.


Jeg fandt også ud af, at dette problem opstod med listen ListenBacklog.
(Jeg kender ikke til alle mulige modstridende værdier der kan eksistere.)


For at løse problemet kan du oprette en brugerdefineret binding til mex, der matcher den navngivne bindingskonfiguration for netTcpBinding. Eksempel nedenfor:


<endpoint binding="netTcpBinding" bindingConfiguration="TestNetTcpBinding"
      contract="YourContract" />
<endpoint address="mex" binding="customBinding" bindingConfiguration="TestMexBinding"
      contract="IMetadataExchange" />

<bindings>
<customBinding>
<binding name="TestMexBinding">
<tcpTransport maxPendingConnections="20" listenBacklog="20">                   
<connectionPoolSettings groupName="default"  maxOutboundConnectionsPerEndpoint="20" />
</tcpTransport>
</binding>
</customBinding>
<netTcpBinding>
<binding name="TestNetTcpBinding" listenBacklog="20" maxConnections="20"/>
</netTcpBinding>
</bindings>


Eller du kan ikke angive værdier, der beregnes (som maxConnections og listenBacklog) og acceptere standardindstillingerne (bemærk at MaxOutboundConnectionsPerEndpoint stadig beholder standardværdien på 10, da den ikke beregnes på samme måde som egenskaben MaxPendingConnections):


<binding name="TestNetTcpBinding" ...someOtherProperties except listenBacklog and maxConnections/>


Bemærk: Problemet er beskrevet her: http://msdn.microsoft.com/en-us/library/aa702636.aspx, men den eneste løsning er at udsætte mex på en anden port. Nedenfor er nogle skærmbilleder i reflektor, der viser forskellen mellem .net 4.0 og 4.5, når du beregner MaxPendingConnections-standardindstillingerne: [11]


. Net 4.0 ConnectionOrientedTransportBindingElement Beregning af standard MaxPendingConnections


. Net 4.5 ConnectionOrientedTransportBindingElement Beregning af standard MaxPendingConnections


. Net 4.5 GetMaxPendingConnections metode

Andre referencer 1


Jeg har det samme problem, efter at jeg installerede Visual Studio 2012 for at evaluere. Det ser ud til at normal service og mex service ikke kan dele samme port som det plejede at være i. NET 4.0 med samme config-fil (jeg ved ikke hvorfor, der skal være en grund). Kort sagt har jeg min serviceklient referencer på en anden samling og wpf ansøgning på en anden samling. Jeg offentliggjorde mex med en anden port som dette


<service name="X.XService.XService" behaviorConfiguration="myServiceBehavior">
            <endpoint address="" binding="netTcpBinding" bindingConfiguration="NetTcpBinding\_IXService" contract="X.XService.IXService">
                <identity>
                    <dns value="localhost" />
                </identity>
            </endpoint>
            <endpoint address="net.tcp://localhost:9103/XService/mex" binding="mexTcpBinding" bindingConfiguration="" contract="IMetadataExchange" />
            <host>
                <baseAddresses>
                    <add baseAddress="net.tcp://localhost:9102/XService" />
                </baseAddresses>
            </host>
        </service>


Min service referencemontage config


<endpoint address="net.tcp://localhost:9103/XService/mex"
            binding="netTcpBinding" bindingConfiguration="NetTcpBinding\_IXService"
            contract="XService.IXService" name="NetTcpBinding\_IXService">
            <identity>
                <dns value="localhost" />
            </identity>
        </endpoint>


Endelig min klient app config


    <endpoint address="net.tcp://localhost:9102/XService" binding="netTcpBinding"
            bindingConfiguration="NetTcpBinding\_IXService" contract="XService.IXService"
            name="NetTcpBinding\_IXService" behaviorConfiguration="endPointBehavior">
            <identity>
                <dns value="localhost" />
            </identity>
        </endpoint>

Andre referencer 2


Er du sikker på, at din tjeneste er den eneste der lytter til port 13000?


Kør netstat -noa | find "13000" før du starter dit program for at identificere, hvilken proces der har åbent port 13000. Nummeret i den øverste højre kolonne er proces-id.


Kør derefter tasklist | find "<pid>", hvor er ID'en af ​​processen fra den foregående kommando. Dette vil fortælle dig, hvilken proces der har 13000 åbne.

Andre referencer 3


netsat -anb (kræver administratorrettigheder) vil fortælle dig, hvad der lytter på alle porte ... hvis det ikke viser noget, har du sandsynligvis en fejl, hvor du forsøger at oprette endpoint mere end én gang.

Andre referencer 4


Har du. Net Framework 4.5 beta installeret? Jeg har set den samme fejl, når jeg kører på maskiner med 4,5, mens den løb perfekt på 4.0. Men så virker det igen, hvis jeg fjerner Mexico-endepunktet.


I mit tilfælde forårsagede noget i 4.5-ændringerne den samme fejlmeddelelse. Måske blev der skabt et automatisk mex-endepunkt eller noget.


Se heller ikke nogen anden app ved hjælp af porten, netstat viste intet. Så det var en slags selvfornægtelse ...

Andre referencer 5


Nå ... min arbejdede, da jeg skiftede målrammen til. Net Framework 4 Client Profile.


Prøv det ud ... håber det virker også for dig!