История изменений

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

Асинхронный вариант пилить вообще не вижу смысла

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

Не проще сразу придумать асинхронный RPC, который по сути обмен сообщениями, и клиент будет сам проверять наличие ответа в подходящий клиенту момент, не дергая сервер на предмет готовности задания (которое еще надо будет как-то идентифицировать отдельно от клиента и сервера) ?

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

Пока у тебя всё внутри программы, то и нет накладных расходов на обмен информацией, т.к. по сути ты просто построил цепочку вызовов через калбэки клиента и сервера. Тут вопросов нет, кроме опасности принципа калбэка (на момент вызова обработчика, внешние переменные, используемые обработчиком калбэка могут быть не актуальны).

Сервера же пишут для однотипной обработки RPC запросов от множества клиентов и там время передачи и загруженность сервера будет иметь значение.

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

Асинхронный вариант пилить вообще не вижу смысла

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

Не проще сразу придумать асинхронный RPC, который по сути обмен сообщениями, и клиент будет сам проверять наличие ответа в подходящий клиенту момент, не дергая сервер на предмет готовности задания (которое еще надо будет как-то идентифицировать отдельно от клиента и сервера) ?

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

Пока у тебя всё внутри программы, то и нет накладных расходов на обмен информацией, т.к. по сути ты просто построил цепочку вызовов через калбэки клиента и сервера. Тут вопросов нет, кроме опасности принципа калбэка (на момент вызова обработчика, переменные, используемые внутри обработчика калбэка могут быть не актуальны).

Сервера же пишут для однотипной обработки RPC запросов от множества клиентов и там время передачи и загруженность сервера будет иметь значение.

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

Асинхронный вариант пилить вообще не вижу смысла

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

Не проще сразу придумать асинхронный RPC, который по сути обмен сообщениями, и клиент будет сам проверять наличие ответа в подходящий клиенту момент, не дергая сервер на предмет готовности задания (которое еще надо будет как-то идентифицировать отдельно от клиента и сервера) ?

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

Пока у тебя всё внутри программы, то и нет накладных расходов на обмен информацией, т.к. по сути ты просто построил цепочку вызовов через калбэки клиента и сервера. Тут вопросов нет, кроме опасности принципа калбэка (на монет вызова, переменные, используемые внутри обработчика калбэка могут быть не актуальны).

Сервера же пишут для однотипной обработки RPC запросов от множества клиентов и там время передачи и загруженность сервера будет иметь значение.

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

Асинхронный вариант пилить вообще не вижу смысла

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

Не проще сразу придумать асинхронный RPC, который по сути обмен сообщениями, и клиент будет сам проверять наличие ответа в подходящий клиенту момент, не дергая сервер на предмет готовности задания (которое еще надо будет как-то идентифицировать отдельно от клиента и сервера) ?

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

Пока у тебя всё внутри программы, то и нет накладных расходов на обмен информацией, т.к. по сути ты просто построил цепочку вызовов через калбэки клиента и сервера. Тут вопросов нет, кроме опасности принципа калбэка (на монет вызова, переменные, используемые внутри обработчика калбэка могут быть не актуальны).

Сервера же пишут для однотипной обработки RPC запросов от множества клиентов и там время передачи и загруженность сервера будет иметь значение.