Keepcon.todo: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 15: Zeile 15:
* critical "ftp" sollten angebbar sein!
* critical "ftp" sollten angebbar sein!
* !!!trafic mass controll!!! via "ifconfig" mit dem entsprechenden interface.
* !!!trafic mass controll!!! via "ifconfig" mit dem entsprechenden interface.
   Also ein Datenbank Eintrag wieviel Daten über die jeweiligen Interfaces geflo
   Also ein Datenbank Eintrag wieviel Daten über die jeweiligen Interfaces geflossen
   ssen sind.
   sind.
* Zwangstrennung avoid. Nach 2/3 der Verbindungszeit (und Stille)könnte ein
* Zwangstrennung avoid. Nach 2/3 der Verbindungszeit (und Stille)könnte ein
   freiwilliges Trennen erfolgen, sobald keepcon keinen aktuellen traffic
   freiwilliges Trennen erfolgen, sobald keepcon keinen aktuellen traffic
Zeile 26: Zeile 26:
   oder eine "Fehlermeldung" liefern.
   oder eine "Fehlermeldung" liefern.
* Weak-Remote (hhtp-get dazu notwendig) ->wget. Nicht via ftp, sondern http:
* Weak-Remote (hhtp-get dazu notwendig) ->wget. Nicht via ftp, sondern http:
   Es brauchen nicht unnötig Geheimnisse weitergegeben werden.
   Es brauchen nicht unnötige Geheimnisse weitergegeben werden.
* im ip-down (z.B. ausgelöst durch eine Zwangstrennung) ein Signal an keepcon
* im ip-down (z.B. ausgelößt durch eine Zwangstrennung) ein Signal an keepcon
   schicken, damit weitere Schritte (z.B. erneute anwahl) ausgeführt werden
   schicken, damit weitere Schritte (z.B. erneute anwahl) ausgeführt werden
   können. Wie kann man jedoch elegant eine Interprozesskommunikation
   können. Wie kann man jedoch elegant eine Interprozesskommunikation
   programmieren, die durch ein Script schon verwendbar ist?
   programmieren, die durch ein Script schon verwendbar ist?
* "C" connect: Es sollte wirklich erst zurückkehren, wenn auch die zugeteilte IP-
* "C" connect: Es sollte wirklich erst zurückführen, wenn auch die zugeteilte IP-
   Adresse stabil ermittelt ist (Bei ISDN habe ich schon 127.0.0.1 oder so gesehen).
   Adresse stabil ermittelt ist (Bei ISDN habe ich schon 127.0.0.1 oder so gesehen).
* einen hhtp-Server intgerieren der über den aktuellen Status Auskunft gibt. Ev.
* einen hhtp-Server intgerieren der über den aktuellen Status Auskunft gibt. Ev.
   auch die Konfiguration über diesen Server ermöglichen.
   auch die Konfiguration über diesen Server ermöglichen.

Version vom 12. September 2007, 15:26 Uhr

  • wget anstelle des ftp und patch der htmls aus dem routeip-project vollständig übernehmen)
  • automatisches Fail - Over auf ISDN (hab ich mir wegen der Verbindungs-Kosten
 ISDN noch nicht getraut.)
  • Es sollte eine Haltbarkeitsdauer von Fail-Over Verbindungen angebbar sein.
 Damit kann sichergestellt werden, dass keine zu hohen Kosten von Fail-Over
 Verbindungen entstehen obwohl die Hauptverbindung wieder OK ist.
  • Bei einer Neuanwahl einer Verbindung könnte eigentlich die aktuelle firewall
 geladen bleiben. Man kann auch deaktivierte (oder (noch) nicht vorhandene)
 Interfaces in einer firewall angeben.
  • Ein unnötiges rumgepinge ist eigentlich nicht notwendig. Erkennt keepcon traffic
 (in beiden Richtungen auf der Leitung) diff innerhalb der letzten z.B. 6 min
 ist ein ping zwecks "simuliertem Traffic" nicht notwendig.
  • critical "sites" sollten angebbar sein! Bei Fail -> providerwechsel, im neuen
 provider auch fail -> fallback auf den main-Provider -> PANIC
  • critical "ftp" sollten angebbar sein!
  • !!!trafic mass controll!!! via "ifconfig" mit dem entsprechenden interface.
 Also ein Datenbank Eintrag wieviel Daten über die jeweiligen Interfaces geflossen 
 sind.
  • Zwangstrennung avoid. Nach 2/3 der Verbindungszeit (und Stille)könnte ein
 freiwilliges Trennen erfolgen, sobald keepcon keinen aktuellen traffic
 inerhalb eines gewissen Zeitraumes detectiert. Dieser reconnect ist in der
 Regel weniger schmerzlich als der im vollen Last-Betrieb.
 o Kann man das NAT/MASC Modul fragen, wieviele offene Verbindungen es gibt?
  • Alive-Check-Konzept: (wget (=httpget) dazu notwendig) In eine Liste lassen
 sich http anfragen angeben, die Test-Cases starten und normiert "Erfolg"
 oder eine "Fehlermeldung" liefern.
  • Weak-Remote (hhtp-get dazu notwendig) ->wget. Nicht via ftp, sondern http:
 Es brauchen nicht unnötige Geheimnisse weitergegeben werden.
  • im ip-down (z.B. ausgelößt durch eine Zwangstrennung) ein Signal an keepcon
 schicken, damit weitere Schritte (z.B. erneute anwahl) ausgeführt werden
 können. Wie kann man jedoch elegant eine Interprozesskommunikation
 programmieren, die durch ein Script schon verwendbar ist?
  • "C" connect: Es sollte wirklich erst zurückführen, wenn auch die zugeteilte IP-
 Adresse stabil ermittelt ist (Bei ISDN habe ich schon 127.0.0.1 oder so gesehen).
  • einen hhtp-Server intgerieren der über den aktuellen Status Auskunft gibt. Ev.
 auch die Konfiguration über diesen Server ermöglichen.