Bug 55327 - Sockets in Xamarin
Summary: Sockets in Xamarin
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: Future Release
Assignee: Bugzilla
Depends on:
Reported: 2017-04-18 11:07 UTC by Gary Lowe
Modified: 2017-05-30 21:48 UTC (History)
9 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Gary Lowe 2017-04-18 11:07:13 UTC

We have an app which opens a tcp socket on a port to a server.
using net stat on the server I can see the connection is established and communication works as expected.

When the socket is closed net stat reports CLOSE_AWAIT and never disappears. You then get a build up of these.
I have tried the following code in a noddy iOS app and .net console app in Xamarin.
They both leave CLOSE_AWAIT which never go.

                IPAddress ipAddress = IPAddress.Parse("");
                IPEndPoint remoteEP = new IPEndPoint(ipAddress, 1234);

                // Connect to the remote endpoint.
                socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
                socket.BeginConnect(remoteEP, new AsyncCallback(Callback), socket);


If I run the same code in a visual studio console app the connection goes into CLOSE_AWAIT and after a few minutes gets released and disappears.
This appears to be the underlying implementation of Sockets in Xamarin are not closing the socket correctly
This appears to be a bug somewhere, could someone at Xamarin confirm this?

Xamarin Studio Community
Version 6.2 (build 1829)
Installation UUID: b27ad524-386e-4932-9735-45222199301c
	Mono 4.8.0 (mono-4.8.0-branch/e4a3cf3) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)


Comment 1 Vincent Dondain [MSFT] 2017-04-18 19:57:44 UTC

I did not manage to reproduce this. Couldn't see the results as described in the description but I am no expert in debugging socket issues.

It seems though that this is not a Xamarin.iOS only issue since you're also hitting the issue with a console project.

Let us reassign to the BCL and have someone from the runtime team help.

cc. Alex and Marek (feel free to add other people).

Also @gary please include your full build logs, crash reports (if any), test case (to reproduce) and all version informations.

The easiest way to get exact version information is to use the "Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details" button and copy/paste the version informations (you can use the "Copy Information" button).
Comment 2 Gary Lowe 2017-04-24 08:29:54 UTC
Hi Vincent

I had a simple app that had two buttons.
One opens the connection to the server.

I could then run the netstat command on windows server console and see the connection opened.

The other buttons runs the...

There is a windows service that runs on a port on a server.
The iOS app opens a connection to that a connection to that port on that server.

=== Xamarin Studio Community ===

Version 6.2 (build 1829)
Installation UUID: b27ad524-386e-4932-9735-45222199301c
	Mono 4.8.0 (mono-4.8.0-branch/e4a3cf3) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 408000495

=== NuGet ===


=== Xamarin.Profiler ===

'/Applications/Xamarin Profiler.app' not found

=== Apple Developer Tools ===

Xcode 8.3 (12169)
Build 8E162

=== Xamarin.iOS ===

Version: (Xamarin Studio Community)
Hash: ba11e48
Branch: cycle9
Build date: 2017-03-10 08:48:04-0500

=== Xamarin.Android ===

Not Installed

=== Xamarin Android Player ===

Not Installed

=== Xamarin.Mac ===

Version: (Xamarin Studio Community)

=== Xamarin Inspector ===

Not Installed

=== Build Information ===

Release ID: 602001829
Git revision: 3a28108feb03a6384702c96ffc8c548121cdf37c
Build date: 2017-03-12 06:55:23-04
Xamarin addins: 295d27f8dcdde049a1807a76c888fc0a6557357d
Build lane: monodevelop-lion-cycle9

=== Operating System ===

Mac OS X 10.12.3
Darwin MacBook-Pro-2.local 16.4.0 Darwin Kernel Version 16.4.0
    Thu Dec 22 22:53:21 PST 2016
    root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64
Comment 3 Gary Lowe 2017-05-08 08:52:28 UTC

Do you have any update on this?
We have seen this now at a few customer sites where


leaves CLOSE_WAIT on the server whereas the same call in Visual Studio leaves the CLOSE_WAIT but that disappears after a few minutes.
Comment 4 Gary Lowe 2017-05-30 13:54:59 UTC

Could I get an update on this please?
Comment 5 Miguel de Icaza [MSFT] 2017-05-30 15:50:16 UTC
This has an explanation of the problem:


This means that your client has communicated to the server that it has closed, and now it is the turn of the server to close the connection.  Look for CLOSE_WAIT description there.
Comment 6 Miguel de Icaza [MSFT] 2017-05-30 15:51:33 UTC
More information;

Comment 7 Gary Lowe 2017-05-30 16:00:30 UTC
Hi Miguel

If I use the same code as a console app in Visual Studio the CLOSE_WAIT disappears after the timeout period (around 4 minutes)

If I use the same code in Xamarin iOS app or console app the CLOSE_WAIT status never disappears?
Comment 8 Miguel de Icaza [MSFT] 2017-05-30 21:48:01 UTC
The client has done its job in the protocol.   That means the server needs to do its job next.

That is my reading of the description of the TCP/IP protocol.   Perhaps Windows is doing something else on same-system connections.

If you think that this is not the case, it could help if you attach tcpdumps of two networked clients one iOS, one another .NET installation so we can see what the difference is.   

Everything else I see indicates  your server code needs to detect this scenario and do a close on the descriptor