Méthode recommandée pour mettre en œuvre un flux de données financières en temps réel à faible temps de latence avec WCF?
J'ai un service .NET qui doit transmettre des données financières en direct à ses clients. Le débit de sortie de ce flux peut devenir intense et je recherche la meilleure architecture pour implémenter ce type de service avec une latence faible et des performances élevées.
Je pensais utiliser un type de fournisseur de données de flux, utilisé pour l'audio ou la vidéo, mais envoyer des mises à jour de flux.
Apprécierait toute pensée sur ce sujet, ou des exemples du monde réel
Mettre à jour:
Je n'ai pas besoin d'utiliser WCF, ce n'était que ma première approche puisqu'il s'agit de la technologie actuelle. Toute autre implémentation en C # est la bienvenue.
Divulgation complète: Je travaille pour Informatica (anciennement 29West) et je fais partie de l'équipe d'ingénierie responsable de leurs produits de messagerie }. Je suis biaisé. Cependant, je connais assez bien la messagerie à faible latence sur le marché financier.
Si vos messages ont un débit d'environ 60 messages/sec. (comme indiqué dans un commentaire sur la réponse de Will Dean), et ils sont livrés à une interface graphique avec un humain assis devant lui et réagissant au marché à la vitesse de l'homme, honnêtement, peu importe quel logiciel vous utilisez du point de vue de la latence. Vous pourriez même vous débrouiller avec l'utilisation de WCF (bien que je le recommande tout de même contre; nous avons envisagé de le supporter une seule fois et nous avons créé un adaptateur pour ce prototype, ce qui a entraîné une augmentation considérable du temps de latence - nous avons décidé de ne pas le déranger. à l'époque).
Maintenant, le logiciel de messagerie d’Informatica can / transmet les messages entre les processus d’une même machine en une microseconde, et si vous souhaitez acheter des cartes réseau Nice 10 gig-E avec bypass du noyau ou équipement InfiniBand, vous pouvez passer millions de messages par seconde entre des machines avec une microseconde de latence à un chiffre. Nous allons également publier prochainement une nouvelle bibliothèque de sérialisation des données prise en charge en C/C++, Java et .NET dans le cadre du produit de messagerie qui, dans certains cas, est en réalité plus rapide que les tampons de protocole (bien que les tampons de protocole soient largement utilisés et également très répandus). très bon choix). Nos API .NET et Java ont toutes deux une fonctionnalité appelée "ZOD" pour "Livraison d'objet zéro", ce qui est une manière assez amusante de dire qu'elles ne génèrent aucun nouvel objet lors de la remise du message, ce qui signifie qu'aucune pause de la récupération de place et les pics/aberrations de latence associées ne sont générés. Nous avons un autre produit appelé UMDS spécialement conçu pour répartir le trafic dorsal à grande vitesse vers les applications de bureau plus lentes sans ralentir le dorsal ou les autres clients.
Je pourrais continuer encore et encore à dire à quel point le logiciel de messagerie d’Informatica est formidable et je pense que cela vaut la peine de vérifier, mais cela ressemble déjà à une annonce simple et je suis un ingénieur, pas un vendeur. Alors voici quelques conseils plus généraux:
Si de nombreux clients reçoivent les mêmes données, vous souhaiterez un aperçu de la multidiffusion UDP. Vous voudrez souvent un type de transport fiable pour la multidiffusion - le protocole de multidiffusion fiable bien connu (et gratuit) est le protocole PGM. Windows inclut une implémentation de PGM utilisable en C #; Je vous renvoie au excellent blog de Mike Rettig pour savoir comment l'utiliser si vous voulez l'essayer. (Je connais par hasard Mike - il est un type malin.) Le choix du protocole est un domaine dans lequel vous en avez pour votre argent; La messagerie d’Informatica inclut un protocole de multidiffusion fiable basé sur PGM (notre architecte qui l’a conçu a co-écrit le RFC PGM il y a longtemps), mais avec de nombreuses améliorations majeures. La simple PGM pourrait bien convenir à vos besoins.
Vous voulez aller avec une architecture sans courtier/sans serveur. Demandez aux applications de communiquer d'égal à égal avec rien au milieu. Évitez les sauts supplémentaires dans le chemin du message (ce qui signifie généralement d'éviter la plupart des implémentations JMS, évitez presque tout ce qui a une "queue" quelque part, etc.).
Soyez attentif au comportement de votre système lorsqu'un client individuel se comporte mal. Un consommateur lent peut-il ralentir tout le monde?
Il existe de nombreuses options de réglage du système d'exploitation et du BIOS qui peuvent profiter à tous les types de messagerie à faible latence, internes ou achetés - des choses comme interruption , liant NIC interruptions à un processeur particulier mise à l'échelle du côté de la réception (qui a toujours été terrible avec UDP sous Windows, mais devrait s'améliorer à l'avenir), désactivant certains états d'alimentation du processeur, etc.
Résistez à la tentation d'utiliser la sérialisation d'objet intégrée dans .NET pour envoyer des objets entiers par fil - c'est beaucoup moins rapide que d'utiliser un simple format binaire (comme un tampon de protocole, la bibliothèque de sérialisation d'Informatica, votre propre format binaire, etc.). .).
Si vous avez des questions plus spécifiques ou si vous avez besoin de plus de détails sur l'un de mes conseils, faites le moi savoir!
À quel point la «faible latence» est-elle basse et à quel point l'activité est-elle intense? Vous devez avoir une idée de ce que vous visez pour choisir la bonne approche.
Je pourrais vous fournir du matériel qui répondrait à 100% de toutes les demandes, disons entre 20 et 100% de la capacité de votre matériel réseau, mais il n’utiliserait pas du tout WCF.
De manière très générale, je dirais que des éléments tels que WCF sont un très haut niveau et une facilité d'utilisation et un abstraction avantageux pour le programmeur par rapport aux performances (latence/débit). Qu'ils échangent trop pour votre application nécessite des nombres réels.
Le protocole basé sur IP au temps de latence le plus bas et au temps système le plus bas et largement utilisé est le protocole UDP - c'est pourquoi il est utilisé pour des applications comme DNS et NTP. Il est très évolutif sur le serveur, car celui-ci n'a pas besoin de conserver aucun état et il est très simple à mettre en œuvre sur presque toutes les plates-formes. Mais vous devez penser en termes de paquets réseau plutôt que d'objets .NET. Avez-vous également la possibilité de fournir le logiciel client?
Données financières en direct? Ne comptez jamais sur WCF pour cela. Au lieu de cela, allez avec ce que les autres industries utilisent. C'est-à-dire que NASDAQ utilise Innovations en temps réel - Service de distribution de données pour délivrer des ticks de stock en direct aux utilisateurs. Ils fournissent une api C/C++/C # pour leurs bibliothèques de communication, ce qui est extrêmement facile à configurer et à utiliser (par rapport à WCF).
En général, ce type de flux de données en temps réel utilise le paradigme publish/subscribe , qui permet de s’assurer que la communication se déroule avec un minimum de temps système. Ce type d’approche est l’idée principale du middleware orienté message et c’est exactement ce que les services financiers utilisent pour les contenus en temps réel.
Sur un nœud latéral, vous pouvez transmettre des paquets audio-vidéo en temps réel à l'aide de la bibliothèque RTI-DDS. Autant que je sache, des véhicules aériens sans pilote comme MQ-9 utilisent à nouveau cette bibliothèque pour transmettre des informations vidéo en direct et de géolocalisation au sol. stations de contrôle.
Il existe également des bibliothèques de services de distribution de données gratuites, mais je n'en ai aucune expérience. Vous avez juste besoin de google pour cela.
Edit : Je suis en train de prototyper un logiciel IHM (interface homme-machine) qui utilise les bibliothèques RTI-DDS susmentionnées, ainsi que deux autres bibliothèques dotées d'architectures orientées message, qui fonctionnaient jusqu'à présent pour tous. mes besoins de communication en temps réel. Voici une démo: http://epics.codeplex.com/ (Elle sera utilisée pour contrôler à distance les équipements de notre tout nouveau centre de recherche nucléaire)
Plus vous faites d'hypothèses et de fonctionnalités, plus vite vous pouvez rendre votre système. Plus vous essayez de créer des outils robustes et flexibles, plus votre performance en souffrira. Je suggérerais quelques éléments essentiels indispensables:
- Un format de sérialisation de données binaires. N'utilisez pas XML ou toute autre méthode lisible par un humain Pour transmettre vos données .
- Un format de sérialisation De données suffisamment robuste pour qu'il puisse Prendre en charge l'architecture terminale, Les points de terminaison multilingues. BER vient à l’esprit - C # semble avoir un soutien
- Un protocole de transport qui garantit une livraison et une intégrité des données . Si un type d’algorithme financier utilisant Utilisait Ces données, même un signe Manquant pourrait signifier la différence entre Et un ordre déclenché ou manquant sur un prix. Même si vous allez agréger les graduations sur votre serveur., Vous souhaitez toujours contrôler La manière dont les informations sont présentées à Vos clients. TCP fonctionne pour les systèmes distribués. Cependant, il existe des alternatives beaucoup plus rapides si vos clients sont sur le même ordinateur que votre serveur. UDP ne veut même pas se faire passer une commande, ce qui peut être problématique (mais pas insurmontable).
En ce qui concerne le traitement interne:
- Évitez les chaînes et autres classes qui Ajoutent un surcoût important aux tâches simples . Utilisez des tableaux de caractères de base À la place. Je ne suis pas sûr des options Que vous avez en C # ou même si vous avez même des alternatives Légères. Si oui, utilisez Eux. Ceci s'applique également aux structures de données.
- Soyez conscient des erreurs de comparaison double/float. Utilisez des comparaisons qui vérifient uniquement le niveau de précision requis. Si possible, convertissez tous les éléments en nombres entiers en interne et fournissez suffisamment de métadonnées pour les reconvertir à l’autre bout.
- Utilisez quelque chose de similaire aux allocateurs en pool en C++. Mon manque de connaissance de C # m'empêche d'être plus spécifique. Encore une fois, C # n'est probablement pas votre meilleur choix ici. En bout de ligne, vous allez créer et détruire de nombreux objets tick et il n’ya aucune raison de demander à la mémoire du système d’exploitation à chaque fois.
- N'envoyez que des deltas, n'envoyez pas les informations que vos clients ont déjà. Cela suppose que vous utilisez un transport avec livraison garantie. Sinon, vous pourriez afficher des données obsolètes pendant longtemps.
Vous posez spécifiquement la question sur un "flux utilisateur à faible latence". Que voulez-vous vraiment avec une latence faible, pour «Flux uniquement» (et surtout si cela ne génère pas de revenus), les utilisateurs pourraient-ils attendre une seconde; ce n'est pas une faible latence.
Si vous souhaitez effectuer un échange RAPIDE, vous devez vous déplacer physiquement dans la rue depuis la Bourse (ou à proximité avec un lien optique). Ensuite, vous devez «échanger sur la carte»; la carte Ethernet est «intelligente» et est alimentée par des «formules commerciales» qui la programment pour effectuer une transaction préprogrammée en fonction des données reçues (sans perturber votre ordinateur).
Apprendre à manipuler cet environnement vous en achètera plus que de réinventer la roue.
Une latence ultra faible est coûteuse, mais des milliards sont en jeu. vos enjeux (et la poursuite de la latence inférieure) avec être étranglé par $.
Cela pourrait présenter un intérêt bien que spécifique au jeu ... Protocole de transfert Internet de données de petite taille avec la plus faible latence? c #
Voici un tutoriel sur la connexion UDP http://www.winsocketdotnetworkprogramming.com/clientserversocketnetworkcommunication8r.html
Un autre article sur UDP http://msdn.Microsoft.com/en-us/magazine/cc163648.aspx
Dans le passé, j’utilisais des prises de courant ou des supports bruts Tibco pour les prix/taux en continu, où des mises à jour à haute fréquence étaient attendues. Dans cette situation, c’est souvent le client (ou en fait l’utilisateur) qui constitue la limitation (car il n’ya que peu de mises à jour qu’un utilisateur puisse traiter), c’est donc un exemple de perte de données. Dans cette situation, un courtier de service côté client peut être utilisé pour limiter les mises à jour.
Si le système est utilisé pour le trading automatisé ou HFT, il a été prouvé que des produits tels que 29West LatencyBuster fonctionnent correctement et offrent une messagerie garantie.