> Das kann man heute schon ganz gut in der "rate-de.dat" bei
>
> P:25 CityKom
>
> erkennen, wo Alexander mit unz�hligen "A:" Eintr�gen die Zonen 2 und
> 3 f�r diesen Provider definiert hat.
> (Leider in sofern falsch, als das er dort keine normalisierten
> Telefonnummern stehen hat, dort m��te statt
>
> A:02041 # Bottrop
>
> stehen
>
> A:+492041 # Bottrop
>
> oder auch
>
> A:*2041 # Bottrop
>
> wenn der "*" Wildcard auch links funktioniert ... Michael?)
Das funktioniert so nicht. Wenn ein Stern im A:-tag drinnen ist, mu� ab
dem Stern alles bis zum Ende der Nummer �bereinstimmen. Gemacht habe ich
das f�r Sondernummern, d.h. A:+49*110 w�re die Polizei aus jedem
beliebigen Ortsnetz. Aber das erschlagen wir jetzt eh anders...
Trotzdem halte ich obige Vorgehensweise nicht f�r wirklich sinnvoll.
Sowas geh�rt in eine Verzonungstabelle.
> > * jeder Provider bekommt seine eigene Tabelle. In der isdn.conf steht
> > dann: ZONEFILE=/usr/lib/isdn/zone-at-%p.dat
> > %p wird beim einlesen der rate-xx.dat f�r jeden Provider durch seine
> > Nummer ersetzt, die Dateien heissen dann z.B. zone-at-1012.dat (oder
> > zone-at-12.dat? Vorschl�ge? wie ist das in D mit euren mehr als 100
> > Providern?)
>
> Das w�rde hier in Deutschland per heute so aussehen:
>
> ca. 10 verschiedene Verzonungstabellen (die man aber - siehe CityCom)
> durchaus auch durch diverse "A:" Eintr�ge erschlagen kann
Ach was - eine Verzonungstabelle mu� her! A:-Tags werden damit
vergewaltigt! (auch wegen Performance)
> Meine Verzonungstabelle habe ich "gefunden" ;-)
>
> Sowas kann auch immer wieder passieren, d.h. man erh�lt von irgendwo
> her eine rein bin�re Verzonungstabelle.
>
> Daher d�rfte es leider nicht nur ein einziges, g�ltiges Dateiformat
> f�r Verzonungstabellen geben.
>
> Vielmehr m��te f�r jede Tabelle eine eigene, kurze Zugriffsroutine
> programmiert werden, die nach oben nat�rlich wieder immer dasselbe
> liefert:
>
> int areadiff(char *number1, char *number2)
>
> liefert die Tarifzone zwischen den beiden Telefonnummern.
Na, das sehe ich anders. Wenn du die bin�re Datei und die
Zugriffsroutine hjast, ist es doich ein leichtes, diese Datei in ein
neues Format zu �berf�hren.
> Und richtig: Ich lese nicht die ganze Tabelle ein, sondern halte die
> Tabelle �ber die gesamte Laufzeit von isdnlog offen, und greife
> bei Bedarf direkt auf die offene Datei zu.
>
> Mit Deiner Idee mit den symlinks w�ren das nat�rlich �ber 100 offene
> Handles auf letztendlich immer dieselbe Datei ... Irgendwie bl�d ;-)
Das ist richtig... andererseits gef�llt mir die Idee mit den symlinks
schon recht gut, wir brauchen nicht noch ein Tag.. isdnlog k�nnte ja den
symlink erkennen und den originalen Datiedeskriptor verwenden!
Nichtsdestotrotz: Wir brauchen also ein Konzept f�r die Zonenermittlung!
Vorgaben:
ca. 5000 Vorwahlen (in �sterreich sinds ca. 1000)
das sind (5000*4999/2)=12,5 Millionen M�glichkeiten
ich denke, die am �ftesten vorkommende Zone (Fernzone?) kommt nicht in
der Datenbank vor, daraus kann man auch die korrekte Zone ableiten.
Wieviele andere M�glichkeiten gibt es?
Die Zoneninfo selbst ist 1 Byte lang, damit haben wir 255 Zonen.
Ich m�chte gar nicht unbedingt ein ASCII-Format haben, da die Datei
nicht in den Speicher eingelesen wird, sondern der Suchvorgang direkt in
der Datei stattfindet. Damit haben wir auch nicht unbedingt Wildcards
zur Verf�gung.
Also, Leute: wir brauchen einen Zugriffsalgorithmus, der halbwegs
schnell ist, und ein Format f�r die Verzonungstabelle!
bye, Michi
--
netWorks Vox: +43 316 698260
Michael Reinelt Fax: +43 316 692343
Geisslergasse 4 GSM: +43 676 3079941
A-8045 Graz, Austria e-mail: [EMAIL PROTECTED]
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
