Network interruptions, what controls the timeout period?

[Oso]

A general question but relates to PureBasic, since I'm looking at developing a workaround with PB. I've done some tests relating to network disconnections, as it's something that's causing us a problem lately. Our VPN supposed to be up all the time, between three offices, but it suffers from traffic interruptions, to the extent that the software application loses connectivity (it requires a persistent connection).

My tests with a network cable, a PC and a server, show that a connection is able to withstand several seconds of loss of connectivity and this includes a PureBasic application, as well as others. When I plug the ethernet cable back into the machine, it will happily continue, so long as :

a) I didn't try to send anything while it was disconnected
b) It wasn't more than a few seconds

What specifically is responsible for this period of time that's allowed for the disconnection (b) and can it be increased? Thanks.

[Marc56us]

Hi Oso,

It is usually the server application that is programmed to cut off communication if it does not receive anything from a client for a certain period of time.
To prevent this, a signal can be sent at regular intervals. For example, FTP clients can send a NOOP (NO OPeration) command. (See parameters)
On network disks, a simple PING or directory listing etc. can be sent. So in your application sent for exemple an empty string each 30 sec.

In other case, it's always best to free up network resources that are no longer needed, for the good management of servers resources.
For example, it's better to use UNC-type resources (copy * to \\serveur\share) than to map disks all the time.

[Oso]

Hi Oso, It is usually the server application that is programmed to cut off communication if it does not receive anything from a client for a certain period of time. To prevent this, a signal can be sent at regular intervals. For example, FTP clients can send a NOOP (NO OPeration) command. (See parameters)
On network disks, a simple PING or directory listing etc. can be sent. So in your application sent for exemple an empty string each 30 sec.

Thanks for the reply Marc56us, I agree with all those things you've said. That all makes perfect sense.

I already have a 60-second keepalive and the server software needs a persistent connection anyway, because it's a character-based application (it isn't client-server). In other words, it isn't like a web-browser where it only needs to transmit and receive when a user clicks a button. This is via Putty terminal emulator by the way.

It was more a question about the physical disconnection of the network. During my own testing, I found that when pulling out the ethernet cable for a brief 5 or 10-second period, it was fine. But after those few seconds, it gets dropped if I don't reconnect the cable quickly. I'm guessing that the maximum time allowed for disconnection is hardware-dependent, but I wondered if it's possible to increase it. I think the VPN service is not giving full availability. On Friday, I lost my RDP session at exactly the same time Putty lost its connection to the server application.

In other case, it's always best to free up network resources that are no longer needed, for the good management of servers resources.

In this case they are all needed, because they are persistent screens with real-time data being displayed. It's rare that the screen sits there doing nothing, in fact the connection is sometimes dropped when the users are actually entering data. I believe it's the VPN that's dropping the communication — it isn't perhaps disconnecting fully, but just stopping periodically and that seems to be enough to disrupt Putty's connection with the server. Hope that all makes sense anyway.

[idle]

Could it just be Dhcp renewal, Try static ip

[Oso]

Could it just be Dhcp renewal, Try static ip

That's a thought From what I'm told, there are occasional bad days when several people lose their connection. I don't know if they all happen together — they probably don't know themselves, to be fair, because one person might notice the screen disconnection sooner than another.

Just thinking about IP6 in this context also. I suppose that since the client PCs are connecting to the server using IP4, then the IP6 probably isn't going to matter much.

[idle]

Could it just be Dhcp renewal, Try static ip

That's a thought From what I'm told, there are occasional bad days when several people lose their connection. I don't know if they all happen together — they probably don't know themselves, to be fair, because one person might notice the screen disconnection sooner than another.

Just thinking about IP6 in this context also. I suppose that since the client PCs are connecting to the server using IP4, then the IP6 probably isn't going to matter much.

We don't really need Ipv6, NAT over ipv4 seems to works fine, maybe there's a way to schedule dhcp renewal on your routers or switches if that's the cause and don't want static IP addresses which might be considered a weakness in the network security.

[Oso]

Just thinking about IP6 in this context also. I suppose that since the client PCs are connecting to the server using IP4, then the IP6 probably isn't going to matter much.

We don't really need Ipv6, NAT over ipv4 seems to works fine, maybe there's a way to schedule dhcp renewal on your routers or switches if that's the cause and don't want static IP addresses which might be considered a weakness in the network security.

Possibly, but getting things like that done by the main in-house IT department is usually a challenge and they tend to rely on third-party providers for anything beyond the basics. Changing the IP addresses at one of the office sites to "fixed", as a temporary measure, is probably more easy to achieve. Once we get to the bottom of it, at least we know what we need to do.

It used to be that this site had leased lines between the locations, but a few years ago they were replaced by virtual networks. We didn't get many outages before then, in fact I think the connections stayed up for months at a time.

[spikey]

It used to be that this site had leased lines between the locations, but a few years ago they were replaced by virtual networks.

I'm guessing this means one of the xDSL technologies is now in use? Although touted as an "always on" internet connection xDSL isn't necessarily so. It's only "always on" in comparison to the V.9x dial on demand technologies it replaced. xDSL connections suffer from drop outs periodically from a number of sources but are "always on" in the sense that automatic reconnection and transmission speed adaption is built into the protocols. You should also check your routers' logs at both ends to see if xDSL drop outs are involved.

[Oso]

It used to be that this site had leased lines between the locations, but a few years ago they were replaced by virtual networks.

I'm guessing this means one of the xDSL technologies is now in use? Although touted as an "always on" internet connection xDSL isn't necessarily so. It's only "always on" in comparison to the V.9x dial on demand technologies it replaced. xDSL connections suffer from drop outs periodically from a number of sources but are "always on" in the sense that automatic reconnection and transmission speed adaption is built into the protocols. You should also check your routers' logs at both ends to see if xDSL drop outs are involved.

It was via a DSL service until last November, when fibre internet was installed. If anything, I think the problem has been worse since the change to fibre, but it's difficult to be precise, because there's no clear point when it started disconnecting users.

I've been doing a lot of testing on my own separate LAN. I found that I can disconnect a LAN cable between the Putty client and the server and it doesn't cause any problem, even for long periods, unless it attempts to transmit while disconnected. But the complication is that we also need to use keep-alive (SO_KEEPALIVE), otherwise they get purged by the network from lack of periodic traffic. Currently keep-alive is set to 70 seconds, which perhaps is a bit too frequent. But we can't really win — because while disabling keep-alive might successfully allow the client to ignore the pauses in VPN communication, the users would then need to periodically send/receive some data, otherwise they'll get dropped anyway.

[Oso]

A quick update on this saga of the dropped connections via remote office VPNs. The fixed IP address changes, intended to avoid DHCP, didn't have any effect, unfortunately, though thanks for that Idle — it did sound promising.

My thoughts after many hours of remote observation, watching the server logs and hearing users' stories, is that the internet is not dropping its connection, but that the VPN service provider is clearing what it regards as old socket connections. They happen to be the connections of users who have the application open, but perhaps haven't triggered screen data updates for a while. We already send keepalives frequently, so I think possibly the keep-alive is being ignored, as it's only a null packet, anyway. And I noticed that keep-alives are ignored when there's a severed network connection, whereas 'real' data triggers a connection error.

All interesting stuff, but frustrating.

Incidentally, PureBasic's network handling, by contrast, seems very robust. For example, when using Putty terminal emulator, if the network is disconnected and the user presses an input, this will immediately abort Putty with an unrecoverable fatal error. A PureBasic client-server app. that I wrote, as a test, is robust and keeps trying, until finally giving up.

It seems that Putty is pretty poor at dealing with network outages and immediately aborts at the slightest problem, despite its widespread use.