è esattamente quello che sembra

[GabrieleDellepere]

questa versione utilizza un modello di apprendimento non supervisionato per clusterizzare le connessioni che portano a un flag-out. La classe SmartTCPHandler estende il metodo process (quindi se si vuole aggiungere un filtraggio manduale l'unica adesso è overridare il metodo "standard_processing") di TCPHandler, in cui aggiunge automaticamente a un field history tutti i pacchetti in ingresso e interroga "the judge" per sapere se inoltrare i flag-out in uscita o uccidere la connessione.
Ho cercato di renderla quanto più retrocompatibile possibile (quindi se ad esempio l'handler passato alla proxy non ha un judge si dovrebbe comportare esattamente come una proxy normale), ma non l'ho testata esaustivamente su questo aspetto.
Il Giudice si aggiorna ogni 40ina di secondi, interrogando un backend, per sapere quali centroidi utilizzare per il clustering e quali cluster bloccare.
Il backend è in una cartella a parte, è un programma da lanciare localmente che utilizza i dati che gli arrivano da LeProxy per aggiornare i cluster con K-means++ (e manda i dati su centroidi e cluster bloccati indietro a LeProxy). In particolare, il backend crea due file per servizio (uno contenente le connessioni in plaintext da usare come esempi e uno contenente le connessioni già trasformate in punti per il modello), che aggiorna con i dati che ottiene nel modo sopra citato. Ogni 45 secondi lancia un update di ogni modello utilizzando i punti contenuti nel secondo file corrispondente, prendendo al massimo i 2500 più recenti.
La scelta di utilizzare i file è dovuta principalmente all'avere la possibilità di interrompere e rilanciare il backend senza perdere informazioni, ma forse ci sono soluzioni migliori.
Per ora è tutto quello che mi viene in mente, nel caso mi fossi scordato qualcosa te lo faccio sapere.