@Why_oleg Еще вопрос. Вот у меня есть де факто два

встречно-направленных Flow, один из них в API сделан как подписка, другой как много раз единичный send. Я сейчас продублировал это как один sendAndForget и один requestStream. Но я только что подумал, что это можно было бы сделать при помощи заворачивания локальной отправки в callbackFlow и использования requestChannel. Будет ли так лучше? Как я понял как минимум будет менье установлений соединения

it depends сложно сказать, что удобнее зависит от того, насколько нужно знать, связаны ли это send или нет если важно знать, что это поток значений или нужен backbressure - то лучше requestChannel на счёт: > Как я понял как минимум будет менье установлений соединения соединение же будет всегда одно, просто будут слегка разные фреймы, по сути разницы нет

Точно не нужно. В смысле порядок. Он на уровне протокола вообще не регламентируется

Ну если я много раз fireAndForget делаю, то там вроде как должны быть какие-то накладные расходы

нет по сути 3 fireAndForget = 3 FAF frames requestChannel with 3 elements = 1 RC frame + 2 Payload frames единственный возможный оверхед это backpressure (RequestN) + с fireAndForget будет слегка проще наверно, если надо слать из разных мест кода а связаны ли эти send и результ requestStream?

Нет, не связаны. Канал выгляди лучше. Единственное, я не вижу, можно ли там параметры канала первым фреймом как-то передать.

параметры? просто в payload(data/metadata), если я понимаю, что Вам нужно

Ну в requestStream. есть первый фрейм, которым можно сообщить параметры и сингнатура Payload->Flow<Payload>. У requestChannel сигнатура Flow<Payload>->Flow<Payload>. Можно ли передать отдельный первый фрейм для конфигурации?

почему бы не послать его просто внутри flow? условно request: flow { emit(configurationPayload); .... other logic }

Ну можно, просто логика усложняется. Там тогда надо на той стороне тоже первый элемент отщеплять. Хорошо, я подумаю.

>Там тогда надо на той стороне тоже первый элемент отщеплять я сейчас тоже об этом думаю, как это сделать лучше, так как во flow не так просто отделить первый элемент, если flow single collectable есть 2 решения: 1. продьюсить в канал, взять первый элемент и сконвертировать обратно во flow этот канал - возможно, но не приятно 2. поменять сигнатуру requestChannel still WIP

А что с родым API?

родым? в плане клиента?

В плане жава/с++/whatever. Там есть отдельный пакет на конфигурацию каналов?

как где вроде

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

в java был отдельный тип для сервера с requestChannel(payload, flux) но потом его вроде выпилили, типа юзать операторы на flux

Просто если пакеты равноправны, не понятно, что будет при реконнекте

вообще, если смотреть в спеку, то для первого пакета можно устанавливать определённые metadata которые не нужны в остальных (типа routing)

что Вы подразумеваете под reconnect?

А можно меня не надо с большой буквы ( меня и на ты можно, я всем выкаю по привычке)? Ну вот если по каким-то причинам соединение дропнуто и идет переподключение. Как узнать что первый пакет именно первый?

можно и на ты, ок в данный момент, если соединение дропнет - то будет просто ошибка и в общем то всё, request failed, connection failed - надо создавать новое в 0.11.0 есть reconnectable - то там по сути тоже самое, но не будет connection failed - создастся новое подключение и новые запросы будут работать в спеке же есть resumability - которая сейчас перерабатывается и поэтому мы решили пока дождаться её релиза и тогда делать PS - resumability - пока вообще только java поддерживает на данный момент по старой спеке