3 replies to this topic

[skynetman]

Ragazzi ciao, sono sempre lo stesso sky dell'alpha team di keyforum
Vedo che la sincronizzazione dei messaggi sembra avvenire ancora random, non mi sembra sia stato implementato un modo per rendere sicuro il completamente del sync dopo x ore.
In pratica un db potrebbe non convergere mai alla sua versione completa e nessuno sa mai se il suo db è allineato almeno per i giorni passati.

Ripropongo perciò di fare un controllo esaustivo ma molto veloce ad ogni collegamento che io chiamo hash di hash (suppongo che non sia cambiato molto nei meccanismi di osiris rispetto ai vecchi).

Ognuno ha una tabella che chiamo HashCheck che contiene l'hash di tutti gli hash per ogni mese completo e per ogni giorno del mese in corso.
All'avvio e solamente all'avvio ogni client per ogni mese completo e per ogni giorno del mese ancora da terminare fa un hash di tutti gli hash dei messaggi in suo possesso e li SPEDISCE ai nodi a cui si collega (esattamente come L'AICH di emule manda il codice di controllo dell'albero degli hash).
Al massimo sono (M+n) hash, dove M numero mesi da cui è aperta la board ed n=[1...31] numero di giorni del mese in corso.
A questo punto i nodi che ricevono la richiesta possono ignorarla (se ad esempio lo stess ip ripete la domanda in meno di 1 ora) oppure fare un controllo con la tabella contenente i medesimi valori che loro stessi possono aggiornare una volta ogni 6 ore (4 volte al giorno).
Notare che già in ricezione dei messaggi si può segnare un FLAG nella tabella di questi hash dicendo quali devono essere ricalcolati alla scadenza delle prossime 6 ore, quindi si può evitare di ricalcolare blocchi di hash vecchi inutilmente. Non è necessario leggere tale flag, basta settarlo direttamente ogni volta che si riceve un messaggio.
Il principio è che i mesi già completati non richiederanno con molta probabilità nessun aggiornamento, quindi traffico zero.
Qualora ci sia una discordanza sull'hash, il client che si è appena collegato può chiedere gli hash di tutti i giorni del mese dove si verifica l'errore (o gli hash di tutti i giorni se è il mese corrente, come accadrà più spesso) ed individuare dove si trovano le differenze.
In questo modo può fare richieste più mirate completando l'archivio nel minor tempo possibile. Notare inoltre che se uno fa pasticci con il suo database esso viene automaticamente corretto ad ogni nuovo avvio del client e non si verifica il problema che il messaggio viene spedito ma rifiutato dagli altri perchè l'hash non è valido.

Questa sceltà ha dei vantaggi:
1) E' chi ne ha bisogno che fa richiesta dei blocchi di hash, che possono essere ignorati dagli altri per non sovraccaricare il sistema.
2) Lo spreco di banda è minimo, l'informazione viene spedita con un solo hash per giorno o per mese
3) Tutti i database sono costantemente aggiornati.
4) Il consumo di CPU è praticamente nullo per i nodi che sono sempre accesi (4 volte al giorno il ricalcolo), mentre è maggiore per chi si collega (come deve essere per evitare che ci rimettano i più "bravi").

P.S.: se esistesse una sezione sviluppo sarei ben felice di rientrarvi...

[skynetman]

nessuna particella di sodio in giro eh?

[Clodo]

Ciao, benvenuto!
E' che sono un pò incasinato in questi giorni, e volevo consultarmi con l'altro sviluppatore, Berserker.

In linea di massima, a una cosa del genere ci avevamo pensato... il problema è che "cozza" con l'idea del motore di sopravvivenza, in cui uno può sottoscriversi ad un portale e:
- tenere solo delle sezioni di suo interesse
- avere un punto di vista diverso da altri (cioè, un utente scurrile normalmente non visibile da molti utenti, lui ha deliberatamente scelto di vederlo)
- altre cose che ora non mi vengono in mente.

Il punto è che siamo indietro con molti sviluppi, e ora come ora abbiamo le seguenti priorità (in linee generali)
- bugfix vari
- Osiris deve reggere con portali notevoli, nell'ordine di DDU (si parla di gestirlo in tempi ragionevoli di calcolo statistiche & navigazione, non del tempo necessario per scaricarlo)
- Controllo spam/attacchi, tra cui le implementazioni per limitare la registrazione automatica di utenti di spam (n.b. il motivo per cui Daniele ha abbandonato KF).

Fixate queste cose, penseremo a quell'aspetto: è sì "frustrante" allinearsi da zero, ma non è comunque un problema "catartico" come gli altri che ancora dobbiamo affrontare.

Si parlava tempo fa, come compromesso, di far sì che da un portale allineato si possa esportare in un file ".osiris", in modo da condividerlo via torrent/emule, e avere una base di partenza già allineata e scaricata "a palla" in fase di registrazione al portale...

Ci rifletto un pò insieme a Berserker sulle tue osservazioni, e ti sentiamo più avanti.

Ri-benvenuto!

[skynetman]

Non so se alla fine stiamo dicendo la stessa cosa ma credo che un sistema come Osiris debba per forza prevedere sempre delle copie identiche del DB presso ogni utente.
Localmente può anche scegliere di non vederlo, ma i messaggi nel suo db ci devono essere.
La mia idea si basa sul fatto che la sincronizzazione di data e ora viene già effettuata (se è come il vecchio KF), quindi sincronizzare per giorni e mesi è un modo conveniente.
Questo tipo di sync avverrebbe solo al primo contatto con un nuovo nodo, e porterebbe ad un allineamento velocissimo, con la possibilità di creare una lista di hash mancanti e di suddividere le richieste a più nodi diversi.
Credo anche che sia conveniente ordinare gli hash in maniera crescente all'interno delle varie risposte da spedire, creare dei pacchetti di dati di svariati KB, zippare i pacchetti e frammentarli sul socket come fa emule.


Lieto di conoscerti Clodo!!