From: Riley Williams (mhfhtg.nwlylkq@netdirect-online.co.uk)
Date: Fri Mar 01 2002 - 23:05:12 EET
Hi Delbert.
> With such an ambititious set of changes to Predict, perhaps one big
> change would be worth considering. How about splitting the engine
> part into a daemon (predictd?) with a separate program for the
> front-end user interface? With the graphical programs out there
> using Predict, this would make the setup and control much easier.
I'm planning on doing something along those lines in the long term, but
before I do, I want to get the source code tidied up somewhat, and also
to sort out a coherent interface. I've already spotted quite a few
vulnerabilities in the existing code that need dealing with.
> To expand on this a bit, it could even be taken on to have
> "predictd" share the TLE sets between instances. Child servers
> could poll a master server for elements rather than each having to
> go through the full import process.
Before we get to that stage, we will need to have the protocol for both
clients and child servers to talk to parent servers specified, but given
that, we could easily end up with the equivalent of an "ntp" tree of
predictd servers, with a few master servers at trusted sites feeding the
TLE's down through various layers to other servers worldwide.
> Just bouncing around a few ideas...
The more the merrier - I could easily overlook something worthwhile on
my own, so all suggestions are appreciated.
Best wishes from Riley.
> -----Original Message-----
> From: shbazu@kerailya.tunkki.fi
> [mailto:yirmvsrz.dsbhzbtmou@tsukuba.ac.jp]On Behalf Of Riley Williams
> Sent: Friday, March 01, 2002 3:04 PM
> To: EB3CZS Xavier Crehueras
> Cc: Linux Ham Radio
> Subject: Re: Predict 2.1.5
>
> Hi Xavier.
>
>>>>> Beware that this can cause problems with other programs that use
>>>>> Predict as a server. For example gsat segfaults, apparently because
>>>>> it doesn't check the size of the satellite list received from the
>>>>> server and this results in a buffer overflow (gsat is hardcoded for
>>>>> 26 satellites IIRC).
>
>>>> Hmm, I think I will wait for John KB2DB to incorporate the patch
>>>> into the next release... Thanks for the comments.
>
>>> As part of my patch, I will be dealing with problems encountered in
>>> ALL of the clients included with predict, so the above shouldn't be
>>> a problem when I've finished.
>
>> I'm the author of gsat. I don't want you to waste your time writing
>> a patch. I will release version 1.0.0 of gsat soon. This new version
>> will run ok with more than 24 satellites.
>
> I have a patched version of predict running here with 74 satellites, but
> it crashes on anything other than a 50-line screen, so I'm reworking it
> at the moment. The patch I released is the first part of my rewrite.
>
>> Gsat was written for predict and because of this, the 24 satellites
>> limitation was hardcoded. I tried once the 50 sats patch, but I
>> didn't like it very much.
>
> Given my patch, there's a very simple patch that raises the limit to 26
> satellites and uses the letters Y and Z for the extra two satellites.
> The enclosed patch (which includes my previous patch) raises the limit
> this far, if that's of any interest. It also deals with a minor niggle
> related to having less than the maximum number of satellites in the
> list, as far as the selection display is concerned.
>
> However, beyond that, one has to deal with the fact that one needs a
> multi-character identifier for various functions.
>
>> John and I implemented an option to be able to configure the network
>> port on which predict listens in server mode. This allows you to
>> have multiple instances of predict servers running, each one with
>> his own set of TLEs. This way you can have as many satellites as you
>> want, and have they classified in different servers (ex. Amateur,
>> Weather, Comms, etc ...).
>
> My plans for this patch would effectively duplicate that functionality
> within a single instance of predict, and can be summarised as follows:
>
> 1. Satellite groups are identified by a group of three letters.
> This allows for up to 26*26*26 = 17,576 groups. However, the
> group ALL will be special, and will not be editable. It will
> consist of every satellite known to PREDICT, in random order.
> This leaves 17,575 groups that are editable.
>
> 2. Each group consists of up to 26 batches of satellites.
>
> 3. Each batch consists of up to 26 satellites, allowing a
> maximum of 676 satellites in each group.
>
> 4. The GET_LIST server command will specify a particular group
> of satellites, and will thereby receive details of up to
> 26*26 = 676 satellites. If no group is specified, the group
> DEF will be assumed (for compatibility).
>
> This allows for a maximum of 17,575*676 = 11,424,400 satellites, and
> retains compatibility with software that isn't aware of this extension.
> It also allows groups to be set up to categorise the satellites as the
> user requires, although the following assignments would make sense...
>
> GPS Global Positioning System.
>
> HAM Amateur Radio.
>
> RKT Rocket Boosters.
>
> SKY Weather satellites.
>
> ...and one can probably easily think of others. Once the patch is
> finished, one could easily add default categories with the correct
> contents in the predict/default directory with names such as...
>
> predict/default/group.ham.a
>
> ...for the amateur radio group, batch A. These would simply consist of
> the satellite numbers (the second number on the last line of each TLE)
> in random order. I say the satellite number because the satellite name
> can (and does) change, but the satellite number remains constant.
>
>> To prepare a TLE file, you must create a file with the TLEs of 24
>> satellites and do this for every server you want, and then launch as
>> many predict instances as you want with:
>>
>> predict -t <tle file> -n <network port> -s
>>
>> To update the TLEs, you don't have to edit the TLE files again. You
>> go to the main menu in predict and press U, then enter a file name
>> with new TLEs and predict will update your TLE files automagically.
>
> How does the above proposal sound to you?
>
> Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to ebsingoy@mx.dy.fi
More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2b30 : Fri Mar 01 2002 - 23:07:40 EET