Costruire un server CMS / sistema p2p senza server

1

Sto pensando di creare un CMS open source, serverless, replicato offline p2p, ma sono preoccupato che funzioni davvero in un ambiente reale. Come faresti a farlo, riducendo l'esposizione a rischi / bug?

Ho pensato a questo schema per ora.

Sul dispositivo locale abbiamo una cartella chiamata "cmsfiles" contenente i file del software e una sottocartella "database-shards", all'interno di questa sottocartella abbiamo: shard0.sqlite, shard1.sqlite, shard2.sqlite e così via .. ogni frammento ha un limite di 50 GB. All'interno di questi frammenti assegneremo le tabelle in modo casuale, essendo: commenti, post, risposte, utenti ecc.

Se un dispositivo visita un portale, ha accesso di sola lettura e per interagire deve avere un'istanza installata localmente, con lo stesso contenuto di cui sopra.

Quando installa il software, chiede un nick e una password, che verranno quindi salvati su una chiave privata per una successiva verifica. Quando un dispositivo fa un inserto (una risposta a un post in questo caso), deve anche inviare altre informazioni.

A livello locale, la richiesta viene elaborata nel modo seguente:

Al peer remoto viene richiesto il suo indirizzo IP / proxy / tor-node e l'UUID hardware. Viene quindi eseguito un controllo per determinare se il peer remoto si trova nell'elenco delle blacklist, se TRUE, tutte le operazioni / negoziazioni vengono scartate, ma se valuta FALSE, viene effettuato un controllo per verificare se è presente nel "log di tentativo di interruzione". elenca e se il numero è inferiore a 5 & & non uguale a 0, il numero è ++ incrementato, allo stesso tempo tutte le operazioni vengono scartate con il peer remoto.

Altrimenti, se il numero è uguale a 0, procediamo con un'ulteriore verifica.

Vengono recuperati il messaggio del peer remoto (risposta), la chiave privata e i file nella cartella "cmsfiles".

I file vengono ora compressi localmente su cmsfiles.lz, con hashing e confronti.

Questo hash viene quindi confrontato con quello locale e, se non sono uguali, il numero nell'elenco "registro tentativi di interruzione" viene incrementato di + + e tutte le operazioni eseguite vengono eliminate. Ma se corrispondono, procediamo a firmare la chiave privata remota con la chiave pubblica, se firma con successo, controlliamo se il post (la risposta) esiste già.

Se esiste (se TRUE), il numero nel "log del tentativo di interruzione" è ++ incrementato e qualsiasi operazione scartata, altrimenti (se FALSE) controlliamo se i voti del post sono uguali a 0 (un nuovo post non può avere più di 0 voti!), in caso contrario, il numero nella lista "log di tentativo di interruzione" è ++ incrementato e qualsiasi operazione scartata.

Altrimenti, se effettivamente è uguale a 0, possiamo finalmente aggiungere il messaggio (risposta) al database locale.

Sto includendo una rappresentazione dello schema dell'albero nel caso in cui:

    
posta gw0 16.03.2014 - 19:38
fonte

1 risposta

1

Se stai pensando a "50 GB maiuscole", cartelle e sottocartelle, eccetera, dovresti aver prima fissato l'architettura di base.

Non penso che tu ti stia avvicinando. Ad esempio, si inizia con "il peer remoto viene richiesto per il suo IP / ...". Quale peer remoto? Come lo chiedi per il suo IP se non hai ancora quell'indirizzo IP?

Allo stesso modo, "viene fatto un controllo per determinare se il peer remoto è nella lista nera". La ? In un'architettura P2P?

La maggior parte del tuo messaggio sembra riguardare questo "log dei tentativi di interruzione". Eppure non sembra avere un modo solido per prevenire lo spoofing dei pari. Posso generare nuove identità peer più velocemente di quanto tu possa inserire nella blacklist.

    
risposta data 18.03.2014 - 17:16
fonte

Leggi altre domande sui tag