Разбираемся в тонкостях протоколов самодиагностики

Изучаю FIX протокол с нуля. Разбор протокола, первый код на c#

Вступление

Никогда не увлекался скоростным трейдингом. Всегда хватало терминала. Изучать этот протокол меня побудил набор вакансий. Надо отметить, что я неспешно перебираю хорошие вакансии на рынке. Частному трейдеру очень сложно развиваться в одиночку — психологически, эмоционально, физически. Создавать и развиваться постоянно хочется, поэтому принял решение вливаться в коллектив. За несколько месяцев, мне удалось провести несколько собеседований. На втором этапе я проваливался именно из за не знаний протокола. Предметную область я примерно представлял. Ну что там сложного? Соединился с биржей по сокетам и начинай обмен сообщениями. Надо отметить, что в этой области есть уже готовые разработки в виде quickfix или готового API от StockSharp (правда платные). Но я принял решение разбираться с нуля, чтобы вникнуть в детали.

Технические аспекты протокола

Организационные вопросы

1. Наша биржа дает тестовый контур для отработки своих алгоритмов по данному протоколу. Надо всего лишь написать запрос на доступ. Надо признать, тех служба работает отменно. Очень все быстро было организовано. Подробности http://moex.com/s442
2. Обязательно понадобится описание протокола для нашей биржи ftp://ftp.moex.com/pub/FIX/Spectra/test/docs/spectra_fixgate_ru.pdf
3. Чтобы вникнуть в тонкости передачи, мне очень помогла эта программа от биржи (позже я покажу как помогла) ftp://ftp.moex.com/pub/FIX/Spectra/Utils/fix_client.zip
4. Описание самого протокола от создателей (на английском). Мне помог сильно wiki. http://fixwiki.org/fixwiki/FIXwiki
5. Чтобы найти свои ошибки, мне приходилось перехватывать сообщения рабочего клиента биржи и сверять со своими. Для этого мне понадобился tcp/ip сниффер — программа перехвата сетевого трафика.
6. Разработку я веду на c#.

К бою. Немного теоретической практики

Если говорить образно. То, чтобы отправить сообщение на сервер, нам просто нужно сформировать нужную строку со всеми данными и отправить ее на биржу. Ну например:

8=FIX.4.4 ; 9=78 ; 35=A ; 49=FG ; 56=tgFhcfx901U05 ; 34=1 ; 52=20160212-11:42:51.812 ; 98=0 ; 108=30 00 ; 141=Y ; 10=047 ;

Если быть внимательным, то мы увидим, что кол-во символов в строке у нас 100, а в заголовке сообщения мы передаем, что 78 (9 = 78). По правилам протокола FIX, длину сообщения нужно считать без учета концовки и первых двух полей заголовка. А именно:

С длиной сообщения разобрались. Теперь про разделитель. Пока в моем скрине это “;”. В документациях западных написано что это символ SOH. Чтобы однозначно ответить на этот вопрос, я запустил прилагаемого клиента биржи и сниффером стал перехватывать сообщения между клиентом и биржей. Кстати, программа ведет логи, и их общение выглядит так (зеленое — передача запроса на биржу, красное — ответ от биржи):

Зачеркнул свой идентификатор, прошу понять правильно. Ну а перехват сообщения выглядит так:
Зеленым я отметил именно разделители. Как вы уже видите, это просто в шестнадцатеричном виде код 01. То есть, в нашу строку в виде разделителей, нужно вставлять код 01. Также я отметил для себя последовательность полей в сообщении. Почему то в другом порядке у меня вызывало ошибки (возможно тут я не прав)
Ну и контрольная сумма. Контрольная сумма считается над всем сообщением, за исключением концовки. То есть в расчет берется только заголовок и само сообщение. Для этого, мы переводим каждый символ в его Ascii код и вычисляем их сумму. Полученную сумму делим по модулю 256. Это и будет контрольной суммой сообщения. При этом, значение должно быть трехзначным. Если мы получаем 2 знака, то подставляем 0 слева (например, если контрольная сумма = 68, то должны передать значении 068).

К бою. Начало программирования

В законченном виде, разработка будет составлять готовый класс, для работы с протоколом. Теперь начинаю строить его по кирпичикам. Для начала, я создал несколько классов:

• класс для работы с заголовками
• класс для работы с сообщением подключения к серверу (onLogon)
• класс для работы с концовкой

Каждый класс включает в себя поля, которые передаются и некоторые методы для их обработки.
Класс для работы с заголовками. Пока просто выглядит так:

Как видим, первый метод строит нужную строку из полей. Обратите внимание, там присутствует наш разделитель в виде спец символа u0001. Второй метод вычисляет размер заголовка (чтобы потом высчитывать размер сообщения). Надо обратить внимание, что при передачи времени, миллисекунды должны указываться в трехзначном формате (даже если миллисекунды = 52, то передаем 052). Следующие классы строятся по аналогии.
Класс создания сообщения на подключение (инициализация сессии)

Класс создания концовки сообщения

Попробую привести код консольной программы для теста в виде цитаты. Картинки вставляются плохого качества. Подробно комментирую.

//Получаем ip сервера
IPAddress ipAddr = IPAddress.Parse(server);
IPEndPoint ipEndPoint = new IPEndPoint(ipAddr, port);
//Создаем заголовк
HeaderMessage msHeader = new HeaderMessage
<
BeginString = «FIX.4.4»,
MsgType = «A», //Тип сообщения на установку сессии
SenderComp ,
TargetComp > MsgSeqNum = 1
>;
//Создаем сообщение на подключение onLogon
LogonMessage msLogon = new LogonMessage
<
EncryptMethod = 0,
HeartBtInt = 3000,
ResetSeqNumFlag = true
>;

//Вычисляем длину сообщения
msHeader.BodyLength = msHeader.GetHeaderSize() + msLogon.GetMessageSize();
//Создаем концовку сообщения
TrailerMessage msTrailer = new TrailerMessage(msHeader.ToString() + msLogon.ToString());

//Формируем полное готовое сообщение
string fullMessage = msHeader.ToString() + msLogon.ToString() + msTrailer.ToString();
Console.WriteLine(«Сообщение для отправки <0>»,fullMessage);

//Создаем сокет для подключения
sSender = new Socket(ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
//Подключаемся
sSender.Connect(ipEndPoint);
Console.WriteLine(«Сокет соединился с <0>», sSender.RemoteEndPoint.ToString());

byte[] msg = Encoding.UTF8.GetBytes(fullMessage);
//Отправляем сообщение
int bytesSent = sSender.Send(msg);
Console.WriteLine(«Отправил <0>байт», bytesSent.ToString());

//Получаем ответ от сервера
byte[] bytes = new byte[1024];
int bytesRec = 0;
bytesRec = sSender.Receive(bytes);
Console.WriteLine(«Ответ от сервера: <0>», Encoding.UTF8.GetString(bytes, 0, bytesRec));

Все таки приложу и в виде картинок. Так наглядней. Кликабельно.


В результате мы запросили у сервера подключение с нашим логином. И получили от него ответ.

По мере развития, буду продолжать с теоретической частью. Если модераторы перенесут в раздел «Алго», я не против.

Самодиагностика автомобиля: особенности считывания кодов, принцип работы

Усталость от «корявых» рук горе-мастеров на СТО уже настолько накопилась в обществе, что создание современных систем стало глотком свежего воздуха. Точное определение неисправности путем компьютерной диагностики делает возможным быстрый, а главное – эффективный ремонт транспортного средства. Кроме этого, в современных машинах на выручку приходят так называемые системы самодиагностики. Их задача – своевременное информирование водители об имеющихся неполадках в системе и необходимости принимать срочные меры.

Check Engine

Речь идет, конечно же, об индикаторе Check Engine, который для многих автолюбителей стал символом надежности. Любая критическая неисправность тут же фиксируется системой, и водитель видит сигнал на панели приборов. Подобные системы были и раньше, но они принимали вид обычных светодиодов, которые располагались прямо на устройствах управления.

Полная диагностика производится в процессе завода двигателя. Если тест прошел нормально – лампочка контроля гаснет. В случае обнаружения проблем – остается гореть. Если неисправность проявляется во время движения, то индикатор обязательно загорается и сигнализирует водителю о необходимости принимать меры. Иногда, если проблема самоустранилась, индикатор гаснет самостоятельно, но ошибка в памяти сохраняется. При этом желательно не затягивать с посещением СТО, ведь проблема может проявиться в самый непредсказуемый момент. В дальнейшем может понадобиться более детальная компьютерная диагностика.

Особенности систем самодиагностики

Все системы самодиагностики на автомобилях имеют одинаковый принцип действия (хотя конструктивно может отличаться). Есть блок управления, в задачу которого входит считывание основных параметров с датчика автомобиля (причем в разных режимах работы – во время пуска, на холостом ходу, в период прогрева, торможения и так далее).

Показания датчиков различаются – они бывают динамическими, то есть меняющимися во времени (контроль происходит в режиме онлайн) или статическими (дискретными). У статических показаний есть пороговое значение – сигнал определенного уровня. Что касается динамических показаний, то они передают действующий параметр, надежно контролируя его по верхнему и нижнему диапазону. Какой бы ни была диагностическая система, она обязательно сохраняет коды ошибок и выдает их при необходимости.

Работа системы самодиагностики во многом зависит от упомянутых выше показаний датчиков. Если они дискретные, то реакция системы происходит только на отсутствие электрического контакта, то есть водитель получает сигнал о неисправности контролирующего органа. Сверка динамических показателей происходит по другому принципу – с учетом таблиц, которые хранятся в памяти устройства. Но по сути, любой из датчиков в процессе работы проверяется, как на пределы измерения, так и на качество электрического контакта. В противном случае самодиагностика автомобиля была бы далеко не полной. При этом ошибка может иметь два основных вида – отсутствие сигнала от датчика или же выход за конкретно заданные параметры.

Состав системы и особенности фиксации событий

В состав системы управления зачастую входит несколько основных блоков: для мотора – Engine Control Module (в некоторых машинах – Engine Control Unit), для подушек безопасности транспортного средства – Air Bag Supplemental Restraint System (сокращенно SRS), для коробки-автомат – Electronic Automatic Transaxles, для антиблокировочной системы – ABS и так далее. Как видим, каждая система и жизненно важный узел автомобиля находится под полным контролем.

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

Накопленные за время эксплуатации коды ошибок можно в любой момент считать при помощи специального прибора – сканера. Часто данная работа делается вручную. Для этого достаточно перевести систему в режим указания кодов самодиагностики. Полученные данные анализируются, и принимается решение по дальнейшим мероприятиям – ремонту конкретного узла или проведении дополнительной компьютерной диагностики.

Стоит отметить, что ряд важных параметров двигателя не всегда фиксируется системой самодиагностики. Даже считывание кодов не дает возможности четко диагностировать неисправность и приняться за ее устранение. Да и сам автомобиль – очень сложное устройство, состоящее из многочисленных узлов, работа каждого из которых зависит от целого ряда параметров. В итоге небольшая проблема может привести к «высыпанию» множества кодов, которые не смогут четко дать ответ на причину проблемы.

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

Многие автомобильные компьютеры способны фиксировать в памяти информацию от датчиков даже в нормальном режиме работы. Такая информация используется для дальнейшего улучшения эксплуатационных характеристик и повышения работоспособности устройства. Если обнулить систему, то упор делается на показатели, внесенные производителем по умолчанию. Через время компьютер снова набирает необходимые параметры и продолжает контролировать процесс. Не стоит удивляться, если во время «переобучения» системы самодиагностики возникают легкие перебои в работе авто, к примеру, повышается расход топлива или появляется некоторая нестабильность в холостых оборотах. Не стоит переживать, данные симптомы быстро уходят (через 30-50 км), как только компьютер запомнит несколько циклов вождения

Вывод

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

Бекап iCloud: разбираемся в тонкостях

В связи с недавним окончанием бонусной программы Apple для бывших подписчиков сервиса MobileMe, всё вернулось на свои места — теперь каждому подписчику iCloud бесплатно доступны стандартные 5 гигабайт на серверах компании. Многие задаются вопросом: стоит ли платить за расширение доступного пространства для резервного копирования? Или можно обойтись тем, что предоставляется по умолчанию?

Каждый может узнать текущее состояние и настройки своих резервных копий, перейдя в раздел «Настройки» — «iCloud» — «Хранилище и копии» — «Хранилище» (да, вот именно из-за такого перевода я пользуюсь английским языком интерфейса, но для статьи переключился на русский), здесь видна вся информация об аккаунте: общий объём, сколько места доступно, как много занимают данные каждого приложения, включая онлайн-версии документов iWork, а также электронная почта iCloud.

На скриншоте моего iPhone 5 с 16 гигабайтами встроенной памяти видно, что резервная копия занимает всего 2 гигабайта, хотя мой аппарат наполовину забит музыкой. Видимые тут данные могут привести к путанице, поэтому многие интересуются — где же хранится вся информация, понимая процесс так, что в iCloud переносятся все или большая часть информации с устройства.

На сайте Apple есть страница поддержки, объясняющая, какая информация сохраняется в процессе создания резервной копии iCloud:

• Приобретенная вами музыка, фильмы, телешоу, приложения и книги (доступно только в СШA)
• Фотографии и видео из альбома «Фотопленка»
• Настройки устройств
• Данные приложений
• Вид главного экрана и порядок расположения приложений
• iMessage, текстовые сообщения (SMS-сообщения) и MMS-сообщения
• Рингтоны
• Сообщения визуальной голосовой почты

Необходимо понимать, что в вашей резервной копии iCloud хранится только информация о приобретённых вами приложениях, музыке, видео и прочем контенте, который вы приобрели с помощью учётной записи iTunes, а не само содержание приобретённого, по сути это просто ссылки. При процессе восстановления всё это загружается из iTunes Store, App Store, iBookstore, документы из онлайн-хранилища iWork. Некоторые предыдущие покупки могут быть недоступны, это происходит в том случае, если они удалены из сервисов iTunes на момент восстановления устройства из резервной копии, уведомления о таких покупках появятся в процессе.

Как видно, больше всего места в облаке iCloud занимают фото и видео из «Фотоплёнки». Перенеся фотографии на компьютер или выгрузив их в альтернативный сервис хранения (есть очень удобные Flickr и Dropbox), можно отключить резервное копирование содержимого «Фотоплёнки» в iCloud. Более того, для экономии пространства на устройстве можно полностью выключить «Фотопоток» в настройках («Настройки» — «iCloud» — «Фото» — «Мой фотопоток»). Также в настройках резервной копии можно управлять резервированием данных приложений, включая и выключая соответствующие пункты.

Таким образом можно освободить место в iCloud без покупки дополнительного пространства. Это актуально в том случае, если вы часто пользуетесь документами iWork, книгами в PDF-формате, и предпочитаете сохранять их в iCloud для синхронизации между устройствами и совместной работы. По большей части, если вы не используете iPhone как фотокамеру и не получаете в день сотни писем в почтовый ящик iCloud, стандартных 5 гигабайт вполне достаточно для резервного копирования пары-тройки устройств в пределах одной учётной записи.