WLAN Connections

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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?
 
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.
 
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 said:
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
Click to expand...
 
You can detect sleep/wake instead. However I'm not certain it will work
anyway. If you're set up for DHCP, when the device wakes, he LAN driver
powers the chip and then goes to the DHCP server to check the lease.
There's no way around that short of assigning a static IP.
 
And you can't "reestablish" a connection; there's no TCP/IP way to do that.
If the connection has been torn down by the other end, it's gone. You can't
count on the network state to be compatible with just picking up
communication where you left off. If you need to be able to do that, *you*
have to create some method of accomplishing that.

You might envision asking the server to assign you a handle when you first
connect and sending that handle with every message thereafter. The handle
could, from the server's point of view, persist until you told it to discard
it, and the server could ignore whether a new socket sent the old handle or
it came over an existing one (ie. the socket would not be part of the
"state" of the conversation for the server). When you awoke from sleeping
and found that your socket had been torn down, you'd simply reconnect to the
server and resume sending messages using the same handle as before.

Paul T.
 
Back
Top