Copiatore di transazioni/segnali altamente affidabile (discussione di ideologia e sviluppo) - pagina 8

 

Perché arrivare a tanto? C'è un controller standard per lavorare con TCP/IP, scrivi un programma separato per questo caso. Nel terminale, l'EA comunica con il programma (all'interno di un computer, in qualsiasi modo si voglia)... e non c'è bisogno di reinventare la ruota - per ascoltare i porti, tutti hanno ascoltato per voi per molto tempo.

 
sergeev:

Questo è il punto, sto cercando di pensare in modo globale. Naturalmente, inizialmente è necessario investire di più nella scalabilità. Cioè, l'obiettivo è fare come per 1000h. E non importa che solo pochi lo useranno in seguito.

Ecco perché sto cercando di scegliere ora: o la velocità e il micro-traffico con le prese. O http e un sacco di traffico su un costante inseguimento di clienti per una nuova porzione di informazioni.

Penso che la seconda opzione sia migliore. Per coloro che hanno bisogno di scalabilità, e sono molto pochi, in ogni caso, devono sostenere costi aggiuntivi. Che paghino anche per il traffico corrispondente.

Altri nel 90% dei casi lo useranno con un piccolo numero di clienti e l'affidabilità della connessione e quindi la funzionalità in questo caso è più importante del traffico.

E nel primo caso non si può ottenere una buona soluzione senza una connessione affidabile.

 
sergeev:

Questo è il punto, sto cercando di pensare in modo globale. Naturalmente, inizialmente è necessario investire in una maggiore scalabilità. Cioè, l'obiettivo è quello di fare tanto quanto per 1000h. E non importa che solo pochi lo useranno in seguito.

Ecco perché sto cercando di scegliere ora: o la velocità e il micro-traffico con le prese. O http e un sacco di traffico su un costante inseguimento di clienti per una nuova porzione di informazioni.

E cosa succede se i clienti, che ricevono le informazioni, diventano essi stessi dei server e le distribuiscono ad un insieme di clienti. Come Skype.

ZS allora abbiamo una rete scalabile, mentre è piccola gli ordini arrivano direttamente dal server, appena la rete cresce ci sono secondo echelon, terzo. In questo caso, il carico sul server non aumenta. La rete può essere configurata dal ping tra le macchine.

 
Urain:
E se i clienti che ottengono le informazioni diventassero essi stessi dei server e le distribuissero a un certo insieme di clienti. Come in Skype.

Ho appena visto il telegiornale)https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA

Con il peer-to-peer sarebbe una soluzione "rivoluzionaria", ineguagliabile)

Ma c'è da chiedersi se è realistico e se vale la pena di farlo.

 
OnGoing:

Ho appena visto il telegiornale)https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA

Con il peer-to-peer sarebbe una soluzione "rivoluzionaria", ineguagliabile)

C'è solo da chiedersi se è realistico, e se vale la pena di farlo.

Ecco perché ho chiesto le dimensioni della rete. Afferrare l'immensità è come afferrare l'indescrivibile :)
 
Urain:

E se i clienti che ricevono le informazioni diventano essi stessi dei server e le distribuiscono a un certo insieme di clienti. Come in Skype.

L'opzione è buona, ma troppo grande :) Penso che per la sincronizzazione dei client con il master, fare uno scambio supplementare tra i client stessi sia ridondante.
Anche se, naturalmente, ogni client diventerà un mini-server per inviare le informazioni ricevute, e questo, in linea di principio, vale la pena pensarci.

 
Integer:

Perché arrivare a tanto? C'è un controller standard per lavorare con TCP/IP, scrivi un programma separato per questo caso. Nel terminale, l'EA comunica con il programma (all'interno di un computer, in qualsiasi modo si voglia)... e non c'è bisogno di reinventare la ruota - per ascoltare i porti, tutti hanno ascoltato per voi per molto tempo.

Dmitry, ripeto. I replicatori sono disponibili da molto tempo, da circa 4-5 anni. e locale e remoto, e con server intermedi. Non ho bisogno di controllori che ascoltino per me.

Qui voglio fare una discussione a livello di forum tra persone che hanno imparato molto al riguardo. E sulla base dei pro e dei contro delle tecnologie per fare varianti di copiatrici affidabili, che sono stabili e resistenti al numero di clienti così come alla qualità della connessione e al carico sui canali.
 
sergeev:

..

E sulla base dei vantaggi e degli svantaggi delle tecnologie per fare fotocopiatrici affidabili che siano stabili e robuste sia in termini di numero di clienti che di qualità della connessione e del carico sui canali.

Quelli all'ordine del giorno sono due rischi.

1 non riceve il segnale a causa di problemi di comunicazione

2 non ricevere il messaggio giusto a causa delle perdite di bit nella trasmissione.

Poi, senza comunicazione tra clienti vicini, ricevendo tre segnali da fonti diverse, si può fare una riconciliazione bit-wise e ottenere il vero messaggio sul principio del "2 di 3 è vero". Un tale schema è più sicuro sia contro i guasti di comunicazione che contro le perdite di trasmissione. I messaggi possono quindi essere criptati in maschere di bit e compressi al minimo (invece di trasmettere frasi di stringhe). Il che ridurrà il traffico del server.

E al fine di evitare il fallimento a causa di un vicino fallito, formare un invio ridondante, per esempio, il client riceve un segnale dal server e 4 vicini, ma il segnale del server e 2 segnali dai vicini che sono venuti prima sono presi in considerazione.

 
Urain:

Quelli all'ordine del giorno sono due rischi.

1 non riceve il segnale a causa di errori di comunicazione

La mancanza di comunicazione al client non può essere risolta. O è presente o è assente. Si suppone che il server abbia comunicazione in ogni momento.

2 non ricevere il messaggio corretto a causa di bit persi nella trasmissione.

Un messaggio non valido può essere firmato ad esempio con un hash. Se l'hash è sbagliato, il messaggio viene riprovato dal server. Ma di solito uno speciale tag @label@ alla fine e nel mezzo di un file rende chiaro che il messaggio è completo.

 
Urain:

...allora la comunicazione tra client vicini è essenziale, avendo ricevuto tre segnali da fonti diverse è possibile fare una collazione bit-wise e produrre un messaggio vero su una base "2 su 3 corretta". Tale schema è più sicuro sia contro gli errori di comunicazione che contro le perdite di trasmissione. I messaggi possono quindi essere criptati in maschere di bit e compressi al minimo (invece di trasmettere frasi di stringhe). Il che ridurrà il traffico del server.

La verifica della verità dei dati trasmessi è già implementata nel TCP/IP a livello di protocollo.
Motivazione: