Лучшая практика для использования фида финансовых данных с низкой задержкой с использованием WCF?

Ответ 1

Полное раскрытие: я работаю в Informatica (ранее 29West), и я в инженерной команде, ответственной за свои продукты для обмена сообщениями. Я предвзятый. Однако у меня есть довольно хорошее понимание сообщений с низкой задержкой на финансовом рынке.

Если скорость сообщений составляет около 60 сообщений в секунду. (как указано в комментарии к ответу Дина Дин), и они доставляются в графический интерфейс с человеком, сидящим перед ним и реагирующим на рынок со скоростью человека, честно говоря, не имеет значения, какое программное обеспечение вы используете с точки зрения латентности. Возможно, вам удастся избежать использования WCF (хотя я бы порекомендовал его, и мы решили поддержать его один раз и прототипировали адаптер для него, и он раздувал задержки на порядок - мы решили не беспокоиться об этом в то время).

Теперь программное обеспечение для обмена сообщениями Informatica может передавать сообщения между процессами на одной и той же машине в течение микросекунды, и если вы хотите купить несколько симпатичных сетевых адаптеров 10 gig-E с обходом ядра или устройством InfiniBand, вы можете передавать миллионы сообщений за вторых между машинами с одноразрядными микросекундами задержки. Мы также скоро выпустим новую библиотеку сериализации данных, которая поддерживается в C/С++, Java и .NET как часть продукта обмена сообщениями, которая в некоторых случаях на самом деле быстрее, чем протокольные буферы (хотя протокольные буферы широко используются, а также очень хороший выбор). Наши .NET и Java API имеют функцию "ZOD" для "Zero Object Delivery", что является забавным способом сказать, что они не генерируют новых объектов во время доставки сообщений, что означает отсутствие пауз для сбора мусора и связанных с ними спайков/выбросов. У нас есть еще один продукт под названием UMDS, специально разработанный для разгона высокоскоростного магистрального трафика на более медленные настольные приложения без замедления работы магистрали или других клиентов.

Я мог бы продолжать и рассказывать о том, как отличное программное обеспечение для обмена сообщениями Informatica, и я считаю, что стоит проверить, но это уже похоже на прямое объявление, и я инженер, а не продавец. Итак, вот несколько советов:

• Если у вас много клиентов, получающих одни и те же данные, вам понадобится некоторый вкус многоадресной рассылки UDP. Вам часто понадобится надежный многоадресный транспорт - известный (и бесплатный) надежный многоадресный протокол - PGM. Windows включает в себя реализацию PGM, которая используется в С#; Я передам вам Майка Реттига отличное сообщение в блоге о том, как его использовать, если вы хотите попробовать его. (Я знаю Майка - он умный парень.) Выбор протокола - это область, в которой вы получаете то, за что платите; Обмен сообщениями Informatica включает в себя надежный многоадресный протокол, свободно основанный на PGM (наш архитектор, который разработал его, совместно написал PGM RFC долгое время назад), но с большим количеством существенных улучшений. Обычная PGM может быть хорошо для того, что вам нужно.

• Вы хотите пойти с брокерской/серверной архитектурой. Предложите приложениям общаться одноранговым узлом, ничего не посередине. Избегайте дополнительных переходов в пути сообщения (что обычно означает избегать большинства реализаций JMS, избегать почти ничего с "queue" в имени где-то и т.д.).

• Помните о том, как ваша система ведет себя, когда один индивидуальный клиент ошибается. Может ли медленный потребитель замедлить всех остальных?

• Существует множество настроек настройки ОС и настройки BIOS, которые могут принести пользу любым типам обмена сообщениями с низкой задержкой, домами или купленными - такие вещи, как прерывание объединяясь, связывая прерывания NIC с конкретным ядром процессора, масштабированием на стороне приема (которое исторически было ужасно при использовании с UDP в Windows, но должно быть намного лучше в будущем), отключение определенных состояний мощности процессора и т.д..

• Сопротивляйтесь соблазну использовать встроенную сериализацию объектов в .NET для отправки целых объектов по проводам - ​​это на несколько порядков меньше, чем при использовании простого двоичного формата (например, протокольных буферов или библиотеки сериализации Informatica или ваш собственный двоичный формат и т.д.).

Если у вас есть более конкретные вопросы или вам нужно больше деталей по любому из моих советов, просто дайте мне знать!

Ответ 2

Насколько низкая "низкая латентность" и насколько занят "интенсивный"? Вам нужно иметь представление о том, на что вы стремитесь выбрать правильный подход.

Я мог бы предоставить вам некоторое оборудование, которое отвечало бы на 100% всех запросов внутри, скажем, 20us, до полной емкости вашего сетевого оборудования, но вообще не использовало бы WCF.

В очень широком приближении я бы сказал, что такие вещи, как WCF, являются очень высокоуровневой и компромиссной простотой использования и абстракцией для выгоды от производительности (задержка/пропускная способность). Независимо от того, продают ли они это слишком много для вашего приложения, нужны реальные цифры.

Протокол с наименьшей задержкой, самый низкий по сравнению с IP-протоколом, который широко используется, - UDP, поэтому он используется для таких вещей, как DNS и NTP. Он очень масштабируемый на сервере, потому что серверу не нужно сохранять какое-либо состояние, и его очень просто реализовать практически на любой платформе. Но вам нужно думать о сетевых пакетах, а не об объектах .NET. Получаете ли вы также поставку программного обеспечения для клиента?

Ответ 3

Текущие финансовые данные? Никогда не полагайтесь на WCF. Вместо этого перейдите к тому, что используют другие отрасли. то есть NASDAQ использует "Инновации в режиме реального времени" - службу распространения данных, чтобы доставлять пользователям живые тики. Они предоставляют C/С++/С# api для своих коммуникационных библиотек, которые очень легко настроить и использовать (по сравнению с WCF).

В общем, такие типы данных в режиме реального времени используют публикацию/подписку парадигмы, которая помогает убедиться, что связь происходит с минимальными накладными расходами, Такой подход является основной идеей в ориентированном на сообщения средним изделиям, и именно это означает, что финансовые услуги используют в реальном времени.

На стороне node вы можете доставлять аудио-видео пакеты реального времени с использованием библиотеки RTI-DDS, насколько я знаю, беспилотные летательные аппараты, такие как MQ-9, снова используют эту библиотеку для доставки видео в реальном времени и гео- информацию о местоположении на наземные станции управления.

Существуют также бесплатные библиотеки служб распространения данных, но у меня нет опыта в них. Для этого вам просто нужно google.

Изменить. Я сейчас прототипирую некоторое программное обеспечение интерфейса человеко-машинного интерфейса (HMI), которое использует вышеупомянутые библиотеки RTI-DDS вместе с двумя другими библиотеками, которые имеют такие ориентированные на сообщение архитектуры, которые действительно работали с потоком теперь для всех моих потребностей в общении в реальном времени. Вот демо: http://epics.codeplex.com/ (Он будет использоваться для удаленного управления оборудованием в нашем новом ядерном исследовательском центре)

Ответ 4

Чем больше допущений вы сделаете, тем больше возможностей вы сможете сделать. Чем более надежной и гибкой вы пытаетесь сделать вещи, тем больше пострадает ваша производительность. Я бы предложил несколько базовых вещей:

• Формат сериализации двоичных данных. Не используйте XML или любые другие читаемый способ передачи вашего данные.
• Достаточно прочные данные формат сериализации, который может поддержка кросс-архитектуры, межъязычные конечные точки. BER приходит to mind - У С# есть поддержка
• Транспортный протокол,   гарантированная доставка и данные   Целостность. Если какой-либо тип   финансовый алгоритм будет использовать   эти данные, даже отсутствие одного тика   может означать разницу между   и порядок запуска или отсутствия   по цене. Даже если вы   собирать агрегированные тики в вашем   сервер, который вы все еще хотите контролировать   как информация представляется   ваших клиентов. TCP работает для распределенных систем. Однако есть гораздо более быстрые альтернативы, если ваши клиенты находятся на том же компьютере, что и ваш сервер. UDP даже не будет предлагать порядок, что может быть проблематичным (хотя и не непреодолимым).

Что касается внутренней обработки:

• Избегайте строк и других классов, которые добавьте значительные накладные расходы к простым задания. Использовать основные массивы символов вместо. Я не уверен, какие варианты у вас есть на С#, или если у вас даже есть легкие альтернативы. Если это так, используйте их. Это также относится к структурам данных.
• Имейте в виду ошибки сравнения double/float. Используйте сравнения, которые проверяют только необходимый уровень точности. Если возможно, преобразовать все в целые числа внутри и предоставить достаточное количество метаданных для конвертирования обратно на другой конец.
• Используйте что-то похожее на объединенные распределители в С++. Отсутствие знаний о С# не позволяет мне быть более конкретным. Снова С#, вероятно, не ваш лучший выбор здесь. Суть в том, что вы собираетесь создавать и уничтожать множество объектов тика, и нет никаких оснований каждый раз спрашивать ОС о памяти.
• Отправлять только deltas, не отправлять информацию, которую уже есть у ваших клиентов. Предполагается, что вы используете транспорт с гарантированной доставкой. Если нет, вы можете в конечном итоге отображать устаревшие данные в течение длительного времени.

Ответ 5

Это может представлять интерес, хотя его специфический для игр... Протокол передачи данных с минимальными задержками в малом размере? С#

Вот учебник по подключению UDP http://www.winsocketdotnetworkprogramming.com/clientserversocketnetworkcommunication8r.html

Другая статья по UDP http://msdn.microsoft.com/en-us/magazine/cc163648.aspx

Ответ 6

Вы спрашиваете конкретно о "пользовательской ленте с низкой задержкой". Что вы действительно хотите с низкой задержкой, для "Feed Only" (и, особенно, если он не дает доход), пользователи могут ждать секунду; это не низкая латентность.

Если вы хотите торговать FAST, вам необходимо физически переместиться через улицу с Exchange (или рядом с оптической связью). Затем вам нужно "Торговля на карточке"; карта Ethernet является "умной" и получает "торговые формулы", которые программируют сетевую карту, чтобы сделать предварительно запрограммированную торговлю на основе полученных данных (без приставания к вашему компьютеру).

Смотрите: http://intelligenttradingtechnology.com/article/groundbreaking-results-high-performance-trading-fpga-and-x86-technologies

Учимся манипулировать этой средой, купив вам больше, чем изобретать колесо.

Сверхнизкая латентность стоит дорого, но на карту поставлены миллиарды; ваши ставки (и стремление к более низкой задержке) с дросселированием на $.

Ответ 7

В прошлом я использовал Tibco rv или сырые сокеты для потоковых цен/ставок, где ожидаются высокочастотные обновления. В этой ситуации часто клиент (или на самом деле пользователь) является ограничением (поскольку существует так много обновлений, которые может обрабатывать пользователь), и поэтому это пример того, где вы можете "потерять" данные. В этой ситуации брокер услуг клиентской стороны может использоваться для дросселирования обновлений.

Если система используется для автоматической торговли или HFT, то такие продукты, как 29West LatencyBuster, доказали свою эффективность и предлагают гарантированный обмен сообщениями.