TcpClient.Connect takes 60 seconds

  • Thread starter Thread starter Richard K
  • Start date Start date
R

Richard K

In a VB CE app I am connecting to a VB.NET server program running on my
local network. The statement

MyTcpClient.Connect("192.168.1.1", 8222)

always takes about one minute to connect. It does eventually connect with
no errors, and the NetworkStream works well & quickly after that.

This app was manually ported from an eVB version using the WinSock control.
That one always connects immediately to the same server.

This delay even occurs when the client is running on the same PC as the
server!

I have seen a few other posts over the last year or so describing the same
symptom but without answers.

Can anyone help?

thanks

Dick
 
Richard,

Chances are, the delay you are seeing is due to the TcpClient attempting to
resolve the hostname. Since your hostname is an IPAddress, you may wish to
eliminate the resolution step by replacing your code with the following:

MyTcpClient.Connect(IPAddress.Parse("192.168.1.1"), 8222);

Thanks,
David Kline
Microsoft .NET Compact Framework
--------------------------------
This posting is provided “AS IS” with no warranties, and confers no
rights.

Please do not send email directly to this alias. This alias is for
newsgroup purposes only. To correspond with me directly, remove the
'online' from
my alias.
 
That might work - I don't know, I have already changed the code to use
Socket.BeginConnect/EndConnect which connects instantly using the same IP
address string. But that brings up another question...

In the desktop .NET framework WaitOne(delay in ms) can be used after
BeginConnect to limit the time allowed for a conection attempt. But the CF
version of WaitOne does not accept a time limit. I have seen suggestions
that Thread.Sleep be used instead, followed by testing a boolean that is set
on in the callback if the EndConnect executes normally. If this bool is not
set after Sleep then the connection has not completed.

My question is, in that case isn't the callback thread still waiting on
EndConnect? And if so how can the program terminate it - preferably leaving
the Socket in a state that will allow the user to make another connection
attempt. (It is my impression that "desktop" WaitOne kills the thread if it
times out, but I could be mistaken about that also.)

Dick
 
Answering my own question, Socket.Close seems to do the job. The callback
EndConnect errors out and the thread ends. And I guess the condition of the
socket afterward doesn't matter if it is recreated for each connect attempt.

Richard K said:
That might work - I don't know, I have already changed the code to use
Socket.BeginConnect/EndConnect which connects instantly using the same IP
address string. But that brings up another question...

In the desktop .NET framework WaitOne(delay in ms) can be used after
BeginConnect to limit the time allowed for a conection attempt. But the CF
version of WaitOne does not accept a time limit. I have seen suggestions
that Thread.Sleep be used instead, followed by testing a boolean that is set
on in the callback if the EndConnect executes normally. If this bool is not
set after Sleep then the connection has not completed.

My question is, in that case isn't the callback thread still waiting on
EndConnect? And if so how can the program terminate it - preferably leaving
the Socket in a state that will allow the user to make another connection
attempt. (It is my impression that "desktop" WaitOne kills the thread if it
times out, but I could be mistaken about that also.)

Dick

"David Kline [msft]" said:
Richard,

Chances are, the delay you are seeing is due to the TcpClient attempting to
resolve the hostname. Since your hostname is an IPAddress, you may wish to
eliminate the resolution step by replacing your code with the following:

MyTcpClient.Connect(IPAddress.Parse("192.168.1.1"), 8222);

Thanks,
David Kline
Microsoft .NET Compact Framework
--------------------------------
This posting is provided "AS IS" with no warranties, and confers no
rights.

Please do not send email directly to this alias. This alias is for
newsgroup purposes only. To correspond with me directly, remove the
'online' from
my alias.
Click to expand...
Click to expand...
 
Back
Top