WCF: System.Net.SocketException - apenas uma utilização de cada endereço de soquete (protocolo / endereço de rede / porta) é normalmente permitido

votos
35

Eu tenho um serviço WCF e um aplicativo Web. aplicação web faz chamadas para este serviço WCF de forma contínua aka polling. Em nosso ambiente de produção, recebo este erro muito raramente. Desde então, este é um usuários de atividades internas não tinham conhecimento de quando este erro é lançada.

Não foi possível conectar-se a http: //localhost/QAService/Service.svc . Código de erro de TCP 10048: apenas uma utilização de cada endereço de soquete (protocolo / endereço de rede / porta) é normalmente permitido 127.0.0.1:80. ---> System.Net.WebException: Não é possível se conectar ao servidor remoto ---> System.Net.Sockets.SocketException: Somente uma utilização de cada endereço de soquete (protocolo / endereço de rede / porta) normalmente é permitida 127.0.0.1 : 80

Estou tendo problemas em reproduzir esse comportamento em nosso ambiente dev / qa. Tenho a certeza que a conexão do cliente é fechado em um bloco try..catch..finally. Ainda não entendo o que está causando esse problema .. qualquer conhecimento desta situação?

Nota : Eu olhei para esta questão SO , mas não parece estar respondendo o meu problema, por isso não se repita perguntas.

Publicado 27/08/2009 em 07:12
fonte usuário
Em outras línguas...                            


2 respostas

votos
59

Você está sobrecarregando a pilha TCP / IP. Do Windows (e eu acho que todas as pilhas de soquete na verdade) tem uma limitação do número de tomadas que podem ser abertos em seqüência rápida devido à forma como tomadas de ficar fechado em operação normal. Sempre que uma tomada é fechada, ela entra no estado TIME_WAIT para um determinado período de tempo (240 segundos IIRC). Cada vez que você consultar, um soquete é consumida fora do alcance dinâmico padrão (acho que seus cerca de 5000 portas dinâmicas apenas acima de 1024), e cada vez que pesquisa termina, se a tomada especial vai para TIME_WAIT. Se você consultar com freqüência suficiente, você acabará por consumir todas as portas disponíveis, o que resultará em erro TCP 10048.

Geralmente, WCF tenta evitar este problema através da partilha de ligações e coisas assim. Este é geralmente o caso com os serviços internos que não estão indo através da internet. Não tenho a certeza se alguma das ligações wsHttp apoiar o pool de conexão, mas a ligação do NetTcp deveria. Eu diria pipes nomeados não executar para esse problema. Eu não poderia dizer para a ligação do MSMQ.

Há duas soluções que você pode usar para contornar este problema. Você pode aumentar o intervalo de porta dinâmico, ou reduzir o período de TIME_WAIT. O primeiro é provavelmente a rota mais segura, mas se você está consumindo um volume extremamente alto de soquetes (que não soa como o caso para o seu cenário), reduzindo TIME_WAIT é uma opção melhor (ou os dois juntos.)

Alterar a Porta Dynamic Range

  1. Abrir regedit.
  2. Abrir chave HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters
  3. Editar (ou criar o DWORD) o valor MaxUserPort.
  4. Configurá-lo para um número maior. (Isto é, 65534)

Alterar o atraso TIME_WAIT

  1. Abrir regedit.
  2. Abrir chave HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters
  3. Editar (ou criar como DWORD) a TcpTimedWaitDelay.
  4. Configurá-lo para um número menor. O valor é em segundos. (Ou seja, 60 para 1 minuto de atraso)

Uma das soluções acima deve resolver o seu problema. Se persistir depois de alterar o intervalo de portas, eu veria tente aumentar o período de seu voto de modo que isso acontece com menos frequência ... que vai lhe dar mais margem de manobra para contornar o atraso de espera tempo. Eu mudaria o atraso tempo de espera como um último recurso.

Respondeu 27/08/2009 em 07:41
fonte usuário

votos
3

HttpClient, embora ele implementa IDisposable é um objeto compartilhado, você deve reduzir o número de casos, tanto quanto possível. Você pode sair com ter apenas um exemplo para toda a vida do seu aplicativo, em vez de um para cada pedido.

Eu escrevi sobre isso muito extensivamente na http://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

Respondeu 01/09/2016 em 19:09
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more