Rifiuti del broker ed errori di connessione: accertato contro possibile
Quando un broker rifiuta un login o una sottoscrizione, Senzoukria mostra un avviso costruito dal messaggio grezzo: un titolo su una riga, ciò che è accertato (quando lo è qualcosa), la conseguenza e il rimedio, le cause possibili per frequenza e la formulazione esatta del broker conservata per l'assistenza. Una causa viene affermata solo quando è il server a dichiararla.
Senzoukria · Documentazione · Aggiornato a settembre 2026
Dove trovarlo
- Dove
- Banner sul grafico footprint e sulla heatmap quando una sottoscrizione o un login falliscono; le schede di connessione mostrano lo stato di ogni capacità
- Tipi
- alreadySubscribed, historyBusy, subscribeRefused, loginRefused, unknown
- Codice del broker
- Mostrato accanto al testo come «Codice broker {code}» — «Utile al tuo broker. Da solo non indica alcuna causa.» Il codice 0 non viene mai mostrato
- Messaggio grezzo
- Conservato parola per parola, richiuso sotto «La formulazione esatta del broker», con un pulsante «Copia il messaggio esatto»
Che cosa fa
Il lettore dei rifiuti prende la stringa grezza dell'errore e il contratto corrente, estrae il primo rp_code che trova e sceglie una fra cinque forme. La gerarchia della schermata è la gerarchia della fiducia: titolo, poi ciò che è accertato (visivamente distinto perché è l'unica cosa che il lettore può dare per scontata), poi corpo, conseguenza e rimedio, poi le cause possibili precedute dall'ammissione che nessuna è accertata, e infine la formulazione del broker richiusa in fondo. Un solo rifiuto porta con sé una riga di certezza: il server stesso che dichiara che la sottoscrizione esiste già.
Un pulsante «Riprova» compare quando l'host fornisce un'azione di ritentativo; l'avviso resta su un grafico vuoto per impostazione predefinita, perché nasconderlo non riempirebbe il grafico.
Tipi di rifiuto
| Tipo | Riconosciuto da | Titolo e righe chiave |
|---|---|---|
| Già sottoscritto | rp_code 1029 oppure «update bit type already exists» | «{symbol} è già sottoscritto su questo login» — certo: il server dichiara che la sottoscrizione esiste. Rimedio: chiudi le altre finestre di Senzoukria, comprese quelle nell'area di notifica, poi le altre piattaforme sullo stesso login; una sottoscrizione trattenuta si libera pochi minuti dopo la chiusura dell'applicazione che la tratteneva |
| Storico occupato | «history load is already running / in progress» (la nostra stessa protezione in corso, senza codice) | «Un caricamento dello storico è già in corso per {symbol}» — il grafico riprova da solo; se non si sblocca mai, ⚙ → Impostazioni di trading → Ricarica storico |
| Sottoscrizione rifiutata | La parola «subscri» nel messaggio | «Il broker ha rifiutato la sottoscrizione a {symbol}» — misurato: il login è passato, la sottoscrizione è stata rifiutata. Cause: altra istanza, contratto scaduto, formato del simbolo ({symbol}.{exchange}), mercato chiuso, autorizzazione |
| Login rifiutato | «login» oppure «authentication» | «Il broker ha rifiutato il login» — misurato: il gateway ha risposto, il login è tornato rifiutato; formulazione invariata |
| Sconosciuto | Tutto il resto | «Questo rifiuto non è mai stato visto qui prima» — il messaggio è mostrato invariato e non vi si legge nulla dentro |
Stato delle capacità sulle schede di connessione
Ogni connessione espone cinque capacità — Dati di mercato, Profondità (L2), Storico, Flusso del conto, Ordini — e ognuna porta uno stato: inattivo, in connessione, pronto, riconnessione, errore o non supportato, con una stringa di dettaglio e un timestamp. Lo stato complessivo della scheda ne consegue: Connesso, Connessione…, Riconnessione…, Errore oppure Offline. Le sottoscrizioni sono elencate con il loro flag di profondità, perché «il DOM non si muove» è prima di tutto una questione di sapere se l'L2 sia mai stato richiesto.
Gli ambienti sono Test, Paper, Eval, Finanziato e Live. Su un conto Finanziato l'instradamento degli ordini resta disattivato finché non abiliti a mano l'interruttore Trading della connessione.
Limiti e trappole
- La causa legata all'autorizzazione viene rimossa ogni volta che il codice è 13. Su quel codice «diritti insufficienti» è la lettura che si è rivelata sbagliata quattro volte nel registro dei bug; l'avviso rifiuta di proporla anche solo come possibilità.
- «Rifiuti formulati in modo identico hanno avuto cause diverse qui.» L'avviso non trasforma mai un rifiuto in un verdetto; la frase da inviare è «Chiedi al tuo broker, con queste parole: il mio login è abilitato ai dati {exchange}, sotto quale nome di sistema, e quante sessioni simultanee può aprire?»
- Un demo Rithmic gratuito non può connettersi: «Rithmic non offre l'API R | Protocol agli account demo, qualunque siano il nome del sistema o il gateway.» Quel rifiuto è un confine del prodotto, non un errore da ritentare.
- Una sottoscrizione accettata e poi muta non è affatto un errore a schermo; per quel caso lo strumento è la diagnostica di connessione.
Pagine correlate
- Diagnostica di connessione (preflight)
- Guida alla connessione passo passo
- Bridge NinjaTrader
- Software footprint Rithmic
Questa pagina in altre lingue
Domande frequenti
- Il badge dice CONNECTED ma il grafico è vuoto. La connessione è rotta?
- Non necessariamente. Con un rifiuto di tipo «già sottoscritto» la connessione funziona e il flusso è trattenuto altrove — quasi sempre una seconda finestra di Senzoukria o un'altra piattaforma collegata con lo stesso login.
- Che cosa devo mandare all'assistenza del mio broker?
- La formulazione esatta e il codice del broker, copiati con «Copia il messaggio esatto». Aggiungi la copia della diagnostica di connessione se l'hai eseguita; nessuna delle due contiene la tua password.