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.
...
> 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]"" <davi...@online.microsoft.com> wrote in message
> news:44%23PfzusDHA.3024@cpmsftngxa07.phx.gbl...
> > 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.
|
