Что нужно, чтобы связать платформу с чем-то ещё

Две формы интерфейса для разных задач

Программный интерфейс брокера обычно бывает двух форм. Одна отвечает на вопрос каждый раз, когда её спрашивают, и молчит в промежутках: запрос ушёл, ответ пришёл, и до следующего запроса больше ничего не известно. Другая держит соединение открытым и присылает обновления по мере их появления, так что сведения приходят без запроса.

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

У опроса есть пол, ниже которого он не опустится

Если запрашивать цену раз за разом вместо подписки на неё, картина никогда не будет свежее, чем промежуток между запросами. Вдвое меньший промежуток вдвое уменьшает устарелость и вдвое увеличивает число запросов, а есть черта, за которой брокер это число не примет. Значит, у актуальности опрашиваемой картины есть пол, и где он проходит, решает кто-то другой.

Это важнее, чем звучит, потому что устарелость путешествует дальше. Любое решение, любой показ, любое сравнение, сделанное по опрошенному числу, наследует возраст этого числа, не неся при этом ярлыка об этом. Система, которая опрашивает, а затем действует, действует по числу, возраст которого обычно нигде не записан.

Один лимит — обычно несколько лимитов

Лимит частоты — это предел на число запросов, которое счёт может отправить за период, и он редко бывает одним числом. Разные точки доступа считаются отдельно, и разрешённое на чтение цен обычно не равно разрешённому на отправку ордеров. Система, рассчитанная по щедрому лимиту, может получить отказ по строгому, причём в самый неудобный момент, потому что ордерный поток обычно сгущается ровно тогда же, когда и ценовой.

Какие лимиты действуют и как они считаются, задокументировано брокером, а не выясняется опытом. Искать стену на ощупь значит тратить отказы, чтобы узнать, где она стоит, — на живом счёте и в тот момент, на который придётся поиск.

Дорогой способ обработать отказ

Немедленный повтор ухудшает положение с лимитом, потому что повторы тоже считаются, и система, отвечающая на ограничение усиленными попытками, ограничивает себя ещё сильнее. Отступить, а не давить — вот и всё правильное поведение здесь, и оно неинтуитивно именно потому, что большинство других сбоев вознаграждает настойчивость.

Более серьёзная беда в том, что отказ не всегда отличим от других сбоев. Запрос, который истёк по времени на стороне клиента, мог быть получен и исполнен, и трактовка «нет ответа — значит, нет ордера» — это способ отправить один и тот же ордер дважды. Всё, что торгует через интерфейс, обязано сначала установить, что произошло на самом деле, перечитав счёт, и только потом действовать снова. Это другая операция, чем повтор, и именно она должна идти первой.

Поток, который открыт и молчит

Потоковая передача снимает пол опроса и взамен приносит собственную работу. Соединения рвутся, и их приходится восстанавливать. Обновления, пропущенные во время разрыва, надо откуда-то восстановить, а это обычно значит спросить у интерфейса другого вида текущее состояние, а не считать, что в пробеле ничего не было.

Трудный сбой — не тот и не другой. Это соединение, которое всё ещё открыто и перестало доставлять, и выглядит оно ровно как тихий рынок, потому что тихий рынок тоже ничего не доставляет. Разбор содержимого пришедшего их не разделит, ведь в обоих случаях ничего не пришло. Разделяет их время: возраст последнего сообщения, а не то, что в нём было. Программе, потребляющей поток, нужно нечто, что устаревает само и об этом заявляет, иначе она будет читать мёртвое соединение как спокойные условия ровно столько, сколько эти условия длятся.

Оповещение, отправленное на адрес, — это односторонняя связь

Оповещение по веб-адресу — это когда платформа отправляет сообщение на указанный вами адрес при выполнении условия, заданного на графике, вместо показа на экране или вдобавок к нему. Это обычный мост между анализом в одном месте и действием в другом, и его привлекательность очевидна: условие, выраженное на графике, становится входом для другой программы.

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

Адрес — это не учётные данные

Получатель никак не может определить, кто прислал ему запрос, если запрос этого не доказывает. Поэтому адрес — единственное, что стоит между оповещением и любым другим, кто этот адрес узнает, а адреса утекают самыми обычными путями: вставлены в обращение в поддержку, скопированы в общий документ, оставлены видимыми на снимке экрана.

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