Ждать ответа от отправленного сообщения? - PullRequest
0 голосов
/ 18 марта 2020

У меня возникли проблемы, когда я обдумываю следующую концепцию.

Я отправляю сообщения ОС C, чтобы запросить состояние приборов в Ableton, поэтому я продолжаю комбинировать эммитер / приемник. Дело в том, что я хотел бы избежать необходимости поддерживать какое-то глобальное состояние и оборачивать все вокруг этим. и я общаюсь с Ableto следующим образом:

sender.emit("/live/device", queryData);
receiver.on("/live/device", function(responseData){
// process response here...
})

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

То, что я хотел бы сделать, это просто

query number of instruments on ONE certain channel
get number back 
query parameters of each instrument of that channel based on first query
receive parameters back

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

Запрос данных и сохранение Обещания, которые должны быть разрешены с помощью eventListener, кажутся решением, но потом я застрял на том, как передать их обратно в последовательность.

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

1 Ответ

1 голос
/ 29 марта 2020

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

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

Вариант 1: Отправить контекст, получить его обратно

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

Вариант 2: выяснить данные результата, если они соответствуют вашему запросу

Если в полученных данных есть что-то Указав c для сопоставления, как ключи на JSON объекте, может быть возможно выяснить, что это был за запрос.

Вариант 3: Используйте состояние на своей стороне, чтобы отслеживать все

В большинстве случаев, когда я видел такие API, сервер не заботился о запросах и отправлял их текущее состояние, только если оно было изменено каким-либо запросом. Клиент должен реплицировать состояние сервера, прослушивая все события, если он хочет показать текущее состояние сервера.

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

...