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

Re: Proposed Internet Space Telemetry Protocol

>In the UNIX tradition, that archiving function could be done by a separate
>process which connects to a TCP/IP server in the same way as a normal
>client.  That way, it could be run on the server itself, or by anyone who

Exactly. I've been doing something much like this for the past three
years with the GPS navigation messages from my TAC-2. One Linux daemon
(started automatically at boot on the machine I leave up all the time)
reads the Motorola Oncore data from the serial port, parses it into
frames (made hard by the brain-damaged Motorola binary format), and IP
multicasts them onto my house LAN.

Another daemon listens to that same multicast address and logs each
qnew packet to disk, automatically suppressing messages in which the
only change is the time of day. Since the GPS ephemerides are updated
every two hours, that results in only one logged message every two

The logging daemon just happens to run on the same Linux machine as the
daemon that does the multicasting, but this is by no means necessary.

A third command can be run interactively that listens to the same
multicast address and interprets in human-readable ASCII anything it
hears. This can run on any machine in the house, in any number of
instantiations, without any increase in network traffic.

Because I use IP multicasting, there is nothing to keep me from making
this data available to the entire multicast backbone, should I want to
do so. I probably will once I rewrite the software to use the new
standard protocol I'm now defining; this will serve as a good test to
ensure that the standard is good for at least one thing other than
carrying AO-40 telemetry.

I note that multicasting would support an efficient way for end users
to discover logging servers and to request copies of logged data.  The
protocol would go something like this:

Requesting user->multicast address: I need AO-40 telemetry between 0000-0100 on Nov 16 2000.

Server1->requesting user: I have 100 blocks in this range

Server2->requesting user: I have 45 blocks in this range

(Note that the answering servers send their responses directly to the
requesting users; they are not multicast.) The requesting user is then
free to ask the servers directly for the blocks they want, perhaps
first subdividing the time periods to determine more precisely who has
what. And because multicasting is done at the IP level, it would
almost certainly be *much* faster than anything based on application
layer relays.


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