Originally reported at https://sourceforge.net/p/hamlib/mailman/message/59187189/

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