Discussion :

[sp2308]

Bonjour

Je créé un fichier comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MemoryMappedFile mmf = MemoryMappedFile.CreateOrOpen("Essai", 1000);
MemoryMappedViewAccessor accessor = mmf.CreateViewAccessor();

Le truc c'est que j aimerais pouvoir en creer plusieurs (sans en connaitre le nombre par avance) et les appeller par leur nom style mmf["Essai"].dispose().

Etant donné que je debute en C# et en programmation objet, je cherche et je trouve que pour appeler un index 'string', je dois utiliser un dictionary.Mais là comment construire mon fichier ?
Alors Je me dis qu il serait plus simple de creer un objet que j'appellerais par une de ses proprietes...

Et là je suis plus perdu encore.

J ai donc besoin de vos lumieres.
Un conseil, un exemple, un lien... Je prends tout ;-)

Merci pour vostre aide

Stéphane

[Donpi]

Une classe avec un indexeur devrait faire l'affaire.

"c# indexer" dans google, deuxième lien

[ZenZiTone]

Le truc c'est que j aimerais pouvoir en creer plusieurs (sans en connaitre le nombre par avance) et les appeller par leur nom style mmf["Essai"].dispose().
[...]

Un conseil, un exemple, un lien... Je prends tout ;-)

Plusieurs questions :

Qu'est-ce qui motive la création de ces fichiers? Qui demande la création (dans le programme hein)? Qui utilise ces fichiers?
Quand tu parles d'index, Est-ce juste pour le nommage du fichier?

Il existe mille solutions à un problème. Éclaire nous sur le contexte qu'on puisse te proposer les conseils les plus pertinents

[sp2308]

Merci pour le lien, je vais me pencher là dessus.

Ce qui motive cette creation c est un robot de trading.
En fait jai une appli CORE qui dialogue avec les robots et avec le broker (qui forunit les cotes et avec lequel on passe les ordre)

Mon idee est la suivante :
A l ouverture de core, il cree le fichier de dialogue

A l ouverture d un robot, il s identifie aupres de CORE vial le fichier Dialogue.Il y envoit ses ordres de transaction et reçoit les reponses.

Mais quand le robot s identifie aupres de CORE il lui fait part de ses besoins en terme de paire de devise à surveiller.Core cree donc un fichier du nom de cette paire de devise par lequel il fera transiter les cours à destination de tous les robots qui utilisent cette paire de devise.

Voila qui j espere avoir repondu à tes questions.

Je precise que j ai choisis les fichiers mappés pour leur rapidité et leur simplicité d emploi (quoi que là j ai atteint mes limites et celle de l emploi associé avec FileSystemWatcher de mon ppost

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://www.developpez.net/forums/d1605135/dotnet/general-dotnet/debuter/fichiers-mappes-p-filesystemwatcher/

).

voila je suis donc ouvert à toutes propositions, idees conseils etc :-)

merci

stéphane

[DotNetMatt]

voila je suis donc ouvert à toutes propositions, idees conseils etc :-)

C'est irrealiste de vouloir creer un robot de trading base sur des fichiers. Trading = multithreading, car il faut gerer les rafraichissements de l'UI, les calculs, les ordres, etc. Et avant toute chose, on veut faire ca en temps reel. Les fichiers ne permettent pas de gerer des ecritures concurrentes, car un verrou est pose sur le fichier lorsqu'il est en lecture ou en ecriture. Cela signifie qu'il ne peut y avoir qu'une seule operation en meme temps, ce qui n'est pas le cas avec un SGBDR.

Et je ne parle pas des problemes de performance liees a la taille des fichiers (quand ils vont devenir tres gros ou qu'il y aura enormement de fichiers). Tout cela est limite par les performances intrinseques de ton hardware. Il est bien plus rapide de travailler en memoire (ce que font les SGBDR).

La solution la plus fiable pour travailler avec des fichiers et d'utiliser un systeme de queues et d'y pousser les messages en asynchrone. Mais pour un systeme de trading, encore une fois il faut faire du temps reel donc ca n'est pas envisageable...

Mon conseil : met en place un SGBDR comme SQL Server Express par exemple, pour commencer.

[sp2308]

je me suis mal exprimé visiblement.
les fichiers n'auront qu une ligne du style 1.23456;1.23456 c est pour cela qu il y aura 1 fichier par paire de devise. Il n est qu en memoire et pas ecrit physiquement sur le DD
je ne conserve pas les données passées, seule la derniere compte. Je ne fais pas de chart, je conserve seulement un tableau avec les 50 derniere prix dans chaque exe robot.
le rafraichissement des prix se fait entre 10 fois (le modele standard) et 100 fois par secondes (pour les institutionnels et les pros 'à gros volume) sur lmax api.
ma logique est que (mais dis le moi si je me trompe), chaque robot etant un exe, il s execute dans un thread séparé + 1 thread pour le core (ecoute des ticks) + 1thread pour le core dial avec robot pour les ordres.
J ai testé avec un timer (en delphi que je connais un peu mieux) et cela fonctionne parfaitement avec un robot par paire de devise et un rafraichissement des prix toutes les 100 ms.
(en realité je lis une ligne de prix dans un fichier sur DD pour simuler l'arrivée d'un prix, ce qui selon moi devrait prendre plus de temps que l arrivee d'un prix avce l'api).
Le robot a aussi un timer et tous les 100ms il lit le fichier de prix en memoire.
D un côté commed e l autre la lecture et l'ecriture se font dans une boucle while avec un try qui fait que l'on ne peut sortir de la boucle qu une fois l action (lecture ou ecriture) effectuée.
Le temps de l execution de cette boucle sera pris en compte lors de la comparaison du teps ecoulé dans la boucle for de lecture des prix.
Donc mon raisonnement est le suivant si j ai une boucle de 10 paire de devises et que je boucle en memorisant le datetime du dernier appel.Si l'apple date de moins de 100ms, j attends jusqu'à atteindre ces 100ms et effectue l'appel. Ensuite je distribue.
J ai chois ce systeme de fichier en memoire car j ai lu partout qu il etait le plus rapide des moyens de communication.
Je n imagine pas qu'une requete d extraction de bdd et son traitement soit plus rapide qu'un simple 'read' sur un fichier en memoire qui ne comporte qu une ligne d autant qu'avant de lire dans une bdd il faut y inscrire les données (dans les deux cas) mais un simple write sur un fichier mais il est vrai que je ne connais pas assez les perfs des bdd.
Ok j ai bien compris que la bdd etait en memoire aussi mais il y a la structure, les regles acces... c est pour ça que j imagine que c est plus lent.

Sinon concernant le trading en temps réel c est une vue d esprit.
Une fois que le cours est arrivé sur mon pc il se peut qu il ait déja evolué. Des outils comme mt4 sont lents.
L'api quant à elle permet des transmissions plus rapides mais les prix sont décalés et c est pour cela qu un rafraichissement toutes les 100 ms est suffisant dans mon cas d autant que je ne vise pas le scalping...

Voila je suis ouvert à toutes tes remarque

[DotNetMatt]

je me suis mal exprimé visiblement.

Oui Maintenant que tu as precise tout cela, mes remarques sont beaucoup moins pertinentes. Donc oui dans ce cas, ton systeme devrait suffire.

Concernant les SGBDR, ca depend. Si ton SGBDR et ton appli sont sur le meme LAN, avec cablage en fibre optique, le SAN qui va bien et tout le tintouin, les temps d'acces sont extremement courts, mais restent quand meme plus lents qu'un simple acces en memoire sur le meme serveur c'est clair. Apres, si on prend aussi en compte l'avantage offert en terme de multi threading, qui permet de litteralement bombarder une DB, ca peut changer la donne, au prix de quelques micro secondes.

Au NASDAQ ils ont migre sur une archi full SQL Server et ils gerent plusieurs milliards de transactions boursieres par jour sans aucun souci. Bien sur il n'y a pas qu'une seule DB pour gerer tout ca, mais les possibilites sont enormes. A la SG les automates bossent avec un mix de bases Oracle et SQL Server.

[sp2308]

Bon je suis rassuré, mon raisonnement n est pas totalement erroné.
Quoi qu il en soit, seule la mise en service sur un VPS (avec un compte démo dans un premier temps) me permettra de valider mon concept.