Никакая связь не могла быть установлена, потому что целевая машина активно отказалась от него?

Иногда я получаю следующую ошибку, в то время как я делал HttpWebRequest к WebService. Я скопировал свой код ниже также.


System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:80
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.InternalConnect(EndPoint remoteEP)
   at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetRequestStream()

ServicePointManager.CertificatePolicy = new TrustAllCertificatePolicy();
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);

request.PreAuthenticate = true;
request.Credentials = networkCredential(sla);
request.Method = WebRequestMethods.Http.Post;
request.ContentType = "application/x-www-form-urlencoded";
request.Timeout = v_Timeout * 1000;

if (url.IndexOf("asmx") > 0 && parStartIndex > 0)
{
    AppHelper.Logger.Append("#############" + sla.ServiceName);

    using (StreamWriter reqWriter = new StreamWriter(request.GetRequestStream()))
    {                        
        while (true)
        {
            int index01 = parList.Length;
            int index02 = parList.IndexOf("=");

            if (parList.IndexOf("&") > 0)
                index01 = parList.IndexOf("&");

            string parName = parList.Substring(0, index02);
            string parValue = parList.Substring(index02 + 1, index01 - index02 - 1);

            reqWriter.Write("{0}={1}", HttpUtility.UrlEncode(parName), HttpUtility.UrlEncode(parValue));

             if (index01 == parList.Length)
                 break;

             reqWriter.Write("&");
             parList = parList.Substring(index01 + 1);
         }
     }
 }
 else
 {
     request.ContentLength = 0;
 }

 response = (HttpWebResponse)request.GetResponse();
228
задан BalaRam 31 May 2019 в 00:46
поделиться

2 ответа

Наиболее вероятная причина - брандмауэр.

Эта статья содержит ряд причин. Это может быть вам полезно.

Возможными причинами из статьи могут быть:

  • Настройки FTP-сервера
  • Настройки программного обеспечения / персонального брандмауэра
  • Несколько программных / персональных брандмауэров
  • Антивирусное ПО
  • Уровень LSP
  • Маршрутизатор Прошивка
  • Компьютер выключен
  • Компьютер не подключен
30
ответ дан 23 November 2019 в 03:47
поделиться

Если это происходит всегда, это буквально означает, что машина существует, но на ней нет служб, прослушивающих указанный порт, или вас останавливает брандмауэр.

Если это случается время от времени - вы использовали слово «иногда» - и повторная попытка завершается успешно, скорее всего, это связано с тем, что на сервере имеется полный «невыполненный журнал».

Когда вы ожидаете принятия ed на слушающем сокете, вы помещаетесь в очередь. Это отставание ограничено и довольно короткое - значения 1, 2 или 3 не являются необычными - и поэтому ОС может быть не в состоянии поставить ваш запрос в очередь на «accept» для использования.

Задержка - это параметр функции listen - все языки и платформы в этом отношении имеют в основном один и тот же API, даже C # . Этот параметр часто настраивается, если вы управляете сервером, и, вероятно, он читается из какого-либо файла настроек или реестра. Узнайте, как настроить свой сервер.

Если вы написали сервер, у вас может быть тяжелая обработка при принятии вашего сокета, и ее лучше переместить в отдельный рабочий поток, чтобы ваш accept всегда был готов принимать соединения. Вы можете изучить различные варианты архитектуры, которые уменьшают создание очереди клиентов и их последовательную обработку.

Независимо от того, можете ли вы увеличить объем невыполненной работы сервера, вам действительно потребуется логика повторных попыток в коде клиента, чтобы справиться с этой проблемой, поскольку даже при длительном отставании сервер может получать много другие запросы на этот порт в то время.

В редких случаях маршрутизатор NAT может выдать эту ошибку, если его порты для сопоставлений будут исчерпаны. Я думаю, что мы можем отбросить эту возможность как слишком долгий шанс, поскольку маршрутизатор имеет 64K одновременных подключений к одному и тому же адресу / порту назначения до исчерпания.

189
ответ дан 23 November 2019 в 03:47
поделиться
Другие вопросы по тегам:

Похожие вопросы: