[Ovmsdev] v3 hardware disconnecting from v2 server

[Tom Parker]

On 29/01/18 13:29, Mark Webb-Johnson wrote:

> Perhaps we should issue network.mgr.stop earlier? However, even if we 
> close the connections from our end, I’m not sure if the packet would 
> make it through to the other end before the wifi disconnects.

I don't think we need to address the situation where the server does not 
get informed of the disconnection -- the disconnection could happen 
before we know it has happened preventing us from signaling the server. 
This could happen simply by driving away from the wifi network.

What we need to address is informing the client inside the vehicle 
module that it is no longer connected. In the case where we know the 
network has gone down, we can have the OVMS process listen for the event 
and take appropriate actions. In the case where the network is up but 
the socket is broken somewhere in the network and we get a RST response 
or we never get an ACK, we should signal the client. It's been a long 
time since I dealt with raw sockets and tried to handle all the edge 
cases so I'll have to defer to others with more knowledge of the apis to 
suggest how it should work. The v2 client is good in that it transmits 
periodically (which should eliminate the need for TCP level keepalive 
packets on all but the most aggressive networks) so the socket library 
has an opportunity detect the broken socket and tell the client code 
that the socket isn't working.

I wrote an OVMS v2 python client which suffers from the same problem, 
every now and again it needs to be restarted because it thinks it is 
connected but it isn't. Unlike the vehicle module, this client never 
writes to the socket after login but I'm a little surprised the OS 
doesn't eventually say "this socket is broken" or something, I really 
should work out how to fix it (maybe by restarting if there has been no 
data for some number of minutes).