Projekt abcc składa się z demona, napisanego w Pythonie, który czyta plik konfiguracyjny, a następnie na podstawie jego zawartości dokonuje cyklicznej kontroli jakości dostępnych łącz względem określonych w konfiguracji IP docelowych. Przeprowadzane operacje zapisywane są do logu (syslog?), podobnie jak oceny poszczególnych łącz.
Zakładam wykorzystanie Pythona w wersji 3, przestrzeganie PEP8 i programowanie funkcyjne. Całość ma być możliwie prosta koncepcyjnie i możliwie konfigurowalna przy pomocy pliku konfiguracyjnego za pomocą wag poszczególnych wskaźników, wag IP. Rozwiązanie ma też zapewniać użytkownikowi pełną przejrzystość działania, wybór poziomu logowania i możliwość uruchomienia w wersji „na sucho”, w celu przetestowania, jak uruchomienie z daną konfiguracją wpłynęłoby na zmiany routingu.
Aby to osiągnąć, zmienia na czas pomiaru routing do docelowych IP na dane łącze, dokonuje pomiaru jakości łącza, a następnie, po zebraniu danych dla wszystkich łącz, określa, które z nich jest najlepsze i – jeśli zachodzi taka potrzeba, dokonuje zmiany routingu.
Do zmiany routingu wykorzystywane są zewnętrzne skrypty bashowe – pozwala to na dostosowanie działania demona do różnych platform i potrzeb – np. dodanie zmiany NATowanaia, wywołanie zmian na zdalnym systemie (router sprzętowy) – bez zmian w samym silniku.
Teoretycznie można by to napisać w czystym Bashu i wywoływać z crona, ale po pierwsze, chcę potrenować Pythona, po drugie tak będzie łatwiej, bardziej elegancko i będzie otwarta droga np. do zwiększenia częstotliwości próbkowania przez zrównoleglenie pomiarów.
Z racji wymogów konkursowych dotyczących ilości postów, tworzenie projektu będzie trochę przegadane, i spowolnione, przynajmniej na początku. Zaleta jest taka, że będzie lepiej widać sposób rozumowania, gdyby ktoś chciał coś skomentować lub się przyłączyć. Commity kodu i dokumentacji będą się pojawiały w miarę równolegle z wpisami na blogu, pierwszy właśnie poszedł.
Zmiana routingu spowoduje zerwanie wszystkich połączeń, taka zmiana ma sens tylko wtedy kiedy default gw uległ awarii
@rob Mam świadomość konsekwencji, ale rację masz tylko częściowo: w przypadku, gdy będzie użyte na pojedynczym komputerze, bieżące połączenia zostaną faktycznie zerwane. I zdecydowanie planuję unikać częstego przełączania, za sprawą definiowanego przez użytkownika kosztu przełączania.
Natomiast nie zgadzam się, że przełączenie ma sens tylko w przypadku awarii default gw – zależy od zastosowania, ale wyobrażam sobie sytuacje, gdy warto przełączyć łącze znacznie wcześniej, np. przy istotnych stratach pakietów czy dużej różnicy prędkości. Bardzo wiele zależy tu od wykorzystywanych aplikacji/serwisów.
W przypadku wersji operatorskiej problem zupełnie nie występuje – nie zmienia się w ogóle źródłowe IP, jedynie trasa. Tak czy inaczej, decyzję pozostawiam użytkownikowi.
w wersji operatorskiej za zmianę trasy odpowiedzialne są protokoły routingu dynamicznego. Tak czy inaczej, fajny pomysł żeby sobie coś popisać.
@rob To prawda, ale… nie w tym rzecz. Technicznie dało by się mieć łącza operatorskie bez dynamicznego routingu, choć w takie rzeczy raczej mało kto się bawi. Kluczem do zerwania sesji jest zmiana IP, która towarzyszy przepięciu łącza w wariancie konsumenckim. Ale jak pisałem – zależy od zastosowania. Jeśli ktoś przegląda strony WWW lub ściąga pocztę lub wykorzystywany program nie zwraca uwagi na zmianę IP – będzie działać OK.
Nawiasem, protokoły operatorskie nie zapewniają sprawdzania opóźnień i strat.