Keeping a TCP connection during power off

  • Thread starter Thread starter Dexlex
  • Start date Start date
D

Dexlex

Hello NG,

How can I manage keeping a WLAN TCP connection during power off. My TCP
thread waits in socket.Receive(...) when the device goes to sleep and throws
a SocketException (10004 - WSAEINTR - Interrupted function call) as soon as
it is turned back on. When I ignore this and loop back in
socket.Receive(...), I get a SocketException (10038 - WSAENOSOCK - Socket
operation on nonsocket) immediately.

Even when I turn off the device during a Thread.Sleep(...) I get WSAENOSOCK
as soon as I enter socket.Receive(...).

Does anyone know? Thanks!

Dex
 
Dexlex said:
Hello NG,

How can I manage keeping a WLAN TCP connection during power off. My TCP
thread waits in socket.Receive(...) when the device goes to sleep and throws
a SocketException (10004 - WSAEINTR - Interrupted function call) as soon as
it is turned back on. When I ignore this and loop back in
socket.Receive(...), I get a SocketException (10038 - WSAENOSOCK - Socket
operation on nonsocket) immediately.

Even when I turn off the device during a Thread.Sleep(...) I get WSAENOSOCK
as soon as I enter socket.Receive(...).

Does anyone know? Thanks!

Dex
Click to expand...

The TCP connection requires the device to respond periodically with
keep alive messages normally, so I'd imagine that by the time you turn
the device back on the remote server would have dropped the connection
anyway.

Can you not just open a new connection to the server when it is
dropped? Then if the reconnect fails you probaly don't have network
connection anymore and need to do something to handle this condition,
error to the user, wait and try again in a couple of minutes, etc. This
would be the normal error handling you have for a loss of connection,
which you have to assume is possible as some one can move out of
wireless range, unplug the cable, etc.
 
A new connection starts a new session on the host, which is not acceptable.
Since the data communication is always initiated by the device, leaving the
radio area is no problem because I hold outgoing data as long as I don't
have an access point association. When I re-associate, I send the data and
everything is fine.

A TCP connection doesn't necessarily send keep-alives and so doesn't mine
(Windows). The device doesn't finish the line when turned off, so the
connection on the host side is still open. When I open a new socket to the
host (with the same destination port but a different source port), the other
one is still open.

Is there a way to force Socket.Connect to use a given source port and so
possibly reopen the half open connection?

Dex
 
The answer is that you can't. At power off the network controller is
completely powered down to conserve battery life. When you wake, it gets
repowered and reinitialized, at which point it must renogotiate with the
network.

The anaolgy on the desktop would be to disable and renable your adapter and
expect a connection through it to survive that.
 
No. You can implement recognition on your server end that the same client
(identified by something that the client sends shortly after connecting, a
GUID, a user name, whatever), has connected and drop the old connection
(that is, you'd implement what you're talking about yourself), but you can't
somehow make the connection persist in the absence of network connectivity.

Paul T.
 
Thank you!

So I stop researching at this point and use Idle mode to save energy and
disable the power button.

Dex



"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> schrieb im Newsbeitrag news:[email protected]...
 
Again, it's not a bug in later versions of the CF - you're simply taking
advantage of a bug in an earlier version. That bug, while it works
sometimes, will not work in all cases. depending on a bug will most
certainly lead to a failure in the future.

One good case would be the following:

Your PPC is on a network with short DHCP lease times. Put the device to
sleep, wit until after the lease period, then wake. Your socket
transmission will fail (it will likely behave just like the updated CF
versions).

The way to get past this is to expect proper device behavior and code for
it - do not rely on the earlier bug and definitely don't try to reproduce
the bug on later, fixed devices.


--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--



conradj said:
Hi Dexlex,

I've been looking at this problem ever since upgrading from a device using
.NET Compact Framework 1.0 RTM to .NET Compact Framework 1.0 SP3.

When using the earlier version of the .NETCF, the connection is retained
after a Power Off / Power On. You could try using an earlier version of
the
.NETCF on your device if it is compatible to keep connections, but other
improvements in the .NETCF would have to be sacrificed.

It has been suggested to me that later versions of the .NETCF clear out
their Socket Settings so requiring reinitialization to reconnect to the
host.
It anybody finds a way of restoring connections after a Power Off / Power
On,
on later versions of .NETCF, I would very interested.

Thank you,

Conradj


Dexlex said:
Thank you!

So I stop researching at this point and use Idle mode to save energy and
disable the power button.

Dex



"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT
com> schrieb im Newsbeitrag news:[email protected]...
No. You can implement recognition on your server end that the same
client
(identified by something that the client sends shortly after
connecting, a
GUID, a user name, whatever), has connected and drop the old connection
(that is, you'd implement what you're talking about yourself), but you
can't somehow make the connection persist in the absence of network
connectivity.

Paul T.

A new connection starts a new session on the host, which is not
acceptable. Since the data communication is always initiated by the
device, leaving the radio area is no problem because I hold outgoing
data
as long as I don't have an access point association. When I
re-associate,
I send the data and everything is fine.

A TCP connection doesn't necessarily send keep-alives and so doesn't
mine
(Windows). The device doesn't finish the line when turned off, so the
connection on the host side is still open. When I open a new socket to
the host (with the same destination port but a different source port),
the other one is still open.

Is there a way to force Socket.Connect to use a given source port and
so
possibly reopen the half open connection?

Dex




Dexlex wrote:

Hello NG,

How can I manage keeping a WLAN TCP connection during power off. My
TCP
thread waits in socket.Receive(...) when the device goes to sleep
and
throws
a SocketException (10004 - WSAEINTR - Interrupted function call) as
soon as
it is turned back on. When I ignore this and loop back in
socket.Receive(...), I get a SocketException (10038 - WSAENOSOCK -
Socket
operation on nonsocket) immediately.

Even when I turn off the device during a Thread.Sleep(...) I get
WSAENOSOCK
as soon as I enter socket.Receive(...).

Does anyone know? Thanks!

Dex

The TCP connection requires the device to respond periodically with
keep alive messages normally, so I'd imagine that by the time you
turn
the device back on the remote server would have dropped the
connection
anyway.

Can you not just open a new connection to the server when it is
dropped? Then if the reconnect fails you probaly don't have network
connection anymore and need to do something to handle this condition,
error to the user, wait and try again in a couple of minutes, etc.
This
would be the normal error handling you have for a loss of connection,
which you have to assume is possible as some one can move out of
wireless range, unplug the cable, etc.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top