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

[George B. <geo...@gm...>]

Yes, it is broken.  i think I have found the problem - your description 
was very detailed, thank you. Fixing it may take a few days, mostly to 
determine the scope of the affected data, and to make sure there are no 
loose ends.

In the meantime, the problem is being tracked as an issue on github at 
https://github.com/Hamlib/Hamlib/issues/1748.

73 n3gb

On 5/23/25 9:16 PM, Stephen Pattinson via Hamlib-developer wrote:
> 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
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer