Copiatore di transazioni/segnali altamente affidabile (discussione di ideologia e sviluppo) - pagina 6
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
uno schema di scambio semplice: il generatore di segnali mette un file sul server con tutti i suoi ordini e posizioni aperte, come nel terminale. Se almeno un ordine o una posizione sono cambiati, piazza un nuovo file. In questo caso, il server invia una nuova versione del file (o un messaggio con il contenuto completo del file), e il client risponde di averlo ricevuto (il server dovrebbe contenere la lista dei client connessi). Il server invia anche il file al client in qualsiasi momento.
Se il client è bloccato o perde un ordine, può facilmente ripristinarsi leggendo il file terminale del server. Se c'è uno scambio comando per comando, ci possono essere molti crash e ambiguità. Il client può risincronizzarsi per la diagnostica, ad esempio una volta per Xmin se non ci sono stati cambiamenti.
Il traffico non è elevato con questo schema. Quindi puoi usare anche SSL o https.
Ci sono 3 tipi di messaggi: dare, ricevere, file stesso.
uno schema di scambio semplice: il generatore di segnali mette un file sul server con tutti i suoi ordini e posizioni aperte, come nel terminale. Se almeno un ordine o una posizione sono cambiati, piazza un nuovo file. In questo caso, il server invierà una nuova versione del file (o un messaggio con il contenuto completo di questo file). Invia anche questo file in qualsiasi momento su richiesta del cliente.
Se il client è bloccato o perde un ordine, può facilmente ripristinarsi leggendo il file terminale del server. Se c'è uno scambio comando per comando, ci possono essere molti crash e ambiguità. Il client può risincronizzarsi per la diagnostica, ad esempio una volta per Xmin se non ci sono stati cambiamenti.
Il traffico non è elevato con questo schema. Pertanto, è possibile utilizzare anche SSL o https.
Lo schema è inutile, perché il file con il segnale di trading perde la sua rilevanza molto rapidamente, perché le operazioni devono essere eseguite in tempo. L'opzione più veloce è che il cliente mantenga una connessione costante al socket del server e aspetti che appaiano i segnali di trading. Una connessione permanente non spreca traffico a differenza delle richieste sistematiche e la sua affidabilità è abbastanza alta.
Come ho detto prima, non sono necessari nemmeno i comandi. Non appena appare un segnale di trading, il server lo invia ai client come una singola linea con il simbolo di terminazione "\n" e aspetta il prossimo. Il client non deve inviare nulla al server, riceve solo segnali.
SSL e https non sono affatto necessari. In primo luogo, il proprietario del server dovrà registrare un dominio e comprare un certificato e poi dovrà prolungare tutte queste cose anche non gratuitamente per poter lavorare con questi protocolli. E in secondo luogo, questi protocolli sono per la crittografia dei dati, per intercettare le informazioni in un flusso TCP non poteva decifrare. Il carico sul server sarà enorme se ha molti clienti, perché la crittografia non è halam balam, ma l'operazione di elevare grandi numeri interi a potenze superiori modulo.
Lo schema è inutile, perché il file del segnale di trading perde rapidamente la sua rilevanza, dato che i trade devono essere fatti in tempo. L'opzione più veloce è che il cliente mantenga una connessione costante al socket del server e aspetti che i segnali di trading appaiano. Una connessione permanente non spreca traffico, a differenza delle richieste sistematiche, e la sua affidabilità è abbastanza alta.
Come ho detto prima, anche il cliente non ha bisogno di comandi. Quando appare un segnale di trading, il server lo invia al client come una singola linea e aspetta il prossimo. Il client non deve inviare nulla al server, ma solo ricevere segnali.
Non c'è ritardo, perché viene inviato a tutti i clienti immediatamente dopo la comparsa del segnale.
La connessione comando per comando fa certamente risparmiare traffico, ma l'affidabilità sarà scarsa. Il cliente dovrebbe essere in grado di ottenere tutti gli ordini (per esempio, gli ordini pendenti o le modifiche degli ordini) anche quelli che ha perso per qualche motivo.
Non c'è alcun ritardo perché il messaggio viene inviato immediatamente a tutti i client dopo la comparsa del segnale.
Squadra per squadra, ovviamente, risparmia il traffico, ma l'affidabilità sarà scarsa. Il cliente dovrebbe essere in grado di recuperare tutti gli ordini (ordini pendenti per esempio, o modifiche di ordini), anche quelli mancanti per qualche motivo.
Ok, fai una gobba. Solo chi farà tali sciocchezze - non è un mio problema.
Il mio lavoro è quello di offrire la migliore opzione con il minimo carico e traffico, avete il diritto di rifiutare.
SSL e https non sono affatto necessari. In primo luogo, il proprietario del server deve registrare un dominio e comprare un certificato, e poi rinnovarlo permanentemente non è anche gratis, per lavorare con tali protocolli. E in secondo luogo, questi protocolli per la crittografia dei dati, per intercettare le informazioni in un flusso TCP non potevano decifrarlo. Il carico sul server sarà enorme se ha molti clienti, perché la crittografia non è halam balam, ma l'operazione di elevare grandi numeri interi a potenze superiori modulo.
Ma tutti i server-segnali non autenticati esistenti vengono craccati in un paio d'ore. Anche se la crittografia può essere inutile))
ma tutti i server-segnali esistenti senza autenticazione possono essere craccati in un paio d'ore. La crittografia può essere però inutile)).
1. Non ore, ma millisecondi
2) Chi diavolo ha bisogno che i suoi segnali siano aperti da qualcun altro? Aneddoto su Elusive Joe.
Va bene, fai una gobba. Ma chi farà queste sciocchezze non è più un mio problema.
Il mio lavoro è quello di offrire la migliore opzione con il minimo carico e traffico, avete il diritto di rifiutare.
1. Non ore, millisecondi.
2) Chi cazzo ha bisogno che i suoi segnali siano coperti? Aneddoto su Elusive Joe.
Non me ne frega niente, ma la gente che vende segnali per soldi si arrabbia)) Ma se non è importante in questo progetto - nessun problema, nessuna necessità di protezione
Se il client ha perso la connessione, o si è riavviato, e nel frattempo sono passati alcuni ordini pendenti o modifiche di ordini, come risolvere il problema con lo scambio di comandi telnet? Non lo so, forse puoi - è per questo che te lo chiedo.
Ti ho già detto che non c'è bisogno di un comando telnet, ma stai di nuovo dicendo sciocchezze.
Dovresti duplicare i file e caricarli su qualche hosting economico usando SendFTP(). E lasciare che il cliente legga i file via FTP con il tempo di creazione quando era fuori contatto.
Ti ho già detto che non c'è bisogno di un comando telnet, ma stai di nuovo dicendo sciocchezze.
Dovresti duplicare i file e caricarli su qualche hosting economico usando SendFTP(). E lasciare che il cliente legga i file via FTP con il tempo di creazione che era fuori dalla connessione.
Cioè non è tuo))
Reshetov:
Socket su protocollo TCP/IP. È possibile trasmettere segnali in forma di testo in una riga per segnale, come "EURUSD Buy 1.0\n", come via Telnet, perché è la versione più primitiva che non richiede una procedura di scambio complessa, come nei protocolli http o ftp con parsing minimo.
Stai parlando di nuovo senza senso - duplicare uno con l'altro quando si può fare con uno)). Perché preoccuparsi di memorizzare file, quando uno è sufficiente - l'ultimo con lo stato attuale di tutti gli ordini e le posizioni? Per combinare lo scambio su richiesta del server (quando qualcosa è cambiato sull'account principale) e su richiesta del cliente (quando ha avuto problemi o incongruenze), e non per venire con stampelle aggiuntive. Potete inviare non l'intero file d'ordine su richiesta del server, ma solo ciò che è cambiato e sarà la vostra versione di "scambio di comandi".