Re: WLAN Connections
- From: conradj <conradj@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 8 Jan 2007 02:20:01 -0800
Hi Chris,
Thanks again for your comments.
Interesting points you raised about the TCP initialization back to previous
values prior to the Power Off / Power On sequence. If I could store those
when detecting a disconnection, and reuse them to re obtain the connection.
I'm using a separate thread to start the connection as follows:
Public Sub Connect()
Try
Dim tThread As New Threading.Thread(AddressOf ConnectThread)
State = enumState.sConnecting
tThread.Start()
Catch ex As Exception
RaiseEvent Error(ex.Message, "Connect")
Finally
End Try
End Sub
Public Sub ConnectThread()
Dim ipaAddress As System.Net.IPAddress
Try
ipaAddress = System.Net.IPAddress.Parse(Address)
tcData = New TcpClient
tcData.Connect(ipaAddress, Port)
Catch ex As SocketException
State = enumState.sDisconnected
RaiseEvent Error("SocketException:" + ex.Message,
"ConnectThread")
Exit Sub
Catch ex As Exception
State = enumState.sDisconnected
RaiseEvent Error("Exception:" + ex.Message, "ConnectThread")
Exit Sub
End Try
Try
State = enumState.sConnected
RaiseEvent Connected()
csClosingState = enumClosingState.csRunning
tReception = New Threading.Thread(AddressOf ReceptionThread)
tReception.Start()
Catch ex As Exception
State = enumState.sDisconnected
RaiseEvent Error(ex.Message, "ConnectThread")
End Try
End Sub
As can be seen from the example code above, I am using the TcpClient Class.
One problem is that I do not know how to detect a disconnection unless I
rewrite the module using the Socket Class instead (which I was trying to
avoid), if I did detect it, would it already be too Late? i.e. the Values
may be wiped out as soon as it disconnects.
I will of course let you when I find the solution to this.
Thanks again,
Conradj
"<ctacke/>" wrote:
I don't know what might be causing it, but if/when you find out I'd be.
really interested to know. Just from a hardware perspective I can't see how
it could work, becasue as I said, the radio must get shut off, so the TCP
stack gets torn down. I supposed maybe it's possible that when it comes
back up things fortuitously get initialized back to what they were and the
socket never realizes that the connectivity went away and just continues
merrily. If that's the case, then my guess is that CF 2.0 added some sort
of socket clean-up for these cases that plugged the hole you're driving
through. Just a guess though, since I never would have expected it to work
in the first place.
--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--
"conradj" <conradj@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5D8F107D-6115-4D45-B8E7-F2173437437C@xxxxxxxxxxxxxxxx
Hi Chris,
The reason I think the .net Compact Framework is responsible was concluded
from the Following Test:
Symbol MC9060-G OEM 01.00.09 (MFG Aug 2004) :
1. Loaded alll CAB files including net CF 1.0 RTM
2. Connectionn Retained.
3. Loaded alll CAB files including net CF 1.0 SP2
4. Connectionn NOT Retained.
5. This would suggest that the .NET CF SP2 did not retain connections,
when
the .NET CF 1.0 RTM DID retain connections.
6. This test was also carried out on a MC9060-G (MFG 11Mar06, OEM
02.00.01)
which also gave the same results.
I conclude that the Compact Framework 1.0 RTM retains connections when the
Compact Framework 1.0 SP2 DOES NOT.
Our customers have NOT complained about poor battery life. I accept that
it
could be an issue with some applications, but we would prefer to keep the
connections open with the server during power off/on. At least, for the
time
being.
Regards,
Conradj
"<ctacke/>" wrote:
I have a hard time believing the CF is responsible for this - it's the
device that handles network connectivity. When the device is off, the
WLAN
radio should be shut off, as it's a huge battery drain. When you power
back
up, it has to reconnect, and then requery the DHCP server to see if its
lease is still valid (it has no idea how long it's been offline). I
can't
see how it could even keep the connection, unless the 9060 doesn't
actually
shut off the radio.
--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--
"conradj" <conradj@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1AA3E39D-8AB9-4CB1-B995-97E332102564@xxxxxxxxxxxxxxxx
Hi,
Can someone help me with the following problem?
The first release of the .NET Compact Framework 1.0 RTM, retains
connections
to a WLAN after a device 'Power On / Off' operation. Replacing this
with
SP2
of .NET Compact Framework 1.0, the device then loses the connection
after
powering down and up (not warm boot just the power button on/off).
Not a problem for the device in question (Symbol MC9060-G), but our
client
now wants to use the Symbol MC9090-G which requires the '.NET Compact
Framework 2.0', which also loses connections after Power On / Off.
Is their a way of making the Later Versions of the Compact Framework
behave
in a similar way to the first version, .i.e. retaining it's connection
to
the
server even after a Suspend / Resume or Power On / Off operation?
Possibly a registry setting or Win32 API call?
--
Thank you in advance,
Conradj
- Follow-Ups:
- Re: WLAN Connections
- From: <ctacke/>
- Re: WLAN Connections
- References:
- Re: WLAN Connections
- From: <ctacke/>
- Re: WLAN Connections
- From: conradj
- Re: WLAN Connections
- From: <ctacke/>
- Re: WLAN Connections
- Prev by Date: Re: Error with (large) fileupload using HttpWebRequest
- Next by Date: Re: CommManager (Ring or Vibrate)
- Previous by thread: Re: WLAN Connections
- Next by thread: Re: WLAN Connections
- Index(es):
Relevant Pages
|
