Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TcpClient.Connect takes 60 seconds

7 views
Skip to first unread message

Richard K

unread,
Nov 23, 2003, 1:52:46 PM11/23/03
to
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


David Kline [msft]

unread,
Nov 24, 2003, 7:41:23 PM11/24/03
to
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.

Richard K

unread,
Nov 25, 2003, 12:39:58 PM11/25/03
to
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]"" <dav...@online.microsoft.com> wrote in message
news:44%23Pfzus...@cpmsftngxa07.phx.gbl...

Richard K

unread,
Nov 26, 2003, 5:00:55 PM11/26/03
to
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" <junk...@seventree.com> wrote in message
news:bq048o$e7fi$1...@news3.infoave.net...

0 new messages