[Hamlib-developer] Issue with simultaneous access to rigctld by multiple TCP clients - Probable Low Priority

[Stephen P. <st...@bi...>]

Hi,

I have several programs that interrogate rigctld simultaneously which 
among other things request various radio parameters from my IC-7300 
every second. With just one rigctld client program running I have no 
issue, but I have discovered a number of issues that the developers may 
or may not consider worth of rectification, when multiple rigctld 
clients request radio parameters more of less simultaneously.

I can work around these issues, but nevertheless, I think they are worth 
of reporting.

Hamlib version is  -  hamlib-w64-4.6.2

Windows (10) DOS Command to start rigctld is as follows: “rigctld -m 
3073 -r COM4 -s 115200 -vvv”

These issues are probably all related or indeed have the same cause, but 
I’ll list separately.

1 – Two Python programs are requesting the ptt status of the radio every 
second. There is no synchronization between the two programs, so whether 
or not they request the ptt status at the same time is hard to say. The 
programs also request the frequency and mode of the radio.

Both programs request the ptt status using the “extended” method, ie the 
TCP message is (in Python code). I’m using the optional ‘|’ separator as 
can be seen from the code snippet

     sentBytes = rigctldSock.sendall(b'|t\n')
     response = rigctldSock.recv(1024)

The response should be                         b'get_ptt:|PTT: 0|RPRT 0\n'
however, every now and again, the response is of the form 
b'get_ptt:\nPTT: 0\nRPRT 0\n'

which causes my parsing to fail. The response looks like the result as 
if the ‘+’ separator was used, however this is not the case. Perhaps I 
can avoid this by using the ‘+’ separator, but it shouldn’t be necessary.

2- Running the commercial LOG4OM program which is configured to use the 
“Hamlib NET rigctl Stable” rig model, and one of my Python programs has 
a similar effect as described in issue 1 above. I don’t of course know 
the exact command that LOG4OM is using other than it is communicating to 
rigctld on port 4532.

Also, the issue arises with multiple parameters. Once again, my program 
uses the ‘|’ separator character. I don’t know what LOG4OM uses, or 
indeed if it uses the “extended” or “default” method.

As before, expected responses are of the form ( for get_ptt and get_mode 
commands)

     b'get_ptt:|PTT: 0|RPRT 0\n'
     b'get_mode:|Mode: LSB|Passband: 2400|RPRT 0\n'

however, occasionally the responses are

     b'get_ptt:\nPTT: 0\nRPRT 0\n'
     b'get_mode:\nMode: LSB\nPassband: 2400\nRPRT 0\n'

which fails my parsing due to the LF char unexpectedly replacing the ‘|’ 
char.

The cause is no doubt the same as in issue one. It may or may not matter 
if two programs accessing rigctld use the same separator character.

3 – A similar issue arises if one rigctld TCP client is using the 
“default” protocol and other the “extended” protocol more of less 
simultaneously.

For example, I have one Python program accessing rig frequency using the 
“extended” protocol which results in a response of this form

     b'get_freq:|Frequency: 1424840|RPRT 0\n'

at the same approximate time, the second client program uses the 
“default” protocol which results in a response of this form

     b'1424840\n'

however, every once in a while, the response to the “default” protocol 
results in this response

     b'1424840|\n'

It appears that the “default” response has been “infected” by the 
separation character of the “extended” response due to the other client.

Of course, maybe I shouldn’t allow mixing of the two types of request, 
but of course I have no easy way of knowing what any other arbitrary 
program might be using that may simultaneously request radio parameters.

In summary, I feel these issues which probably all have the same root 
cause may warrant looking at, but I will totally understand if it is 
regarded as low priority or not worth fixing. In my case, I’ll probably 
alter my programs to use the ‘+’ separator character that results in 
‘\n’ characters separating the fields as I suspect this is what is 
usually used.

Thanks for reading.
Rgds
Steve
VK3SPX