locked Re: Not logging some QSOs to DXKeeper. #DXLAB


g4wjs
 

On 05/07/2020 23:36, HamApps Support (VK3AMA) wrote:
On 5/07/2020 9:25 am, g4wjs wrote:

Hi Laurie,

a socket close call is not the same as doing a socket shutdown call first. Is this code AutoIT or .Net?


--
73
Bill
G4WJS.

AutoIT. The TCP logging component in JTAlert is not part of the new .NET based JTAlertV2.Manager code. What AutoIT does under the hood is unknown, it only offers a TCPCloseSocket command, but that is likely their friendly description of the function executing the low-level TCP instructions.

I just stopped the auto logging to DXKeeper, 20 hours continuous, logging every 30 seconds. Not a single QSO was lost, 2410 records sent and logged.

Before I shutdown the Test, I went into DXKeeper and deliberately changed the Base Port of the Network Service (from 52000 to 62000) which as expected stopped DXK from receiving the logging instructions. JTAlert correctly identified an inability to connect (recorded a standard 10060 error) after 10 retries. Resetting the DXK port back to 52000 and logging resumed.

Perhaps a Network Service restart is all that is needed, rather than a DXKeeper restart if the failed logging occurs again.

At this time, I don't know where else to look.

de Laurie VK3AMA

Hi Laurie,

RR on all, I did look for the sources of the AutoIT TCP Socket code but that part seems to be closed source. I do note that by default a socket close() operation on on Windows makes a reasonable attempt to do a graceful shutdown, so I doubt that closing the socket after each logging event is the source of this issue.

Did you look at the support request from Steve M5BFL, it was his PC running at my shack where the problem occurred, I wonder if there was anything helpful in the debug files?

Another possibility is that DXKeeper has an issue with handling multiple TCP/IP client connections concurrently. Maybe if a logging event takes an extended time, due to Internet actions on my very poor shack WiFi connection, the next QSO logged could cause JTAlert to start a new connection while DXKeeper was still finishing its end of the last connection. Steve was very busy running a frequency using FT4 at  the time so QSOs were being logged at a fast rate.


--
73
Bill
G4WJS.

Join Support@HamApps.groups.io to automatically receive all group messages.