[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: AO40rcv and the Kenwood TS-2000



> Date: Thu, 5 Apr 2001 16:40:02 +0100 (BST)
> From: John Melton - Sun UK - ENS <John.Melton@Sun.COM>
> Subject: Re: [amsat-bb] AO40rcv and the Kenwood TS-2000
> To: amsat-bb@AMSAT.Org
> 
> > Interoperable between independent implementations that wish to
> > communicate with each other.  Again, I believe that the context of this
> > discussions is protocols for connecting pieces of amateur
> > radio-related software executing on different machines communicating
> > over an IP network such as the Internet.
> 
> Isn't this a good example of specifying an abstract interface for the 
> application protocols and then specifying different bindings to different 
> transport methods.

John,

I think we are saying slightly different things, but I'm not entirely
sure.

As a networking person, I want to specify the bits as they appear on
the wire (or on the air).  I don't particularly care (being just a
networking person) how the application generates the appropriate string
of bits.  I just care that all applications generate the same 
sequence of bits so that different implementations interoperate.

> A good way to go may be to define the application protocol using XML.

Being a lower-level networking guy, I generally like much more terse
encodings than provided by XML.

If I were developing this protocol, I would use type/length/value
tuples (TLVs).  Each message would be composed of one or more TLVs.
Each TLV would like:

          -------------------------
          | Type | Length | Value |
          -------------------------

Where:

	"Type" is a type code, perhaps a command code.  The Type field
	could be a fixed length (e.g., one or two bytes) or could be
	variable length (e.g., if bit 7 is set, another byte of Type
	follows.

        "Length" specifies the length of the "Value" portion of the TLV.
	Again, this could be a fixed length field (one or two bytes is
	pretty typical) or a variable length field.

	"Value" is a parameter associated with the Type code.  If
	you want (as the protocol designer), you could allow TLVs
	in the Value field.

For example, you might create a protocol in which a particular Type
code means "issue this command to the transceiver" and the Value
field could contain "UP" (the value to send to the transceiver).
Alternatively, a different protocol might contain a Type code that
means "increase the transceiver receive frequency" and the value might
specify the number of Hz by which the frequency ought to change.

TLVs are common in IP protocols, particularly lower-level protocols.
They are used in OSPF (an IP routing protocol) and RSVP (readers who
have never heard of RSVP can just consider it to be another IP
routing protocol).

A TLV-based protocol is fairly easy to extend.  Receivers are able to
skip TLVs that they don't understand, and still find the next TLV
(by looking at the Length field).  RSVP goes a step farther, and
classifies type codes as "if you don't understand this type code,
just skip it" and "this type code is really important, so if you don't
understand it, just give up".

I really hate to say that we should optimize protocols for 1200 bps
AFSK, but I do like concise encodings.  As such, I am not always a 
fan of XML.  On the other hand, I have been meaning to look at the
WAP binary XML spec, which (I think) creates a smaller encoding of XML.

(Actually, at one point I suggested that amateur transceivers such
as the Kenwood D700 and THD7 should use WAP.  Perhaps, I would be able
to communicate with my rig from my cell phone.  But, now that I have
played with Java 2 Micro Edition (J2ME), I think that perhaps rigs should
support J2ME.)

> If we then stated that every application written implements the XML binding 
> using a TCP/IP socket connection as the minimum,  this would allow
> interworking with any other apppication (written to the spec) running on
> any platform.
> 
> Now lets say that we define a binding of the protocol to RMI.  A Java 
> application would implement the XML/Socket interface as required and could
> also implement the RMI interface thus allowing 2 Java applications to
> communicate that way rather than using the XML/Socket interface.
> 
> Other bindings could be specified for other inter program communications 
> methods.

Beats me.  I am just a networking guy.  To me, interoperability means
specifying the bits on the wire.  The world may be a better place
if someone else thinks about application-level bindings.

-tjs
----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org



AMSAT Top AMSAT Home