Re: [Hamlib-developer] rigctld idea, programmers needed :-)

[Stephane F. <f8...@fr...>]

Hi Nate,

First of all, let me tell you I like your idea about rigctld.

Thu, Nov 08, 2007 at 08:19:26PM -0600, Nate Bargmann skribis:
> On Thursday 08 November 2007 09:29:33 Dave Hines wrote:
> > Hi Nate,
> >       I Like the idea of a socket based control daemon, but I strongly
> > believe that the protocol should be TCP, not UDP. UDP is fine for
> > those operations which are idempotent, but some are not. The
> > specification of the UDP protocol allows packets to be lost, delivered
> > out of order, or even duplicated... and yes, I have seen all three of
> > these in practice (though out of order is very rare). For some
> > operations this is fine, but for example the sequence of setting the
> > transmit frequency, auto-tuning the antenna matching unit, then sending
> > a short burst of morse, could suffer badly from any of these
> > problems. Any reply packets from the daemon to the client could also
> > affected by this. TCP is designed to eliminate all these issues.
> 
> I don't disagree at all.  I tossed out UDP since it seems to work with 
> cwdaemon.  For anything critical outside of localhost operation UDP may prove 
> to be too unreliable.  TCP is probably as easy to implement as UDP on both 
> the client and daemon.

rigctld could offer both UDP and TCP interface. IMHO the protocol built
on top of UDP should work only for one way commands (set_freq, ..).
Anything that needs a response (get_level STRENGTH, ..) should use the
TCP interface.

The protocol would be so simple the following command should just work:

	echo "F 14266000" | nc localhost 4532
or
	echo "set_freq 14266000" | nc localhost 4532

Rem: I started playing with "nc -l -p 4532 -e rigctl", but this has
lot of shortcomings. A proprer rigctld is really needed.

[..]
> What I see rigctld trying to solve is the requirement for client applications 
> to link in the compilation sense to Hamlib.  All that would be required of 
> the client is to open a TCP port and speak the protocol.  This would be an 
> entirely programming language independent interface to Hamlib.  This would 
> also make downstream distribution maintainers' lives easier as a new release 
> from us wouldn't require a recompilation of clients using the network 
> interface.

I do recognize that linking against Hamlib is too heavy. While Hamlib has 
been designed to modelize a complete rig with description of features,
even the weirdest, most end-user applications don't care about it. They
just need to set_freq, set_mode, get_strength and that's it (well, maybe 
a little more, but you get my point).

So I do agree with you Nate. rigctld whould help in many areas.
On top of the advantages you mentioned, it would have the advantages
of rpcrigd, that is, enable multiple applications to access the rig
at the same time. 

What you're loosing with this protocol interface is the model description 
of the rig, but it's not used much, and serves different needs.


Ok, I think I've understood your idea, something ligth, simple but
efficient (la simplicité fait l'élégence). It should be a matter of
a two hour hack, openning sockets and making scanf/printf work against
the socket instead of stdin/stdout. I'll see what I can do over the
week-end.

Rem: for SDR folks around here, there's a new DttSP backend in town.
sdr-core must be running already, then you can play with
"rigctl -m 2303 -C tuner_model=2507" or any other Hamlib application.
The model ID 2303 is DttSP, and 2507 is the Elektor SDR-USB I/Q downconverter.
It tunes the whole 30MHz spectrum as easily as any other standard rig.

Cheers
-- 
Stéphane - F8CFE