D
David Dvali
How can I check if TcpClient is connected (or not connected)?
T
Tim Haughton
David Dvali said:
You could check the state of the underlying socket. This is a protected
property on TcpClient.
--
Regards,
Tim Haughton
Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
This is in my opinion one of the problems of using TcpClient , you can know
if it's connected at connection time, after that you are pretty much blind.
Does anybody knows why the member Sockect was made protected instead of
public?
You can use TcpClient.Active , it does says if a connection has been
established, it does not says nothing about the status of the connection
after that.
you could derive it and expose Socket as a public property
cheers,
This is in my opinion one of the problems of using TcpClient , you can know
if it's connected at connection time, after that you are pretty much blind.
Does anybody knows why the member Sockect was made protected instead of
public?
You can use TcpClient.Active , it does says if a connection has been
established, it does not says nothing about the status of the connection
after that.
you could derive it and expose Socket as a public property
cheers,
T
Tim Haughton
Ignacio Machin ( .NET/ C# MVP ) said:
I'm guessing it's the fact that the TcpClient is a helper class designed to
simplify use. Exposing the Socket as a public property might be seen as
breaking that encapsulation. If the OP was really bothered by it, he could
simply use the Socket class instead of TcpClient, it's not *that* much
harder.
--
Regards,
Tim Haughton
Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
G
Guest
You could also derive your own class from TcpClient, use and expose your own
Socket. I think there are examples on MSDN. I did this last summer and could
dig around and find the code if you want.
Socket. I think there are examples on MSDN. I did this last summer and could
dig around and find the code if you want.
I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
Yes, that is the reason, it makes it easy to connect and then expose a
stream which do help a lot really.
But it would not had hurt to expose some others properties from the
underliying socket.
In any case inheriting is the way to go.
Well, what happened to me once is that I was using a library that return a
TcpClient , so I was stuck with it and I had no way to change it. is in this
situations where not even inheriting can solve the problem
cheers,
Yes, that is the reason, it makes it easy to connect and then expose a
stream which do help a lot really.
But it would not had hurt to expose some others properties from the
underliying socket.
In any case inheriting is the way to go.
Well, what happened to me once is that I was using a library that return a
TcpClient , so I was stuck with it and I had no way to change it. is in this
situations where not even inheriting can solve the problem
cheers,
S
S. Senthil Kumar
It is a hack, but you can use reflection to get the underlying socket.
Of course, it will break if Microsoft changed the member variable name,
but it works for the current version
I also noticed that .NET 2.0 beta does expose the socket object as a
property.
Of course, it will break if Microsoft changed the member variable name,
but it works for the current version
I also noticed that .NET 2.0 beta does expose the socket object as a
property.
I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
Yes, you can use that, and it does not matter if the member variable
change of name, you can check by the variable type
Now the problem would be if TcpClient has more than one Socket member
Good that of 2.0
cheers,
Yes, you can use that, and it does not matter if the member variable
change of name, you can check by the variable type
Now the problem would be if TcpClient has more than one Socket member
Good that of 2.0
cheers,