La Divulgation complète: je travaille pour Informatica (anciennement 29West) et je suis sur l'équipe d'ingénierie responsable de leurs produits de messagerie. Je suis partial. Je ne, cependant, ont une assez bonne compréhension de la faible latence de messagerie dans le marché financier.
Si vous message les tarifs sont d'environ 60 messages/sec. (comme indiqué dans un commentaire sur la Volonté du Doyen de réponse), et ils sont livrés à une interface graphique avec un homme assis en face de lui et à faire réagir le marché de l'homme-vitesse, honnêtement il n'est pas question beaucoup ce logiciel que vous utilisez à partir d'un temps de latence point de vue. Vous pourriez même être en mesure de s'en tirer avec l'aide de la WCF (même si je serais encore recommandons contre elle; on envisage d'appuyer une fois et prototypé un adaptateur pour elle et il pléthorique des latences par un ordre de grandeur - nous avons décidé de ne pas s'embêter avec ça à l'époque).
Maintenant, Informatica logiciel de messagerie peuvent passer des messages entre processus sur la même machine en moins d'une microseconde, et si vous voulez acheter quelques belles 10 gig-E Nic avec un noyau de dérivation ou InfiniBand du matériel, vous pouvez passer des millions de messages par seconde entre les machines avec un seul chiffre microsecondes de la latence. Nous allons également bientôt sortir un nouveau sérialisation de données de la bibliothèque pris en charge en C/C++, Java et .NET dans le cadre de la messagerie produit que, dans certains cas, c'est effectivement plus rapide que le Protocole Tampons (même si le Protocole Tampons sont largement utilisés et également un très bon choix). Notre .NET et Java Api les deux ont une fonctionnalité appelée "ZOD" pour "Zéro de l'Objet de Livraison", ce qui est plutôt une drôle de façon de dire qu'elles ne génèrent pas de nouveaux objets lors de la livraison du message, ce qui signifie pas de collecte des ordures pauses & associés des pics de latence/valeurs aberrantes. Nous avons un autre produit appelé UMD qui est conçu spécialement pour fan de base à haut débit de circulation plus lente des applications de bureau sans ralentir la colonne vertébrale ou d'autres clients.
Je pourrais continuer encore et encore sur la façon dont grand d'Informatica logiciel de messagerie est et je ne pense qu'il vaut la peine de vérifier, mais cela ressemble déjà à un straight-up ad, et je suis ingénieur, pas une personne de vente. Voici donc quelques morceaux de plus de conseils généraux:
Si vous avez beaucoup de clients qui reçoivent les mêmes données, vous aurez envie certaine saveur de multidiffusion UDP. Vous voudrez souvent un fiable multidiffusion le transport de quelque nature: le bien-connus (et gratuit) fiable protocole de multidiffusion est PGM. Windows inclut une implémentation de PGM qui est utilisable en C#; je vais vous référer à Mike Rettig de l' excellent billet de blog sur la façon de l'utiliser si vous voulez l'essayer. (Je sais, Mike - il est un gars intelligent.) Le choix du protocole est une zone dans laquelle vous obtenez ce que vous payez; Informatica de messagerie comprend un support fiable protocole de multidiffusion vaguement basé sur des PGM (notre architecte qui l'a conçu a co-écrit le PGM RFC longtemps à l'arrière), mais avec beaucoup d'améliorations majeures. Plaine PGM peut être très bien pour ce que vous avez besoin, cependant.
Vous voulez aller avec une brokerless/sans serveur de l'architecture. Avoir les applications de communiquer d'égal à égal avec rien dans le milieu. Éviter supplémentaire de houblon dans le chemin de message (ce qui signifie en général d'éviter la plupart des JMS implémentations, à éviter presque rien avec "file d'attente" dans le nom quelque part, etc.).
Être conscient de la façon dont votre système se comporte lorsqu'un client se comporte mal. Peut-on ralentir la consommation de ralentir tout le monde?
Il y a beaucoup d'OS de paramétrage du BIOS et des options de paramétrage qui peut profiter à toute sorte de faible latence de messagerie, fait maison ou acheté - des choses comme l' interruption de la coalescence, en les liant NIC interruptions à un cœur de PROCESSEUR, l'échelle côté réception (qui a toujours été terrible, lorsqu'il est utilisé avec UDP sur Windows, mais devrait être d'obtenir beaucoup mieux à l'avenir), la désactivation de certaines de puissance CPU unis, etc.
Résister à la tentation d'utiliser les haut-sérialisation d'un objet dans .NET pour envoyer l'ensemble des objets sur le fil - c'est un ordre de grandeur plus lent que la simple utilisation d'un format binaire (comme le Protocole de Tampons, ou la sérialisation de la bibliothèque ou de votre propre format binaire, etc.).
Si vous avez des questions plus spécifiques ou besoin de plus de détails sur aucun de mes conseils, faites le moi savoir!
