Socket connect opened many times in same machine with same request

[wyaow]

My issue is that when my web browser navigates to these url:
http://localhost:44382/api/Todo/3
http://localhost:44382/api/Todo

With command "netstat -nao | findstr 44382", It shows only one socket connection port opened during the whole time. The same even with more different HTTP Request.
While Use RestClient(Code below), It seems that every HTTP Request Creates a different socket connection port althought it will be released within a few minute.

for (int i = 1; i <= 10; i++)
{
	var client = new RestClient("http://localhost:44382/api/Todo/3");
	var request = new RestRequest();
	equest.Method = Method.GET;
	request.RequestFormat = DataFormat.Json;
	
       var asyncHandle = client.GetAsync<TodoClass>(request, (resp, callback) =>
	{
		Console.WriteLine(resp.Content);	
		callback.Abort();
	});
}

Is there a best way to avoid create different socket port by use one same socket?
look forward to get your reply !

[alexeyzimarev]

Well, you are creating a new instance of the client for each call, why are you surprised?

[wyaow]

While the same result when creating client only once.

var client = new RestClient("http://localhost:44382/api/Todo");
var request = new RestRequest();
request.Method = Method.GET;
request.RequestFormat = DataFormat.Json;

for (int i = 1; i <= 5; i++)
{
    var response = client.Get(request);
    var responseJson = response.Content;
}

[DynamicOperationsFacilitator]

Same result for me, using .net core 2.2 on Windows 10.

Start local nginx instance:

docker run -it -p 8888:80 nginx

Start loop to download index.html

using System;
using RestSharp;
using System.Threading;

namespace RestSharpRecycle
{
  class Program
  {
    static void Main(string[] args)
    {
      var client = new RestClient();
      while(true)
      {
        Thread.Sleep(10);
        var resp = client.Get(new RestRequest("http://127.0.0.1:8888/index.html", Method.GET));
        if(!resp.IsSuccessful) { throw new Exception(); }
        if(resp.Content.Contains("just-to-make-sure-we-access-Content")) { throw new Exception(); }
      }
    }
  }
}

Result is 360+ connections to the nginx instance in TIME_WAIT

netstat -ano  | select-string 8888 | select-string TIME_WAIT | measure-object

Count    : 366

The scenario implemented using System.Net.Http.HttpClient yields significantly less connections in TIME_WAIT.

using System;
using System.Threading;
using System.Net.Http;

namespace RestSharpRecycle
{
  class Program
  {
    static void Main(string[] args)
    {
      var client = new HttpClient();
      while(true)
      {
        Thread.Sleep(10);
        var res = client.GetAsync("http://127.0.0.1:8888/index.html").GetAwaiter().GetResult();
        res.EnsureSuccessStatusCode();
        var content = res.Content.ReadAsStringAsync().GetAwaiter().GetResult();
      }
    }
  }
}

This is the entire output from netstat when running that code.

netstat -ano  | select-string 8888

  TCP    0.0.0.0:8888           0.0.0.0:0              LISTENING       7872
  TCP    127.0.0.1:8888         127.0.0.1:54306        TIME_WAIT       0
  TCP    127.0.0.1:8888         127.0.0.1:54311        TIME_WAIT       0
  TCP    127.0.0.1:8888         127.0.0.1:54318        ESTABLISHED     7872
  TCP    127.0.0.1:54318        127.0.0.1:8888         ESTABLISHED     29832
  TCP    [::1]:8888             [::]:0                 LISTENING       7872

[fgiele]

Check what is written on:
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

This issue might be related to what is mentioned in that blog. I ran into this issue as well where I have to massively query a single server, seriously considering moving to a native HttpClient implementation to see if that resolves the issue.

[dyardyGIT]

We are having similar where restsharp works for a while, then it starts failing.

Right now we are creating new restsharp client on each request.

Ideas on the solution?

"Error:RestSharp.RestResponseSystem.Net.WebException: An error occurred while sending the request. Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ---> System.Net.Http.HttpRequestException: An error occurred while sen "

[alexeyzimarev]

RestClient was made thread-safe quite a while ago and I would suggest not instantiating it every time.

[alexeyzimarev]

@wyaow this Todo API, is this some .NET WebAPI? I'd like to test it.

[dyardyGIT]

made thread-safe quite a while ago and I would suggest not instantiating it eve

At the current moment, i am using singleton pattern via asp.net core / dependency injection / addSingleton and so re-using the client and still ending up with connection issues.

[dyardyGIT]

Check out this blog post which describes the multiple issues that we are running up against https://www.nimaara.com/beware-of-the-net-httpclient/

[alexeyzimarev]

It was already mentioned in the old issue. It doesn't help really. HttpClient and WebRequest are different things.

[dyardyGIT]

issue. It doesn't help really. HttpClient

Does this mean their solution does not work also (if you have tried it?) At this point, i am looking for work arounds/other solutions to this issue.

[lixiandai]

our team has exactly same issue and one of our team member confirmed using httpClient and httpRequest is correctly resuing the open connections there so we have to write our own client libaray instead of using the RestSharp

[devenr23]

RestSharp relies on HttpWebRequest. In .NET Core, HttpWebRequest was implemented by creating a new HttpClient instance each time it is used. So, connections are not reused. It looks like a fix for it that handles some scenarios has been merged. I reproduce the socket problems using RestSharp on .NET Core 2.2 and 3.0. So, RestSharp probably needs to be updated to use HttpClient. Microsoft is recommending that HttpWebRequest be moved away from.

Recommendation to stop using HttpWebRequest
Reported issue with HttpWebRequest in Core
Merged fix for it