From: Riley Williams (smeexbkn.zboovisdge@amw.gdynia.pl)
Date: Sat Mar 02 2002 - 00:54:40 EET
Hi Tomi.
>>> I would like to see a predictd daemon completely without any UI
>>> whatsoever.
>>
>> Eventually, I'd like to see that, but for testing purposes, I'll
>> be retaining the UI for the time being.
> Yep.
>>> It would handle unlimited amount of satellites and the TLE data
>>> could be updated without taking the daemon down (standard way
>>> would be to make the daemon re-read its config files upon
>>> receiving SIGHUP, I guess).
>>
>> Whilst that's certainly possible, I could see problems with that.
> Well, virtually unlimited then? A compile time option that can be
> set to 1000 without any problems?
That's not the sort of problem I was referring to - I was thinking more
along the lines of the nature of the TLE's meaning that tweaking the
configuration files would be a less than ideal method of updating the
details.
What I would be more inclined to look into is the idea of splitting
predictd three ways...
1. A TLE server, which specialises in supplying TLE's to any
client that wants it, and knows how to update the TLE's
automatically based on information in its configuration
file. Call this tleservd for reference.
2. A prediction server, which knows how to make predictions
about a satellite, and how to talk to tleservd, and with
the capability of passing requests from clients straight
through to tleservd where relevent. Call this predictd for
reference.
3. A user interface, which queries whichever of the above is
relevant for the information it needs.
The clients would talk to either tleservd or predictd depending on their
needs - those that had no need of predictions would talk direct to
tleservd whilst those needing predictions would talk to predictd and let
it pass requests through to tleservd when relevant.
The predictd server would start life with an empty list and read its
configuration file for a list of hosts to check for tleservd servers,
together with a list of satellites to get details of by default. It
would listen on its assigned port for clients asking for service, but
would also ask the tleservd servers for TLE's for the named satellites.
It would also try to get updates for any TLE's for which the epoch was
more than 48 hours ago, and would discard any for which the epoch was
more than 30 days ago.
When a client connects and asks for a satellite not in its current list
of satellites, predictd would return a PLEASE_WAIT response whilst it
tried to obtain a current TLE for the specified satellite. If it was
unable to do so, it would follow up with a NOT_AVAILABLE response to
indicate that it had not been able to obtain details of the requested
satellite, otherwise it would return the relevant prediction for that
satellite.
>>> Needless to say the clients (that would also include a ncurses
>>> client similar to the current predict UI) should not make any
>>> assumptions on any data the server might give.
>>> Including the number of satellites.
>> To be reasonable, the clients should be able to ask the server for
>> any limits it may reasonably need. The number of satellites the
>> server can supply it with is a perfect example of such information,
>> and is an early planned addition. Expect a patch shortly...
> Sure, any limits that can be asked from the server should be asked.
> But to be honest even the basic course in programming (and rest
> assured, that is all I ever had, I am a RF engineer to be) stresses
> that you should never rely on the format of any data that a user or
> a network peer can supply. :)
That is very true, but there are certain assumptions one has to rely on,
and this is one of those areas. The attached patch adds the GET_MAXSATS
call to the current PREDICT code (exlcusive of my previous patch), and
all it returns is the maximum number of satellites that the server can
handle. By the nature of the code, this number can't be exceeded, but
there is no guarantee that a lesser number of satellites are currently
being handled. Any program that can handle UP TO the number stated will
get no surprises from the resulting server.
> Anyway, waiting for your patches. Predict is cool software and your
> additions make it even better.
Many thanks.
Best wishes from Riley.
This archive was generated by hypermail 2b30 : Sat Mar 02 2002 - 00:56:36 EET