On Tue, 21 Oct 2008 10:00:55 -0700, Jeroen Mostert <jm******@xs4all.nl>
wrote:
puzzlecracker wrote:
>It looks like i need to get IPEndPoint first, but I cannot figure out
from msdn the eventual obtainment of machine name and port number.
Please suggest a solution.
There is no solution. You should be the one responsible for creating the
TcpClient, so you also know the endpoint. Conversely, if you're just
using a TcpClient created somewhere else, you have no business with the
endpoint the TcpClient is abstracting over.
Alright, so there is one solution: use reflection to read the
TcpClient's private members, in particular the Socket it encapsulates.
There is no reason why such code shouldn't break with the next release
of the framework, though. Only use it for an incident. [...]
Actually...
While I agree with your general comments about whether one should need the
IPEndPoint at all, you can retrieve the Socket for the TcpClient with the
public Client property. There's no reflection needed, nor should it
necessarily be a long-term maintenance problem, at least not with respect
to the retrieval of the Socket itself (the design flaw itself could lead
to a maintenance problem, but that's different :) ).
Of course, that assumes that the OP really means that he's got a TcpClient
in hand, and for some reason wants the IPEndPoint. But his original post
isn't very clear on which IPEndPoint he wants (local or remote), nor on
whether he wants it for the purpose of creating a TcpClient, or getting it
from a TcpClient.
It's possible there's a different, more appropriate answer to the question.
Pete