[Logo] Spazio Aperto Banca Sella
[Register] Registrati   [Login] Login    
[Search] Ricerca   [Recent Topics] Argomenti Recenti   [Hottest Topics] Argomenti vivaci  
[Banner Pubblicitario]
Messaggi inviati da: giulio.rattone
Indice dei Forum » Profilo per giulio.rattone » Messaggi inviati da giulio.rattone
Autore Messaggio
Entrambi i problemi che lei evdienzia dovrbebero essere collegati al fatto che l'inforamtiva dello strumento che ha scelto è in delay di 15 minuti.
Quindi correttamente si ferma a 15 minuti prima e non supporta il push (noi non aggiorniamo l'informativa in push se il real time non è abiltiato)

Può contattare il nostro servizio clienti al fine di farsi abilitare il mercato in oggetto in realtime.

Provi a vedere quali sono i costi dell'informativa real time mercato per mercato qui:
https://www.sella.it/ita/trader/strumenti-mercati/mercati-azionari.jsp
https://www.sella.it/ita/trader/strumenti-mercati/mercati-derivati.jsp
https://www.sella.it/ita/trader/strumenti-mercati/mercati-obbligazionari.jsp
https://www.sella.it/ita/trader/strumenti-mercati/mercati-cfd-forex.jsp


Ciao crogerc,

considerato che la maggior parte degli strumenti del mercato italiano adesso hanno l'asta di volatilità e non più la vera e propria sospensione ti suggerirei di fare una formattazione condizionale (SellaExtreme5 fra le novità introdotte ha questa funzione) basata sul valore della colonna "fase". In modo da evidenziare le righe come vuoi quando la fase è, a titolo di esempio "Reopening Auction Call".

Cosa ne pensi?
LsKoder wrote:Ciao Diego,

grazie per la risposta.
Ho citato la modalità di connessione perchè essendo il VirtualMode una modalità che non permette operazioni di trading, speravo che si potesse evitare di usare il token (a che scopo tanta sicurezza in una modalità "in sola lettura" su dati pubblici?)

Inoltre, non mi è chiaro come possa un'unica connessione avere le stesse prestazioni di connessioni multiple. Per aggiornare 1000 strumenti, voi richiedete 1000 richieste (con un overhead spaventoso e ingiustificato, specialmente se l'aggiornamento deve essere fatto su pochi giorni).
Mi confermi quindi che l'oggetto XRemoting.Session supporta l'uso condiviso da parte del multithreading? Ti chiedo conferma perchè dai test effettuati non ho riscontrato i benefici che mi aspettavo (un leggero miglioramento del 10% usando il multithreading, mi aspettavo qualcosa di più)..

Grazie,
Sergio


Ciao LsKoder,
Anche in modalità VirtualMode siamo tenuti ad identificare l'utente utilizzatore in modo preciso perchè i flussi informativi in realtà non sono pubblici. Essi sono di proprietà dei mercati che le erogano e sono sottoposti a fees. Siamo quindi obbligati a "contare" i singoli utlizzatori nel modo più preciso e consono in ben controllati sistemi di "entitlement".

Per quel che concerne il tema connessioni multiple o meno ti do un paio di informazioni utili a comprendere il meccanismo "sottostante".

1) Per quel che concerne le richieste "snapshot" la libreria "dietro le quinte" apre già più connessioni tcp sottostanti la sessione. Le richieste snapshot però lato server hanno un meccanismo di "sincronizzazione" e "accodamento" cliente per cliente per cui una certa loro "sezione" viene elaborata transazionalmente. Da qui il fatto che la scalabiltià dell'approccio multithread non è "Lineare" ma è comunque vantaggiosa. Il parallelo totale inserendo un ordine o modificandolo non sarà mai possibile dovendo intervenire in modalità transazionale ci saranno sempre delle parti da eseguire in modo "atomico".
2) Per quel che concerne i dati di refresh "in push" l'uso di più connessioni è inutile perchè la natura del protocollo è completamente "asincrona". Non è request/response ma pulisher/subscriber e quindi 1, 10, 100 o 1000 connessioni il limite è determinato solo dal tuo bandwidth disponibile.

Spero di essere stato esaustivo se hai ulteriori domande ...... Siamo qui!
Ciao Fabrizio71,

dando un'occhiata più approfondito al codice che hai postato ho notato che è sbagliato.

Il login si effettua in 2 step. Il token si passa al secondpo step.

Puoi consultare il manuale o gli esempi allegati allo zip di STB

Saluti
nmanes wrote:Aggiungerei alla richiesta di tiozzo la seguente:

Quando si effettuano le sottoscrizioni per ricevere i messaggi del Book, ad esempio di questo tipo:

Session.SubscribeInfo(SubscriptionType.Book,
SubscribeUpdateModes.SnapshotAndRefresh,
Session.CreateAutoDispatchQueue(receiveMessageFromSella),
tableStocks);

dicamo che ne facciamo 5 di chiamate da 1000 titoli ognuno
specificando sempre lo stesso nome come MessageQueue e precisamente "receiveMessageFromSella"

DOMANDA:
come si comporta la piattaforma Sella?
cioè:

  • ogni messaggio che arriva in coda (dalle 5 sottoscrizioni), aspetta che la funzione "receiveMessageFromSella" processi quello precedente?

  • viene istanziata in parallelo una nova chiamata (Thread) che processa il messaggio successivo che arriva in coda?

  • vengono create 5 code con 5 istanze della "receiveMessageFromSella" dove ogni istanza processa in serie i messaggi della relativa sottoscrizione?

  • oppure altro modo?


  • spero di aver spiegato bene la cosa

    resto in attesa di una vostra risposta che credo interessi anche tiozzo visto
    che riguarda il funzionamento delle code e dei thread anche per gli ordini..

    Grazie e a presto

    Nicola





    Non sono sicuro di aver compreso la domanda... Anzi mi sa che non l'ho compresa affatto

    Comunque...
    Se intendi che ripeti il codice che hai riportato 5 volte ovviamente crei 5 code distinte.

    Il problema che perdi il riferimento alla coda perchè usi la stessa variabile "receiveMessageFromSella".
    A occhio mi sembra un approccio errato però ripeto probabilmente ho capito male.

    Giulio
    tiozzo wrote:Ciao,
    aggiungo un'altra domanda così facciamo tutto un conto

    Le operazioni dispositive che io faccio dall'interno del sw, per esempio invio di un ordine, modifca di un ordine, cancellazione etc...
    che arrivano poi al server di sella come vengono gestite? Vanno in una coda e quindi sono eseguite in serie o c'è una parallelizzazione
    come se ci fosse un multithread.

    Mi spiego meglio:
    Io nel mio sw potrei inviare 3 ordini in parallelo perchè ognuno va su un proprio thread, ma questi 3 ordini
    come sono gestiti (io uso sempre l'oggetto Session) vanno in una coda verso sella e quindi vengono gestiti in serie
    o vengono gestiti in parallelo?
    Stesso discorso per il ritorno nella PushMessageOrder, possono arrivare messaggi in parallelo o solo in serie?

    Mentre sto scrivendo questo post è arrivata la risposta ad una mia precedente domana e quindi mi sembra di capire che tutte le operazioni
    dispositive, in ingresso e in uscita, fatte su un conto non possono andare in parallelo e vengono gestite una alla volta.

    Giulio, mi confermi questa cosa?
    Non c'è qualche work around che può consentire una sorta di parallelizzazione?

    Grazie 1k
    Matteo.



    Ciao Matteo.

    Nella piattaforma di TradingOnline la transazionalità è gestita per conto.
    Ovvero per lo stesso conto (quindi stesso portafoglio / margini / liquidità) i calcoli vanno fatti in modo "atomico".
    Non c'è alternativa.
    Questa scelta è resa necessaria dal fatto che i calcoli di saldi, margini e liquidità devono prendere in considerazione l'intero portafoglio e di conseguenza le transazioni vanno fatte giocoforza una alla volta.

    Quindi, mentre il sistema processa un'eseguito (mediamente 500ms) o un inserimento ordini (mediamente 400ms) o una modifica (mediamente 200ms), le richieste si "accodano".

    A questi tempi devi aggiungere l'overhead dei tempi rete e parsing delle informazioni in andata e ritorno che, questi sì, sono assolutamente paralleli.

    L'unico workaround che mi viene in mente per operare su molti strumenti in assoluta contemporaneità (come se ci fossero quindi più trader che operano nello stesso istante paragonato al mondo del discrezionale...) è di aprire più conti, anche gesititi da un unico codice internet non importa, e lavoarare aprendo più sessioni ognuna con la sua tupla conto titoli/dossier/conto cash.

    Già averene 2 o 3 anzichè 1 dovrebbe aumentare il parallelismo perchè avendo margini e saldi differenziati si possono fare i conti ogni operazione "separatamente".
    Per esempio potresti segregare l'operatività in base agli strumenti.

    Spero di essere stato chiaro.

    Giulio
    tiozzo wrote:Salve,
    volevo chiedere se è normale che non si possano inserire, in automatico, ordini sul mercato eurotlx dopo le ore 17:00.
    Ricevo infatti il seguente messaggio:
    Errore durante la prepare dell ordine chiave: EuroTlx (Milano) - Fascia oraria non ammessa per questa operazione

    Grazie.
    Matteo


    Si che si può fino alle 17.30.
    Probabilmente stai inserendo ordini short o leva che hanno una limitazione all'inserimento fino alle 17.

    Giulio



    tiozzo wrote:Ciao,
    mi succede in alcuni casi di avere questo messagio di errore a fronte di invio ordine di cancellazione,
    volevo sapere se mi potreste indicare il motivo e il modo per evitarlo.

    27/08/2014 09:57:00:442 Eccezione in EliminaOrdineBuy: Message:Malformed server response
    codice ordine: 20140827204386


    Grazie.
    Matteo


    L'errore "Malformed Rsponse" eliminando un ordine significa che la cancellazione non è più effettuabile perchè nel frattempo l'ordine è stato eseguito (o già revocato...)

    Che verisone stai usando della libreria?
    Perchè nell'ultima il problema del messaggio poco parlante era stato risolto....

    Giulio
    tiozzo wrote:Ciao,
    volevo capire bene come funziona tutto il giro, quindi ricapitolo i passi:

    ora invio ordine; questo è l'istante prima di fare l'istruzione
    Session.OrderManager.PrepareDeleteOrder(order);
    18/08/2014 09:05:03:272 EliminaOrdineBuy: codice_ordine_buy 20140818201781

    dopo di che il codice prosegue così:

    if (order.ErrorLevel == ErrorLevelType.Ready)
    {

    Session.OrderManager.ExecuteDeleteOrder(order);
    switch (order.ErrorLevel)
    {
    case ErrorLevelType.Executed:
    Log.Write("EliminaOrdineBuyInviato: Ordine inviato: p.codice_ordine_buy " + p.codice_ordine_buy + " " + p.key);
    ..........................

    e quando va nel ramo Executed io loggo il fatto che l'ordine è stato inviato
    18/08/2014 09:05:07:908 EliminaOrdineBuy: Ordine inviato: codice_ordine_buy 20140818201781

    In questo intervallo di tempo di 4 secondi e passa il sw su quel thread non fa nient'altro che aspettare appunto la risposta da sella
    Quindi domande:
    1 - che è successo in questi secondi?
    2 - Non è possibile inviare una cancellazione in un solo passo, tipo l'inserimento fast?

    Dopo di che mi è arrivato il relativo messaggio di cancellazione nella PushMessageOrder a quest'ora
    18/08/2014 09:05:07:979 PushMessageOrder message.Fields[0].Content: TRADING.ORDERS.DELETED.1752 Codice_Ordine: 20140818201781

    quindi da quando ho fatto la Session.OrderManager.PrepareDeleteOrder(order)
    fino a quando mi è arrivato l'ok dal mercato/broker dell'ordine cancellato (e quindi quando è stato cancellato effettivamente l'ordine)
    sono passati 4 secondi e 700 ms circa.

    A parte il fatto che i due orologi (il mio e il vostro mi riferisco agli orari assoluti, ma i delta sono congruenti) potrebbero essere non allineati volevo capire da voi se magari c'è qualcosa che sbaglio
    o se può essere fatto perchè ho visto che alcune volte ci sono rallentamenti anche su altri tipi di ordine (tipo modifica).

    Grazie.
    Matteo



    Ciao Tiozzo.
    Scusa il ritardo.
    Rispondo alle domande di questo post.

    1. Nel tempo che intrecorre fra le check e la execute delete order facciamo semplicemente i controlli che l'ordine sia eliminabile. Solitamente è molto veloce.
    2. No non è possibile farlo in una sola invocazione.

    Alcuni picchi nel tempo di risposta possono dipendere che su un singolo conto le operazioni non possono essere parallellizzate per motivi gi gestione della transazionalità e vanno fatte una alla volta.
    Quindi se operi in parallelo su molti strumenti con molti esiti sullo stesso conto potresti avere qualche collo di bottiglia.

    Giulio
    enricod75 wrote:Buongiorno,

    volevo chiedere tramite quale campo del flusso "price" sia possibile ottenere il prezzo teorico di riapertura in caso di un'asta di volatilità durante la negoziazione continua.
    In specifico: l'OPEN_PRICE, viene aggiornato con il nuovo valore teorico di riapertura, oppure rimane fisso al valore di apertura giornaliera?

    Grazie


    Il campo OPEN_PRICE contiene il teorico durante l'asta di apertura o di volatilità intraday e l'apertura effettiva (ammesso che venga realizzata) a fine della fase di auction.

    Saluti
    astrazze wrote:Buongiorno,

    ho due domande da porre:

    1) leggendo la documentazione ho intuito che per modificare un ordine già eseguito è necessario
    impostare il codice dell'ordine resitituito in fase di inserimento. Presumo quindi che si debba
    costruire un ordine come se lo si volesse inserire (new Order) e assegnargli il codice dell'ordine
    esistente. Non trovo però la proprietà da utilizzare per assegnare il codice (OrderCode è di
    sola lettura)

    2) se imposto un'ordine di tipo "Market" e voglio acquistare, presumo che l'ordine sarà eseguito
    con il prezzo ask del livello 1 del book quando il mio ordine verrà processato da Borsa Italiana.
    Ora, se il mio ordine non è stato ancora processato e il livello 1 del book cambia, il mio ordine
    sarà processato con il nuovo prezzo in automatico o devo provvedere a modificare l'ordine con
    il prezzo del nuovo livello 1 ?

    Grazie

    /Alessandro


    1) L'ordercode lo assegnamo noi a ordine inserito sui server sella. Per quello la proprietà è di sola lettura. Se ritieni puoi usare la propietà ClientID per associare un tuo codice ordine. Tale campo non lo trattiamo e ti ritorna in "eco" in ogni notifica.

    2) Il tuo ordine di esempio, se è al meglio, verrà eseguito alla NUOVA miglior lettera.

    Ciao
    Gentile Felix68,

    le strategie, così come gli ordini, valelvoli per la seduta successiva sono visualizzabili nello stato ordini filtrando per modalità "Prenotati".
    Da lì è possibile eventualmente revocarli.
    Questa impostazione è la medesima su tutte le nostre interfacce di front-office di SellaXTrading (Web, mobile, Tablet, SellaExtreme4 e SellaExtreme5)


    Esempio:
    Dovremmo avere chiarito i dubbi telefonicamente.

    Nel frattempo la saluto.

    Per eventuali problemi ulteriori in merito a questa modalità di accesso "temporanea" mi contatti pure in pvt.


    Buongiorno a tutti.

    Abbiamo rilasciato la verisone 1.3.3.0 di SellaTradingBridge.

    La versione è disponibile al link http://download.sella.it/SellaTradingBridge.zip

    Le novità salienti sono:

    1) Possibilità di inerire stop order smplicemente fillando la nuova proprietà StopPrice della classe Order. Documentato in SellaTradingBridgeOvervier a pagina 29 e in "SellaTradingBridgeHELP.chm" su manespace XRemoting.Data.Order

    2) Aggiunta alla classe Message la proprietà MessageType documentato su "SellaTradingBridgeHELP.chm". Definisce la classe "push" del messaggio

    3) Aggiunto il flusso BOND_ACCRUALS nel servizio di download file anagrafici come documentato su "DownloadAnagrafiche.pdf". Nel file sono presenti i ratei le imposte per strumento/data valuta utili per calcolare i controvalori degli ordini obbligazionari.

    4) Vario bug fixning

    A disposizione per chiarimenti

    Saluti
    spartacus wrote:come faccio a collegare sella bridge con multicharts


    Deve aspettare che rilasciamo l'apposito plugin per multichart su cui stiamo effettuando gli ultimissimi test.

    Dalla prossima verisone di multichart il plugin verso stb sarà incluso nel prodotto (ci troverà sia nella lista dei broker che in quella dei fornitori di datafeed built in)



     
    Indice dei Forum » Profilo per giulio.rattone » Messaggi inviati da giulio.rattone
    Vai a:   
    E.t.v.s.p.b WLS11G