Architektura implementacji

Realizowane funkcje rozdzielono pomiędzy dwa programy. Pierwszy z nich (mixclient) jest klientem względem sieci miksów i służy jako lokalny serwer pośredniczący HTTP, drugi (mixcore) realizuje wymianę wiadomości pomiędzy miksami. Szczegółowy podział zadań prezentuje tabelka 5.1.

Tabela 5.1: Podział funkcji pomiędzy programy

mixclient	mixcore
odbieranie żądań klienta HTTP; dzielenie zapytań na części odpowiedniej wielkości; wybór ścieżki i innych parametrów komunikatów; generowanie komunikatów dla miksów; odbieranie komunikatu przetworzonego przez wszystkie miksy na ścieżce; interpretacja danych z przetworzonego komunikatu i wydobycie z niego odpowiedzi; defragmentacja odpowiedzi; przekazanie odpowiedzi do klienta HTTP.	odbieranie komunikatów od innych miksów; rejestrowanie kluczy dzielonych; wykonywanie żądań HTTP zawartych w otrzymanych komunikatach; mieszanie komunikatów; przekazywanie komunikatów do odbiorców.

Zadania zostały podzielone w ten sposób, że jeśli dany miks służy jedynie do przekazywania komunikatów, czyli nie są inicjowane z niego żądania HTTP, to nie ma potrzeby uruchamiania części klienckiej. Programy te nie muszą być uruchamiane na jednym komputerze, a do jednego serwera (mixcore) można podłączyć wiele programów klienckich. To powoduje, że łatwo jest zrealizować równoważenie obciążenia pomiędzy wiele komputerów, gdyż operacje kosztowne obliczeniowo znajdują się głównie w części klienckiej (szyfrowanie kluczem publicznym RSA). Wszystkie komputery wykonujące programy danego miksu powinny znajdować się wewnątrz sieci prywatnej, gdyż ujawnienie komunikacji pomiędzy komponentami pojedynczego miksu zagraża anonimowości jego klientów. Strukturę komponentów w obrębie sieci prywatnej przedstawia rysunek 5.2.

Rysunek 5.2: Komponenty systemu w obrębie miksu