PB recovery from network outage / Do PureBasic networking functions require ‘ping’?

[PBJim]

Today we had a network outage at the office and consequently my PB client-side application disconnected from its corresponding PB server-side application. Three users’ PB clients were able to reconnect and continue working after the connection came back up. One PC was unable to reconnect.

Rather than just reboot that PC, I tried to properly establish what was going on. I found that RDP on this user’s PC, connected to that same server without any problems, but my PB application on THIS PC only, was unable to reconnect.

I closed the PB client application and restarted it. It still would not reconnect. Finally I changed the client’s server hostname to the fixed IP address of the server and the PB client then reconnected okay.

To summarise : All PB clients had connected to the server using its hostname, though only that one PC had a problem reconnecting after the outage. It would only reconnect after I changed the server address for the client from 'name' to its IP. On the face of it, it seemed like a DNS problem, but other applications, such as RDP, allowed me to connect using the server’s hostname.

The only oddity I’m aware of is that Windows Server 2019 onwards, doesn’t have ping turned on by default, so I wondered if PB requires ping to be working (a bit of a long-shot I know).

Server and client connections are established with the following :

Code: Select all

svrid.i = CreateNetworkServer(#PB_Any, portno.i, #PB_Network_IPv4 | #PB_Network_TCP, "")

svrcon.i = OpenNetworkConnection(hostname.s, portno.i, #PB_Network_IPv4 | #PB_Network_TCP, netout.i)

Any other ideas on this that might help me to prevent this happening in future? Appreciate any thoughts on this.

[spikey]

so I wondered if PB requires ping to be working (a bit of a long-shot I know).

It does not, the ping protocol (ICMP) is not involved in (normal) TCP or UDP transfers.

it seemed like a DNS problem

That seems unlikely to be the case to me, RDP should have had a similar problem at the same time. However, you can show the current dns cache with:

Code: Select all

ipconfig /displaydns

or force a rebuild with:

Code: Select all

ipconfig /flushdns

Appreciate any thoughts on this.

My first guess would be that the original connection stayed at the TIME_WAIT state on exit and this had cleared down naturally by the time you reconfigured to use the address instead. This state can persist in human time scales, rather than machine ones, if the appropriate ACKnowledgement isn't sent or goes astray. This is entirely feasible in the event of a network failure.
You can check for this using:

Code: Select all

netstat -a

You wouldn't necessarily notice this if the application normally runs all day and only closes when users log off.

[Marc56us]

Hi,

If you're on a local network with few machines and fixe IP, use the HOSTS file.
It will be read in priority to any other name resolution method (and responds instantly).
File to edit on Windows:
%windir%\system32\drivers\etc\hosts
On each client. No need to restart.
You need admin rights to modify this file.

[NicTheQuick]

At first I would try to replicate the behavior by creating the network outage by yourself. If you then get a consistent behavior of that one client you can dig deeper.

[PBJim]

Thanks to all for the replies on this. Today we didn't experience an outage, but I think we need to try to diagnose it when the opportunity presents itself again.

My first guess would be that the original connection stayed at the TIME_WAIT state on exit and this had cleared down naturally by the time you reconfigured to use the address instead. This state can persist in human time scales, rather than machine ones, if the appropriate ACKnowledgement isn't sent or goes astray. This is entirely feasible in the event of a network failure.

Possibly yes. It seemed odd that it wouldn't reconnect, even after shutting down the PB client application, but the three other machines on the network were fine and reconnected.

Just to clarify, but you probably picked this up already from the summary, Spikey - the user was not using RDP at the time of the outage, but the RDP connection attempt was my own attempt, to see if the problem was DNS-related. I opened the RDP session to the same server that's running my PB server-side application, to see if it could find the server from its hostname. It immediately connected via RDP, whereas the PB client application would not reconnect using that same name, even after I closed and reopened it.

At first I would try to replicate the behavior by creating the network outage by yourself. If you then get a consistent behavior of that one client you can dig deeper.

I tested the troublesome PC further by removing and then reconnecting the cable to that user's PC and I found that the PB client was able to reconnect. It seems the outage that we had earlier, was not the same as simply removing the ethernet cable.

If you're on a local network with few machines and fixe IP, use the HOSTS file.
It will be read in priority to any other name resolution method (and responds instantly).

Yes, agreed - the hosts file is always a reliable way, but it's a commercial environment and I can't ask the IT people to set it up in that way unfortunately. I think for now, I'm limited to just waiting until another outage takes place and then I can diagnose further.