Yes, indeed, those layers need to be designed separately. If it works over TCP and uses only one connection, it will work over serial, and if it uses more than one connection then some means of mux for the serial would be necessary. Deciding the goals and the various bindingd would certainly be part of the design.
Multicast might be useful for some cases, but I suspect the cases are rare. If they are important rare cases then they would have to be addressed. Multicast is generally used for one-to-many audio or video streaming, and there isn't muxh rig control or other activity going on, so just using someone else's better-and-working solution may be fine. For remote access, managing the bandwidth used and adapting to it is the biggest issue I found. I read a number of papers on streaming congestion control. The VOIP folks have a number of solutions already, and as we have seen, the ham community (echolink), the SIP/H.323 community, and commerce (Skype) all have solutions. My opinion is that innovation in this space need not come from the rig control/digimode area. As for serial, it isn't likely that audio needs to travel that way (if you have point-to-point wires, you would run audio wires). But I may be wrong. One solution I found for controlling the rate and bandwidth used for the data streams was a request-response paradigm. It has an advantage over other rate control schemes in that it is simple to implement and goes well through proxies and firewalls if you bind the request to HTTP. The request URI says what is requested (how much spectrum data, how much RX data) and when it's done streaming, it's done and the server sends no more (buffering in the case of RX data, discarding in the case of spectrum data) until the next request comes in. A client can send another request before the first is done to double-buffer and assure continuity from its point of view, but because of network latency and throughput, this automagically translates into a request back to the server at just the right time to prevent exceeding the time-available bandwidth. If this isn't clear let me know. A very fast connection (I.e. On box or in memory) that can send full data with no loss could have larger buffer requests, but given its nature, it would not require infrequent long requests in order to be efficient because of the large available bandwidth. For serial, the request/response paradigm may be the right way to handle mux of rx data, control, and status transfer. Of course, without a TCP connection, the HTTP protocol isn't necessary, but binding just the request URI to the command ("GET rxdata" or "POST rigcontrol") as literal command strings would allow the semantic defninition to be preserved, remain human readable, and still be a small number of bytes. The response data for requests would be different types for different requests. RX data would just be plain text, one or a few chars at a time. Spectrum would be 8-bit bytes, possibly encoded by the lower layer (HTTP provides content-transfer-encoding for this, and the same could be used over rs232 to use 7 bits and avoid XON/XOFF problems). As for Simon's concern about XML, I would recommend it only for certain rig control requests and responses...most can be handled with unique command and individual responses, but sending a sequence of commands to be done at once, or sending obscure rig control commands that are done in an extensible command set would benefit from the structure and the extensibility. Leigh/WA5ZNU On Sat, 17 Feb 2007 8:26 pm, Dave Bernstein wrote: > Suppose there's a transceiver control application with, say, 5 client > applications that must track the transceiver's frequency. If TCP is > the transport, would you suggest that this be handled with multicast, > publish-and-subscribe, or some other approach? > > Does "TCP is good enough" mean that the transceiver frequency as > presented by any client will track smoothly without disconcerting > delay when the user QSYs? > > Rather than weld ourselves to one transport mechanism (again), > perhaps we should only define message semantics. Being able to choose > in-memory, network, or even serial port transports would provide > useful flexibility. > > 73, > > Dave, AA6YQ > > --- In digitalradio@yahoogroups.com, "Leigh L Klotz, Jr." <[EMAIL PROTECTED]> > wrote: >> >> TCP is good enough. Windows and Linux make it efficient on the > box, and >> you always have the option to use "named pipes" or "AF_UNIX" > sockets to >> make it even shorter. X windows works this way and it is plenty > fast >> enough. >> >> Unless you're doing a full SDR data stream though there's no need > for >> that. For digimode, that means just sending TXRX data, spectrum > plots >> (remember the spectrum for the waterfall is sampled in the time > axis so >> it isn't the full audio data), and rig control. Plenty of > bandwidth on >> the box for that, and as a bonus you get cross-platform > compatibility >> and cross-network opewration. I have already demonstrated this > with >> RPSK, and others have proprietary or vendor-specific protocols for > doing >> this. Logging and DX spots are even less bandwidth and TCP is fine. >> >> For data format, XML (and JSON if people want it) are easy to > define and >> there are libraries for every OS. (Fldigi does XML without a > library >> and works fine too.) For command format, HTTP and URIs are fine > too. >> Again, there are libraies, it is standardized, and runs just about >> everywhere. >> >> No, it won't run on an x86 DOS box, but it will run on a PocletPC > and I >> fact I have had discussions with Vojtech about this...he already > has >> support for pskmail in his PocketDigi, and adding TCP remoting > support >> is not hard, and would clearly work even on the $100 WinCE 2000 > Jornada >> I have, and on newer devices. >> So yes, I think the technology is there and it would indeed be a > good >> time to start. >> >> 73, >> Leigh/WA5zNU >> On Sat, 17 Feb 2007 12:17 pm, Dave Bernstein wrote: >> > That said, an efficient platform-independent mechanism for >> > interprogram communication would be both useful and timely. I > suggest >> > starting first on a low-level mechanism to see if an effective >> > working group can be established. If so, then defining a > framework of >> > higher-level abstractions would be the next step. >> > >> > > > > > > Announce your digital presence via our DX Cluster > telnet://cluster.dynalias.org > > Our other groups: > > http://groups.yahoo.com/group/dxlist/ > http://groups.yahoo.com/group/themixwgroup > http://groups.yahoo.com/group/contesting > http://groups.yahoo.com/group/wnyar > http://groups.yahoo.com/group/Omnibus97 > > > Yahoo! Groups Links > > >