Copiatore di transazioni/segnali altamente affidabile (discussione di ideologia e sviluppo) - pagina 7
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
OK. Allora propongo di prendere la connessione socket come modello di lavoro.
Схема работы синхронизатора:
- Il server creerà connessioni socket permanenti con i client (la questione di assegnare ad ogni client il proprio thread è ancora in fase di studio).
- il master-cliente invia lo stato attuale dei suoi ordini durante un evento commerciale
- il server salva questo file e lo invia a tutti gli altri client immediatamente (una connessione socket è già stabilita)
- il client riceve il file e cambia lo stato dell'ordine in base ai dati ricevuti
- L'ultimo file salvato della procedura guidata viene anche inviato al client quando un nuovo client si connette. (per la sincronizzazione iniziale)
Il vantaggio principale di questo sistema è il risparmio di traffico:
- Non richiede richieste costanti da parte del cliente. Li riceverà dal server sulla loro disponibilità
- Allo stesso modo, il master-client invierà dati solo quando vengono rilevati cambiamenti
Protezione in caso di perdita di connessione
- il client invia un pacchetto "Heartbeat" (ad esempio 2 byte) ogni 5 secondi per controllare la comunicazione con il server
- Il client reinizializza la connessione se il pacchetto viene inviato senza successo (nessuna risposta).
- il server fa lo stesso. Se nessuna risposta viene ricevuta dal client entro 10 secondi, la connessione socket viene chiusa.
C'è uno svantaggio di questa connessione?
- ad esempio, qual è il numero massimo possibile di connessioni socket disponibili?
Protezione in caso di perdita di connessione
- Il client invia un pacchetto "Heartbeat" (ad esempio 2 byte) ogni 5 secondi per controllare la comunicazione con il server
Questo non viene mai fatto quando si comunica tramite il protocollo di trasporto TCP/IP, perché la comunicazione viene mantenuta automaticamente al livello socket, cioè dal sistema operativo. In caso di connessioni interrotte, viene lanciata un'eccezione sul client e il suo gestore deve specificare cosa esattamente deve essere fatto in questo caso. Per quanto riguarda il server, non gliene frega niente, perché se il client è disconnesso, è un problema del client.
- ad esempio, qual è il numero massimo possibile di connessioni socket disponibili?
Se le connessioni sono interrotte e viene sollevata un'eccezione sul client, deve essere sollevata un'eccezione nel suo gestore
Di quale eccezione parla?
Sto parlando della WS2_32.dll. Solite prese Berkeley (anche se nella variante asincrona). Non ho visto alcuna eccezione. Si può rilevare un crash solo provando a inviare/ricevere.
quante connessioni socket possono essere fatte su questa porta?
Di quale eccezione parla?
Beh, avete bisogno di una sola porta.Sto parlando della WS2_32.dll. Normali sockets Berkeley (anche se in versione asincrona). Non ho visto alcuna eccezione. Si può rilevare un crash solo provando a inviare/ricevere.
Mi interessa sapere quante connessioni socket possono essere collegate a questa porta ?
C'è solo una connessione per porta. Affinché il client possa connettersi, deve sapere quale IP e numero di porta sono allocati sul server. In alternativa, potete specificare un nome di dominio invece di IP e il socket lo risolverà in un indirizzo IP tramite DNS.
Il socket del server ascolta proprio questo numero di porta per connettersi dai clienti. Quando il client si connette, il socket alloca un'altra porta dal pool di porte libere per mantenere la connessione. La porta persistente viene poi rilasciata di nuovo e resta in ascolto per le connessioni di altri clienti.
Questo è il modo in cui sono fatte le connessioni del protocollo di trasporto TCP/IP. Tutto questo viene fatto a livello di socket, cioè non c'è bisogno di programmare il protocollo - è standard ed è già cablato nella libreria condivisa nel sistema operativo.
Quando un client si connette, il socket alloca un'altra porta dal pool di porte libere al client per tenerlo permanentemente connesso.
Yuri, grazie per le basi, ma è fuori luogo. Stai dando la conoscenza sbagliata.
E quella assegnata non ha affatto senso, scusate. Forse state applicando i concetti di porto in due ipostasi diverse, ma allora è meglio che lavoriate in concetti accettati.
qualcosa potrebbe tornare utile per lo sviluppo
improbabile. poco professionale.
E quella evidenziata è una sciocchezza, mi dispiace. Forse stai applicando i concetti di porto in due forme diverse, ma allora è meglio che lavori in concetti accettati.
Come si dice, è un vostro problema come applicate il concetto di porto. Ho solo spiegato come vengono usate le porte nel protocollo TCP/IP. Ancora una volta, il protocollo è standard, cioè non l'ho inventato io.
Non sono io che l'ho inventato.
Buona fortuna!
Qual è l'ordine di grandezza della rete, quanti clienti dovrebbero essere 1000-mila, 100-mila, 10-mila, 1-mila?
Perché il tuo server andrà davvero in bancarotta con migliaia di clienti.
Qual è l'ordine di grandezza della rete, quanti clienti dovrebbero essere 1000-mila, 100-mila, 10-mila, 1-mila?
Perché il tuo server andrà davvero in bancarotta con migliaia di clienti.
Questo è il punto, sto cercando di pensare in modo globale. Naturalmente, bisogna mettere molta scalabilità all'inizio. Cioè, l'obiettivo è quello di fare tanto quanto per 1.000h. E non importa se solo poche persone lo useranno in seguito.
Ecco perché ora sto cercando di scegliere e decidere: o velocità e micro-traffico con le prese. O http e un sacco di traffico su un costante inseguimento di clienti per una nuova porzione di informazioni.