TCP Socket doesn't recognize line interruption

  • Thread starter Thread starter Benjamin Lukner
  • Start date Start date
B

Benjamin Lukner

Hi!

I have a nasty problem concerning a TCP/IP connection:

I use a System.Net.Sockets.Socket and BeginSend/EndSend in my program.
When WLAN still works fine but the connection to the server is broken
anyway (LAN cable plugged out, switch failure or a firewall killed the
connection because of a time out while the PPC2003 was in suspend mode),
the program doesn't recognize it.
For a test I use a timer sending some data to the server every second.
I can plug out the server's LAN connection and my program keeps on
sending data without getting an error! But it's a TCP and not a UDP
connection!?!
Feature or failure...?

This is some of my code:

Private _socket As Socket
[...]
_socket = New Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp)
_socket.Blocking = False
_socket.BeginConnect(endPoint, AddressOf ConnectCallback, Nothing)
[...]

Friend Function Send(ByVal data() As Byte) As Boolean

Try
If _socket Is Nothing Then
Return False
End If

If _socket.Connected = False Then
Return False
End If

Try
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectError) _
= True Then
Return False
Else
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectWrite) _
= False Then
Return False
End IF

Catch
Return False
End Try

Catch
Return False
End Try

_socket.BeginSend(data, 0, data.Length, _
SocketFlags.None, AddressOf SendCallback, Nothing)

Return True

End Function

[...]

Private Sub SendCallback(ByVal ar As IAsyncResult)

If _socket.EndSend(ar) < 1 Then
Debug.WriteLine("Nothing sent.")
End If

End Sub


I also tried to Set SendTimeout and ReceiveTimeout, but without effect.
What else could I do to recognize the closed connection?

Kind regards,

Benjamin Lukner
 
I will be interested in replies to this. I have also discovered that TCP
socket timeouts on PPC is very very high (aobut 10 minutes or longer in my
testing). Unless the server side closes the socket the PPC receives this
close message!
 
Well, I'd pull the .NET CF out of the equation, myself. Write a
C-based/Winsock-based sockets program and try to duplicate the problem
there. If it happens in that case, I'd call it a bug, depending on the time
it actually takes to detect the broken connection. If it 'never' detects
it, then it's a bug. If it takes 10 minutes, I'd say that is potentially
consistent with the way the protocol works.

I can't test this on our devices, as they don't suspend...

Paul T.

Yechezkal Gutfreund said:
I will be interested in replies to this. I have also discovered that TCP
socket timeouts on PPC is very very high (aobut 10 minutes or longer in my
testing). Unless the server side closes the socket the PPC receives this
close message!


Benjamin Lukner said:
Hi!

I have a nasty problem concerning a TCP/IP connection:

I use a System.Net.Sockets.Socket and BeginSend/EndSend in my program.
When WLAN still works fine but the connection to the server is broken
anyway (LAN cable plugged out, switch failure or a firewall killed the
connection because of a time out while the PPC2003 was in suspend mode),
the program doesn't recognize it.
For a test I use a timer sending some data to the server every second.
I can plug out the server's LAN connection and my program keeps on
sending data without getting an error! But it's a TCP and not a UDP
connection!?!
Feature or failure...?

This is some of my code:

Private _socket As Socket
[...]
_socket = New Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp)
_socket.Blocking = False
_socket.BeginConnect(endPoint, AddressOf ConnectCallback, Nothing)
[...]

Friend Function Send(ByVal data() As Byte) As Boolean

Try
If _socket Is Nothing Then
Return False
End If

If _socket.Connected = False Then
Return False
End If

Try
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectError) _
= True Then
Return False
Else
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectWrite) _
= False Then
Return False
End IF

Catch
Return False
End Try

Catch
Return False
End Try

_socket.BeginSend(data, 0, data.Length, _
SocketFlags.None, AddressOf SendCallback, Nothing)

Return True

End Function

[...]

Private Sub SendCallback(ByVal ar As IAsyncResult)

If _socket.EndSend(ar) < 1 Then
Debug.WriteLine("Nothing sent.")
End If

End Sub


I also tried to Set SendTimeout and ReceiveTimeout, but without effect.
What else could I do to recognize the closed connection?

Kind regards,

Benjamin Lukner
Click to expand...
Click to expand...
 
Hi.. I have the same problem and haven't either been able to find a
solution. I read however that the SendTimeout and ReceiveTimeout
socketoptions only work for synchronous sends and receives. I also use
BeginSend and BeginReceive so I have no use for these timeouts.
 
Our application (mainly for testing purposes) is written so that we can run
the client either as a PPC or as a Windows application.

The long socket timeouts only occur on the PPC.

We are guessing that there is a registry setting on the PPC that is telling
the TCP protocol to have very long timeouts on the PPC. This probably makes
sense on most wireless PPC applications, since WiFi, CMDA, GPRS, etc, are
all pretty flaky.

However, in our case we are doing our own error recovery, and we would like
the user to be aware quickly if he is online or off. We will do the
recovery.

So.... Back to the question. Is there a registry or .NET CF setting on
socket (which we have yet to discover) that allows us to have short lived
tcp NAK timeouts?

Otherwise, I see no choice but to have a heartbeat on the server, that the
PPC monitors, and if it does not get, then it closes the line.


--
==================================
Yechezkal Gutfreund
Chief Scientist
Kesser Technical Group, Inc.
==================================
Paul G. Tobey said:
Well, I'd pull the .NET CF out of the equation, myself. Write a
C-based/Winsock-based sockets program and try to duplicate the problem
there. If it happens in that case, I'd call it a bug, depending on the time
it actually takes to detect the broken connection. If it 'never' detects
it, then it's a bug. If it takes 10 minutes, I'd say that is potentially
consistent with the way the protocol works.

I can't test this on our devices, as they don't suspend...

Paul T.

Yechezkal Gutfreund said:
I will be interested in replies to this. I have also discovered that TCP
socket timeouts on PPC is very very high (aobut 10 minutes or longer in my
testing). Unless the server side closes the socket the PPC receives this
close message!


message news:[email protected]...
Hi!

I have a nasty problem concerning a TCP/IP connection:

I use a System.Net.Sockets.Socket and BeginSend/EndSend in my program.
When WLAN still works fine but the connection to the server is broken
anyway (LAN cable plugged out, switch failure or a firewall killed the
connection because of a time out while the PPC2003 was in suspend mode),
the program doesn't recognize it.
For a test I use a timer sending some data to the server every second.
I can plug out the server's LAN connection and my program keeps on
sending data without getting an error! But it's a TCP and not a UDP
connection!?!
Feature or failure...?

This is some of my code:

Private _socket As Socket
[...]
_socket = New Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp)
_socket.Blocking = False
_socket.BeginConnect(endPoint, AddressOf ConnectCallback, Nothing)
[...]

Friend Function Send(ByVal data() As Byte) As Boolean

Try
If _socket Is Nothing Then
Return False
End If

If _socket.Connected = False Then
Return False
End If

Try
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectError) _
= True Then
Return False
Else
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectWrite) _
= False Then
Return False
End IF

Catch
Return False
End Try

Catch
Return False
End Try

_socket.BeginSend(data, 0, data.Length, _
SocketFlags.None, AddressOf SendCallback, Nothing)

Return True

End Function

[...]

Private Sub SendCallback(ByVal ar As IAsyncResult)

If _socket.EndSend(ar) < 1 Then
Debug.WriteLine("Nothing sent.")
End If

End Sub


I also tried to Set SendTimeout and ReceiveTimeout, but without effect.
What else could I do to recognize the closed connection?

Kind regards,

Benjamin Lukner
Click to expand...
Click to expand...
Click to expand...
 
There are few, if any, registry entries for time-outs, etc. on the PPC. I'm
not aware of any 'time-out quickly' settings in Windows CE at all. You can
set up the keep-alive times with the KeepAliveInterval and KeepAliveTime.
These DWORD values affect *all* network connections on the device and are
set in the HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms key in the registry.

Paul T.

Yechezkal Gutfreund said:
Our application (mainly for testing purposes) is written so that we can run
the client either as a PPC or as a Windows application.

The long socket timeouts only occur on the PPC.

We are guessing that there is a registry setting on the PPC that is telling
the TCP protocol to have very long timeouts on the PPC. This probably makes
sense on most wireless PPC applications, since WiFi, CMDA, GPRS, etc, are
all pretty flaky.

However, in our case we are doing our own error recovery, and we would like
the user to be aware quickly if he is online or off. We will do the
recovery.

So.... Back to the question. Is there a registry or .NET CF setting on
socket (which we have yet to discover) that allows us to have short lived
tcp NAK timeouts?

Otherwise, I see no choice but to have a heartbeat on the server, that the
PPC monitors, and if it does not get, then it closes the line.


--
==================================
Yechezkal Gutfreund
Chief Scientist
Kesser Technical Group, Inc.
==================================
Paul G. Tobey said:
Well, I'd pull the .NET CF out of the equation, myself. Write a
C-based/Winsock-based sockets program and try to duplicate the problem
there. If it happens in that case, I'd call it a bug, depending on the time
it actually takes to detect the broken connection. If it 'never' detects
it, then it's a bug. If it takes 10 minutes, I'd say that is potentially
consistent with the way the protocol works.

I can't test this on our devices, as they don't suspend...

Paul T.
Click to expand...
in
my
testing). Unless the server side closes the socket the PPC receives this
close message!


message Hi!

I have a nasty problem concerning a TCP/IP connection:

I use a System.Net.Sockets.Socket and BeginSend/EndSend in my program.
When WLAN still works fine but the connection to the server is broken
anyway (LAN cable plugged out, switch failure or a firewall killed the
connection because of a time out while the PPC2003 was in suspend mode),
the program doesn't recognize it.
For a test I use a timer sending some data to the server every second.
I can plug out the server's LAN connection and my program keeps on
sending data without getting an error! But it's a TCP and not a UDP
connection!?!
Feature or failure...?

This is some of my code:

Private _socket As Socket
[...]
_socket = New Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp)
_socket.Blocking = False
_socket.BeginConnect(endPoint, AddressOf ConnectCallback, Nothing)
[...]

Friend Function Send(ByVal data() As Byte) As Boolean

Try
If _socket Is Nothing Then
Return False
End If

If _socket.Connected = False Then
Return False
End If

Try
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectError) _
= True Then
Return False
Else
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectWrite) _
= False Then
Return False
End IF

Catch
Return False
End Try

Catch
Return False
End Try

_socket.BeginSend(data, 0, data.Length, _
SocketFlags.None, AddressOf SendCallback, Nothing)

Return True

End Function

[...]

Private Sub SendCallback(ByVal ar As IAsyncResult)

If _socket.EndSend(ar) < 1 Then
Debug.WriteLine("Nothing sent.")
End If

End Sub


I also tried to Set SendTimeout and ReceiveTimeout, but without effect.
What else could I do to recognize the closed connection?

Kind regards,

Benjamin Lukner
Click to expand...
Click to expand...
Click to expand...
 
This sounds like a good lead for us (we are doing a dedicated PDA
application).

My eyebrows went up at your use of *all*! I certainly expected a registry
setting to effect an entire
class of connections, and since I only know of TCP and UDP (and KEEP ALIVE
is not relevent
in the second case). I am still sorta guessing if you mean anything more by
the use of *all*.


Paul G. Tobey said:
There are few, if any, registry entries for time-outs, etc. on the PPC. I'm
not aware of any 'time-out quickly' settings in Windows CE at all. You can
set up the keep-alive times with the KeepAliveInterval and KeepAliveTime.
These DWORD values affect *all* network connections on the device and are
set in the HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms key in the registry.

Paul T.

Yechezkal Gutfreund said:
Our application (mainly for testing purposes) is written so that we can run
the client either as a PPC or as a Windows application.

The long socket timeouts only occur on the PPC.

We are guessing that there is a registry setting on the PPC that is telling
the TCP protocol to have very long timeouts on the PPC. This probably makes
sense on most wireless PPC applications, since WiFi, CMDA, GPRS, etc, are
all pretty flaky.

However, in our case we are doing our own error recovery, and we would like
the user to be aware quickly if he is online or off. We will do the
recovery.

So.... Back to the question. Is there a registry or .NET CF setting on
socket (which we have yet to discover) that allows us to have short lived
tcp NAK timeouts?

Otherwise, I see no choice but to have a heartbeat on the server, that the
PPC monitors, and if it does not get, then it closes the line.


--
==================================
Yechezkal Gutfreund
Chief Scientist
Kesser Technical Group, Inc.
==================================
Paul G. Tobey said:
Well, I'd pull the .NET CF out of the equation, myself. Write a
C-based/Winsock-based sockets program and try to duplicate the problem
there. If it happens in that case, I'd call it a bug, depending on
Click to expand...
the
time
it actually takes to detect the broken connection. If it 'never' detects
it, then it's a bug. If it takes 10 minutes, I'd say that is potentially
consistent with the way the protocol works.

I can't test this on our devices, as they don't suspend...

Paul T.

I will be interested in replies to this. I have also discovered that TCP
socket timeouts on PPC is very very high (aobut 10 minutes or longer
Click to expand...
in
my
testing). Unless the server side closes the socket the PPC receives this
close message!


"Benjamin Lukner" <[email protected]>
Click to expand...
wrote
in
message Hi!

I have a nasty problem concerning a TCP/IP connection:

I use a System.Net.Sockets.Socket and BeginSend/EndSend in my program.
When WLAN still works fine but the connection to the server is broken
anyway (LAN cable plugged out, switch failure or a firewall killed the
connection because of a time out while the PPC2003 was in suspend mode),
the program doesn't recognize it.
For a test I use a timer sending some data to the server every second.
I can plug out the server's LAN connection and my program keeps on
sending data without getting an error! But it's a TCP and not a UDP
connection!?!
Feature or failure...?

This is some of my code:

Private _socket As Socket
[...]
_socket = New Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp)
_socket.Blocking = False
_socket.BeginConnect(endPoint, AddressOf ConnectCallback, Nothing)
[...]

Friend Function Send(ByVal data() As Byte) As Boolean

Try
If _socket Is Nothing Then
Return False
End If

If _socket.Connected = False Then
Return False
End If

Try
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectError) _
= True Then
Return False
Else
If _socket.Poll(1,
Click to expand...
Click to expand...
System.Net.Sockets.SelectMode.SelectWrite)
_
= False Then
Return False
End IF

Catch
Return False
End Try

Catch
Return False
End Try

_socket.BeginSend(data, 0, data.Length, _
SocketFlags.None, AddressOf SendCallback, Nothing)

Return True

End Function

[...]

Private Sub SendCallback(ByVal ar As IAsyncResult)

If _socket.EndSend(ar) < 1 Then
Debug.WriteLine("Nothing sent.")
End If

End Sub


I also tried to Set SendTimeout and ReceiveTimeout, but without effect.
What else could I do to recognize the closed connection?

Kind regards,

Benjamin Lukner
Click to expand...
Click to expand...
Click to expand...
 
Why should things like time-outs be the same for a wired Ethernet network
adapter and a wireless Ethernet adapter? Why should they be the same for a
dial-up connection? It's the wrong choice. In fact, it should be settable
on a per-socket basis. In your case, if you change the time-out in order to
make your one program work, you'll be having a global, negative effect on
the total amount of network traffic generated by the device. This sort of
side-effect is generally a bad thing.

Paul T.

Yechezkal Gutfreund said:
This sounds like a good lead for us (we are doing a dedicated PDA
application).

My eyebrows went up at your use of *all*! I certainly expected a registry
setting to effect an entire
class of connections, and since I only know of TCP and UDP (and KEEP ALIVE
is not relevent
in the second case). I am still sorta guessing if you mean anything more by
the use of *all*.


Paul G. Tobey said:
There are few, if any, registry entries for time-outs, etc. on the PPC. I'm
not aware of any 'time-out quickly' settings in Windows CE at all. You can
set up the keep-alive times with the KeepAliveInterval and KeepAliveTime.
These DWORD values affect *all* network connections on the device and are
set in the HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms key in the registry.

Paul T.

Yechezkal Gutfreund said:
Our application (mainly for testing purposes) is written so that we
Click to expand...
can
run
the client either as a PPC or as a Windows application.

The long socket timeouts only occur on the PPC.

We are guessing that there is a registry setting on the PPC that is telling
the TCP protocol to have very long timeouts on the PPC. This probably makes
sense on most wireless PPC applications, since WiFi, CMDA, GPRS, etc, are
all pretty flaky.

However, in our case we are doing our own error recovery, and we would like
the user to be aware quickly if he is online or off. We will do the
recovery.

So.... Back to the question. Is there a registry or .NET CF setting on
socket (which we have yet to discover) that allows us to have short lived
tcp NAK timeouts?

Otherwise, I see no choice but to have a heartbeat on the server, that the
PPC monitors, and if it does not get, then it closes the line.


--
==================================
Yechezkal Gutfreund
Chief Scientist
Kesser Technical Group, Inc.
==================================
message Well, I'd pull the .NET CF out of the equation, myself. Write a
C-based/Winsock-based sockets program and try to duplicate the problem
there. If it happens in that case, I'd call it a bug, depending on the
time
it actually takes to detect the broken connection. If it 'never' detects
it, then it's a bug. If it takes 10 minutes, I'd say that is potentially
consistent with the way the protocol works.

I can't test this on our devices, as they don't suspend...

Paul T.

I will be interested in replies to this. I have also discovered
Click to expand...
that
TCP
socket timeouts on PPC is very very high (aobut 10 minutes or
Click to expand...
longer
in
my
testing). Unless the server side closes the socket the PPC
Click to expand...
receives
this
close message!


in
message Hi!

I have a nasty problem concerning a TCP/IP connection:

I use a System.Net.Sockets.Socket and BeginSend/EndSend in my program.
When WLAN still works fine but the connection to the server is broken
anyway (LAN cable plugged out, switch failure or a firewall
Click to expand...
killed
the
connection because of a time out while the PPC2003 was in suspend
mode),
the program doesn't recognize it.
For a test I use a timer sending some data to the server every second.
I can plug out the server's LAN connection and my program keeps on
sending data without getting an error! But it's a TCP and not a UDP
connection!?!
Feature or failure...?

This is some of my code:

Private _socket As Socket
[...]
_socket = New Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp)
_socket.Blocking = False
_socket.BeginConnect(endPoint, AddressOf ConnectCallback, Nothing)
[...]

Friend Function Send(ByVal data() As Byte) As Boolean

Try
If _socket Is Nothing Then
Return False
End If

If _socket.Connected = False Then
Return False
End If

Try
If _socket.Poll(1,
Click to expand...
Click to expand...
System.Net.Sockets.SelectMode.SelectError)
_
= True Then
Return False
Else
If _socket.Poll(1,
Click to expand...
System.Net.Sockets.SelectMode.SelectWrite)
_
= False Then
Return False
End IF

Catch
Return False
End Try

Catch
Return False
End Try

_socket.BeginSend(data, 0, data.Length, _
SocketFlags.None, AddressOf SendCallback, Nothing)

Return True

End Function

[...]

Private Sub SendCallback(ByVal ar As IAsyncResult)

If _socket.EndSend(ar) < 1 Then
Debug.WriteLine("Nothing sent.")
End If

End Sub


I also tried to Set SendTimeout and ReceiveTimeout, but without
effect.
What else could I do to recognize the closed connection?

Kind regards,

Benjamin Lukner
Click to expand...
Click to expand...
Click to expand...
 
Of course, it SHOULD be settable on a per-socket/per-connection basis.

But you told me that is not an option.

Luckily, in our case we are creating a dedicated device and a dedicated
application. And it will
be using a dedicated wireless network.

So your info is very helpful, and we thank you!


Paul G. Tobey said:
Why should things like time-outs be the same for a wired Ethernet network
adapter and a wireless Ethernet adapter? Why should they be the same for a
dial-up connection? It's the wrong choice. In fact, it should be settable
on a per-socket basis. In your case, if you change the time-out in order to
make your one program work, you'll be having a global, negative effect on
the total amount of network traffic generated by the device. This sort of
side-effect is generally a bad thing.

Paul T.

Yechezkal Gutfreund said:
This sounds like a good lead for us (we are doing a dedicated PDA
application).

My eyebrows went up at your use of *all*! I certainly expected a registry
setting to effect an entire
class of connections, and since I only know of TCP and UDP (and KEEP ALIVE
is not relevent
in the second case). I am still sorta guessing if you mean anything more by
the use of *all*.


PPC.
I'm You
can etc,
are that
the on
the
Click to expand...
keeps
on
sending data without getting an error! But it's a TCP and not
Click to expand...
a
UDP
connection!?!
Feature or failure...?

This is some of my code:

Private _socket As Socket
[...]
_socket = New Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp)
_socket.Blocking = False
_socket.BeginConnect(endPoint, AddressOf ConnectCallback, Nothing)
[...]

Friend Function Send(ByVal data() As Byte) As Boolean

Try
If _socket Is Nothing Then
Return False
End If

If _socket.Connected = False Then
Return False
End If

Try
If _socket.Poll(1,
Click to expand...
System.Net.Sockets.SelectMode.SelectError)
_
= True Then
Return False
Else
If _socket.Poll(1, System.Net.Sockets.SelectMode.SelectWrite)
_
= False Then
Return False
End IF

Catch
Return False
End Try

Catch
Return False
End Try

_socket.BeginSend(data, 0, data.Length, _
SocketFlags.None, AddressOf SendCallback, Nothing)

Return True

End Function

[...]

Private Sub SendCallback(ByVal ar As IAsyncResult)

If _socket.EndSend(ar) < 1 Then
Debug.WriteLine("Nothing sent.")
End If

End Sub


I also tried to Set SendTimeout and ReceiveTimeout, but without
effect.
What else could I do to recognize the closed connection?

Kind regards,

Benjamin Lukner
Click to expand...
Click to expand...
Click to expand...
 
Back
Top