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
>
>
>
