Add LocalEndPoint and RemoteEndPoint properties to TcpClient

[xanather]

Due to dotnet/corefx#5953 it is not possible to get this information.

This is a pretty important property and I think should be added to the contract before next RC release. Obtaining IP address information is essential for application-level IP blocking/banning etc among many other things...

[stephentoub]

cc: @davidsh, @CIPop, @SidharthNabar

[davidsh]

This will require an API review document and API changes to be approved. Add new properties will be difficult since they can't be done as extension methods and thus won't unify with .NET Framework (Desktop). So, we will have to consider design alternatives and/or generation changes for System.Net.Sockets contract. This may not be possible for the RTM release.

[davidsh]

For developers that require these properties, the alternative is to not use TcpClient, but rather use the Socket class directly. TcpClient and UdpClient are considered as "easier" helper classes with fewer properties than Socket.

[xanather]

@davidsh I think a reason why people would use TcpClient over Socket is because it TcpClient provides the async/await model while Socket does not provide this and requires reworking with SocketAsyncEventArgs, which creates slightly more unreadable code and is unnecessary optimization for most applications.

This change basically forces many users to move over to Socket just for simple properties which can be an even worse .net core porting headache, I think the contract should be changed to make these properties available or the bugs associated with exposing Socket on TcpClient fixed.

[manu-st]

👍 @xanather Agree on this one, I had to rework some code due to the recent change in CoreFX.

For example, it prevents porting this project https://github.com/rdavisau/sockets-for-pcl to CoreCLR/CoreFX.

[CIPop]

I agree with the enhancement: I think we should add a way to expose the Local/Remote endpoints for TcpClient. This will need to be done in such a way that allows us to add the same properties on .Net Desktop.

TcpClient provides the async/await model while Socket does not provide this

@xanather We've added TPL (async/await) to Sockets in version 4.1 as we've deprecated the Begin/End APIs. These APIs are now available in both CoreFX and .Net Desktop.

@SidharthNabar, @davidsh I think the disconnect is caused by documentation missing from MSDN about the new async/await APIs.

[xanather]

@CIPop Thanks for the info, because async/await has been added to Socket I have converted my code to use Socket instead of TcpClient (lack of documentation was indeed the problem).

However this forced changed from TcpClient to Socket proves my point, TcpClient is really quite useless now unless in extremely basic scenarios.

[davidsh]

This issue was only opened up when we removed the TcpClient.Client property in the development phase of the 4.1 System.Net.Sockets contract.

However, based on feedback, we put the .Client property back.
dotnet/corefx#8603

So, this issue is not necessary anymore. The .Client property returns the Socket object and hence already has the LocalEndPoint and RemoteEndPoint properties.