From: Nate B. <n0...@bl...> - 2007-11-09 02:19:20
|
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. > The way I have been thinking about this (I admit I've not spent much > time on it) would be to make two processes (the lower two here) as > part of hamlib, with a third process (at the top in this picture) > being a rig control user interface, like this: > __________________ > > | | Client programmes link to a hamlib > | > | User interface | stub library which just sends requests > | rig control prog | over the net to the main hamlib daemon. > |__________________| Uses a single set of standard requests. > | > | ^ As I envision it, the above is rigctld. I'm not sure of which definition of "link" you're using, the software compilation sense or a network link. 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. > TCP/IP |net| connection > _______V___|______ > > | | Main hamlib code, translates requests as > | > | Main hamlib rig | appropriate for the rig in use. Makes > | control daemon | "send this string" / "read reply" type > |__________________| requests to the hardware interface daemon. > | > | ^ > > TCP/IP |net| connection > _______V___|______ > > | | Small daemon to interface to a single > | > | Physical hardware| type of hardware, one should be available > | interface daemon | for serial port interfaced rigs, one for > |__________________| parallel ports, one for USB, etc. The two above blocks are the existing Hamlib frontend and backend libraries and would remain unchanged. rigctld would link to the frontend just as the rigctl test program does. > I wouldn't like to restrict the protocol to strict request/reply RPC, > but also allow the lower levels to send unsolicited information back > up the chain. This is useful for reporting errors or other unexpected > events without waiting for the user to try to do something. > > To allow this, I think that each message in either direction should be > self-identifying, eg. don't just send an s-meter reading as a reply to > a read s-meter command, but reply with a message saying "the s-meter > reading is this value". This means that nothing gets confused when the > message which comes back is in fact "lost contact with rig - possible > power failure", or "antenna rotator has finished moving". Doing this > even allows for such extensions as connecting the rig to an audio > card, and sending audio data back along the same connection. (Though > in this particular case a separate UDP stream may be more appropriate). Interesting. > I still think that the main translation daemon in the middle should be > table based, with one table of translations for each rig type, which > is loaded from information that an end user can supply or modify to > match his rig. The only table or translation needed as I see it, is from the client to daemon protocol to the Hamlib API. This is done in rigctl already for the interactive commands so that is why I'm thinking of it as a model. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @ | a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org |