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

Nuovo commento
 
Integer:
Tutto è già stato pensato, ma mi dispiace, non è sgradevole.

Dima, lo so, certo, anch'io ho tutto inventato e fatto, sia in locale che in remoto in diverse vesti.

Ma voglio solo discutere di questo argomento piuttosto banale, che, secondo me, non è stato affatto sollevato in questo contesto.


Se avete qualcosa da dire sull'argomento, allora parlate.

 

Il cliente copia i suoi parametri e crea un ordine con un magik uguale al biglietto originale. in questo modo si aggira la doppia impostazione.

Dopo di che il client dovrebbe controllare lo stato dell'ordine e segnalare l'esecuzione (se c'è qualcosa da eseguire), o la sua vivacità se la richiesta è un controllo.

 
sergeev:

All'inizio, tutto si riduce al sistema di invio stesso. Un server, molti clienti. Se il sistema funziona, potete caricare il resto su questo scheletro.

Quando il client si connette, invia una richiesta di connessione, il server restituisce una firma in un messaggio speciale, con cui controllerà le risposte. La firma non è valida finché il client non la restituisce con un messaggio speciale. Quando tutto è in ordine è possibile iniziare a comunicare.

Quindi ha le firme di ogni cliente emesse dal server (quindi non ripetute). Il server invia messaggi con numeri di contatori (dovrebbe memorizzare i registri dei messaggi a una certa profondità nel caso in cui debba essere ripetuto), i client ricevono i messaggi numerati e inviano copie firmate al server. In questo modo il server sa quale client ha perso il messaggio e può reinviarlo. Dopo x ripetizioni il server smette di inviare questo messaggio, chiude la sessione con questo cliente e inizia ad aspettare che il cliente richieda una nuova sessione.

 
Perché prendersi tutto questo disturbo, la chiave variabile può essere messa nel messaggio stesso.
 
FAQ:

Il cliente copia i suoi parametri e crea un ordine con un magik uguale al biglietto originale. in questo modo si aggira la doppia impostazione.

Ok, schema classico.

Dopo di che il client dovrebbe controllare lo stato dell'ordine e segnalare l'esecuzione (se c'è qualcosa da eseguire), o la sua vivacità se la richiesta è un controllo.

E che senso ha fare questo? Il server non può ancora influenzare il client in alcun modo.
 
FAQ:
Perché tali complicazioni, la chiave variabile può essere messa nel messaggio stesso.
Quindi il server deve inviare le chiavi tutto il tempo? Questo aumenterà il traffico, ma che dire del traffico, dov'è la garanzia che il messaggio sarà ricevuto? e questo significa che il lato server avrà bisogno del registro delle chiavi variabili per ogni messaggio, il programmatore può confondersi con tutto questo.
 
Urain:

All'inizio, tutto si riduce al sistema di invio stesso.
È qui che la crittografia è essenziale; quando il client si connette, invia una richiesta di connessione

Ma per favore, ci dica quale tecnologia viene utilizzata per inviare e ricevere, dove il server memorizza i dati?

Penso che sia un po' difficile usare le firme. È sufficiente avere un login/password del cliente, rilasciato una volta e controllato durante le richieste.
 
sergeev:

Ok, schema classico.

Perché farlo? Il server non può comunque influenzare il client.

Perché no? Può farlo. Riavvia l'exp, il terminale, nessun problema.
 
sergeev:
Per favore, ditemi quale tecnologia viene utilizzata per inviare e ricevere i dati e dove il server li memorizza.

Non credo che sia facile con le firme. È sufficiente avere solo un login/password
Il server invia i dati al server ftp e i client li prelevano da lì.
 
Urain:
dov'è la garanzia che il messaggio sarà ricevuto?
Una domanda importante che segue la risposta è quale metodo viene usato per scambiare i dati?
123456789
Nuovo commento
Motivazione: