Добавить поле subscriptionId в MarketDataStream

[vitalets]

Сейчас при работе с MarketDataStream не очень удобно сопоставлять запросы и ответы по разным подпискам. Например, если я создаю 2 подписки на свечи и приходит ответ со статусом != success, то чтобы понять, к какой подписке это относится приходится делать разные маневры с составным ключом figi + interval. Также при поступлении событий с данными было бы удобно понимать, к какой подписке это относится (чтобы вешать обработчики на конкретные инструменты, как это сделано у бинанс)

Предложение: Добавить в запрос подписки поле subscriptionId и возвращать его во всех событиях, связанных в этой подпиской:

// запрос подписки
{
  subscriptionId: 'xxx', // <-- идентификатор подписки
  subscribeCandlesRequest: { ... }
}

// результат подписки
{
  subscriptionId: 'xxx', // <-- идентификатор подписки
  subscribeCandlesResponse: { ... }
}

// данные по свече
{
  subscriptionId: 'xxx', // <-- идентификатор подписки
  candle: { ... }
}

[AlexanderVolkovTCS]

Добрый день, подскажите, а зачем вообще два раза подписываться на свечи по одному и тому же инструменту? Ведь из меньшего таймфрейма всегда можно сделать больший.

[vitalets]

Добрый день, подскажите, а зачем вообще два раза подписываться на свечи по одному и тому же инструменту? Ведь из меньшего таймфрейма всегда можно сделать больший.

Это уже другой вопрос, связанный с архитектурой конкретного клиента. Например, две независимые стратегии на разных интервалах. Каждая стратегия инкапсулированно управляет своей подпиской в стриме.

Дизайн API явно предполагает сущность подписки, которой вместо составного ключа нужно дать идентификатор, для четкого разделения подписок между собой. Уверен, это в будущем еще пригодится.

[vitalets]

Например, недавно добавился флаг waitingClose. Вопрос: как мне разделить response по следующим подпискам:

// подписка на figi с waitingClose: true
{
  subscribeCandlesResponse: { 
    instruments: [ { figi: 'xxx', interval: 1 } ],
    waitingClose: true
  }
}

// подписка на тот же figi с waitingClose: false
{
  subscribeCandlesResponse: { 
    instruments: [ { figi: 'xxx', interval: 1 } ],
    waitingClose: false
  }
}

[AlexanderVolkovTCS]

Идентификатор подписки добавим, спасибо.

Например, две независимые стратегии на разных интервалах ... Вопрос: как мне разделить response по следующим подпискам

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

[vitalets]

При такой архитектуре упремся в лимиты: если стратегий будет много, то стримов может не хватить

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

Если одна стратегия подписалась на бумагу, то другая в идеале не должна создавать новую подписку

Но если другая стратегия использует другой набор figi, она же не может вклинить свои фиги в существующую подписку, поэтому придется создавать новую.

Кстати интересно, а как вы сами на бэке разруливаете подписки? Например, у клиента две подписки, в каждой по несколько figi. И теперь клиент отписывается от одной из них. Как бэкенд понимает, какую именно подписку отменить? Так же собирает составной ключ из переданных figi? Или у вас есть внутренний id подписки?

[vitalets]

Идентификатор подписки добавим, спасибо.

Александр, может вместо subscriptionId сделать более общее поле requestId? Это позволит добавить requestId в запрос getMySubscriptions. Без этого поля возможен race condition, если вызвать одновременно getMySubscriptions и создание новой подписки: непонятно какой ответ какому запросу соответствует.

Да и requestId для bi-directional обмена данными привычная вещь, например как в JSON RPC.