Реализация API на вебсокетах

Я так и думал, что этим закончится.

чем закончится то? зачем в JSON RPC идентификаторы по вашему?

зачем в JSON RPC идентификаторы по вашему?

Ооо, в JSON-RPC есть идентификаторы запросов, кто бы мог подумать. Наверное, в Sun RPC их не было.

так зачем же они?

Ооо, микроскоп создан для забивания гвоздей, попробуйте опровергнуть что это не так!

Да, они именно затем. И?

микроскоп создан для забивания гвоздей, попробуйте опровергнуть что это не так!

Зачем? Я просто сделаю утверждение: микроскоп не был создан для забивания гвоздей. Согласен ты с эти или нет, меня не волнует.

они затем что ответ может следовать не после запроса и нам нужно ловить ответ по id, что это как не асинхронное выполнение?

Реализация API на вебсокетах (комментарий)

вы как раз делаете обратное утверждение, можете забивать, другие будут микроскоп использовать как микроскоп, а JSON RPC как асинхронный протокол

Прежде всего вся эта асинхроность нужна для backend

Это с какой стороны нужно смотреть? И какие из этого напрашиваются выводы? Не нужно?

Точно так же никаких проблем не составляет поставить запрос в очередь при обычном процедурном вызове.

REST подразумевает немедленный/синхронный ответ на только что пришедший запрос, без постановок в очередь, а JSON RPC подразумевает очередь и отложенный/асинхронный ответ

Я просто сделаю утверждение: микроскоп не был создан для забивания гвоздей. Согласен ты с эти или нет, меня не волнует.

вы как раз делаете обратное утверждение

Ты лжешь.

другие будут микроскоп использовать как микроскоп, а JSON RPC как асинхронный протокол

Не вопрос. Любой сетевой протокол можно использовать как асинхронный. Правда, он при этом перестает быть RPC: https://searchmicroservices.techtarget.com/definition/Remote-Procedure-Call-RPC

REST подразумевает немедленный/синхронный ответ на только что пришедший запрос, без постановок в очередь

Это не REST подразумевает, а лично ты. Ничто не мешает поставить REST-запрос в очередь (как оно всегда и делается).

Не нужно?

как раз нужно что и доказывает google с его gRPC

Ничто не мешает поставить REST-запрос в очередь (как оно всегда и делается).

«Ты лжешь.» Делается так только когда внедряют что-то типа JSON RPC/gRPC и делают временный wrapper для старых тупых клиентов.

Ничто не мешает поставить REST-запрос в очередь (как оно всегда и делается).

«Ты лжешь.

Нет. Ты просто плохо понимаешь, как работает сервер и ОС.

я чувствую до вашего уровня просветления мне еще слава богу далеко

я чувствую до вашего уровня просветления мне еще слава богу далеко

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

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

постараюсь держаться от него подальше и вести здоровый образ жизни. так для чего же в JSON RPC идентификаторы? ошибка в протоколе? шизофазия?

так для чего же в JSON RPC идентификаторы?

Полагаю, что для того же, что и XID-ы в Sun RPC.

Ссылку хоть почитай

Эту что ли? goo.gl/1WLn5q

Реализация API на вебсокетах (комментарий)

Ссылку хоть почитай

Эту что ли? goo.gl/1WLn5q

Полагаю, что для того же

Вообщем можете использовать асинхронный протокол как синхронный. Смысла дальше обсуждать это не вижу.

Не вопрос. Любой сетевой протокол можно использовать как асинхронный. Правда, он при этом перестает быть RPC

Пока ты это не написал то формально был прав, а вот теперь опустился на уровень анонимуса.

Не вопрос. Любой сетевой протокол можно использовать как асинхронный. Правда, он при этом перестает быть RPC

Пока ты это не написал то формально был прав

Формально, я и остался прав. Ну или объясни, в чем именно я перестал быть прав.

Любой сетевой протокол можно использовать как асинхронный.

Погугли синхронные сетевые протоколы. Убедись что некоторые нельзя использовать как асинхронные.

или (скорее в исключающем смысле)

Правда, он при этом перестает быть RPC

Не перестанет, достаточно найти пункт асинхронные вызовы в спеках на упомянутый тобой же Сан-РПЦ или же великую и ужасную КОБРУ. Лично я не помню чтобы РПЦ в общем смысле декларировал запрет на асинхронный вызов. По умолчанию блок вызывающего потока (спасибо буковкам ПЦ) вроде как подразумевается (неявно!), но если начать копать спеки на какие-либо реализации РПЦ, они таки довольно часто определяют асинхронные вызовы.

При чем если спеки некоторых протоколов явно запрещают асинхронщину, то в рпц таких явных запретов нет.

Погугли синхронные сетевые протоколы.

Гугл не выдает ничего релевантного. Назови имена протоколов.

Убедись что некоторые нельзя использовать как асинхронные.

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

Не перестанет, достаточно найти пункт асинхронные вызовы в спеках на упомянутый тобой же Сан-РПЦ

Что-то не нахожу. в https://tools.ietf.org/html/rfc5531 Но там есть:

«The caller first sends a call message to the server process and waits (blocks) for a reply message. The call message includes the procedure's parameters, and the reply message includes the procedure's results. Once the reply message is received, the results of the procedure are extracted, and the caller's execution is resumed.»

КОБРУ

Это типа шутка? КОРБА. Там асинхронные вызовы перестали быть процедурными вызовами, получающими аргументы и возвращающими значения, и стали постановкой запроса в очередь.

Назови имена

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

не нахожу

Прочитай 2 абзаца вниз. Там прямым текстом.

КОРБА

Она самая. Можешь погуглить ami for ccm. Они вроде бы везде называют это не procedure call а method invocation, но суть то не меняется.

Например sldc

А, понятно. Но это протоколы звена передачи данных, как тогда говорили. Не то, что понимается под сетвыми протоколами и не то, что я имел в виду.

Прочитай 2 абзаца вниз. Там прямым текстом.

Там сказано о реализации сервера.

Они вроде бы везде называют это не procedure call а method invocation, но суть то не меняется.

Суть меняется от того, что это перестало быть вызовом.

не то, что я имел в виду

Это то понятно, но разве от этого sldc перестал быть сетевым? И кстати анонимус то же не то имел в виду, говоря про асинхронный жсон-рпц.

реализации сервера

ладно процитирую

In this model, only one of the two processes is active at any given time. However, this model is only given as an example. The ONC RPC protocol makes no restrictions on the concurrency model implemented, and others are possible. For example, an implementation may choose to have RPC calls be asynchronous so that the client may do useful work while waiting for the reply from the server. Another possibility is to have the server create a separate task to process an incoming call so that the original server can be free to receive other requests.

Тут явным образом указано что извращения допустимы с обеих сторон.

перестало быть вызовом

Вики:

In computing, the Java Remote Method Invocation (Java RMI) is a Java API that performs remote method invocation, the object-oriented equivalent of remote procedure calls (RPC)

Ну блин, ну назвали иначе, т.к. у них там кроме методов ещё и объекты можно проталкивать. Суть то не поменялась.

Это то понятно, но разве от этого sldc перестал быть сетевым?

SDLC. Он никогда и не был сетевым. Это протокол звена передачи данных.

Тут явным образом указано что извращения допустимы с обеих сторон.

Реализация API на вебсокетах (комментарий)

the Java Remote Method Invocation (Java RMI) is a Java API that performs remote method invocation, the object-oriented equivalent of remote procedure calls (RPC)
Ну блин, ну назвали иначе

Я не знаком с RMI. А причем он здесь? Мое «перестало быть вызовом» относилось к CORBA.

Кобра это рми, рми это такой рпц с объектами. Поэтому в доках вместо пц написано ми, хотя фактически разговор о пц. Таки я не понял почему у тебя кобра не рпц?

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

я этот наводящий вопрос еще до него задавал. логика должна была подсказать для того чтобы знать на какой запрос пришел ответ. а так верно большинство реализаций rpc(поверх хттп) синхронны, там даже есть отстуления от стандарта когда не нужен айдишник запроса. никто и не запрещает свою реализацию сделать. для питона, например, удобно использовать что-то типа {«method»:"...",«args»:[],«kwargs»:{}}. а так да у моего способа много недостатков. основной, что пхпмакаки не смогут сделать клиента для работы с моей апишкой.

Кобра это рми

Кобра - это змея. Я знаю, что такое CORBA, но практически ничего не знаю об RMI. Аругменты об RMI я не понимаю.

Поясни как синхронность процедурного вызова влияет на синхронность протокола?

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

Аругменты об RMI я не понимаю.

Ладно отложим рми в сторону. Смотрим спеки на разные рпц, без рми.

RPC - это способ использования протокола. Протокол может быть любым.

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

ЗЫ, я прекрасно понимаю чем именно ты тролил анонимуса, но блин не стоит настолько увлекаться.

но тогда не ясно что ты имеешь против асинхронного рпц?

Приведи определение «асинхронного RPC». Если не общепринятое, то хотя бы то, которым ты пользуешься.

Рпц это абстрактная логика взаимодействия компонентов через сеть.

Эта «абстрактная логика» включает в себя _вызов_ - т.е. неделимую операцию передачи аргументов и возврата результатов. Неделимую с точки зрения пользователя RPC - «под капотом» может быть что угодно.

P.S. и кто такой анонимус, которого я троллил - регистрант, известный как «Царь»?

Эта «абстрактная логика» включает в себя _вызов_ - т.е. неделимую операцию передачи аргументов и возврата результатов.

Кажется нашёл камень преткновения. Если я при вызове метода (локального) верну не результат а указатель но место, где он через некоторое время появится ты будешь считать это вызовом или уже нет?

регистрант, известный как «Царь»?

Я думал quester это anoninous, попутал значит.

Если я при вызове метода (локального) верну не результат а указатель но место, где он через некоторое время появится ты будешь считать это вызовом или уже нет?

Нет, потому что вызов еше не завершен (и нельзя просто вернуть «указатель на место», но это техническая деталь).

вызов еше не завершен

Ага, а когда результат известен и он появится в указанном месте это вызов?

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

без усилий со стороны пользователя - это вызов, иначе это обмен сообщениями

В смысле усилий со стороны пользователя? Если апи/фрейморк/компилятор скрывает от пользователя ожидание появления данных это вызов?

поверх которого, естественно, может быть реализован вызов

Значит всё таки вызов?

В смысле усилий со стороны пользователя? Если апи/фрейморк/компилятор скрывает от пользователя ожидание появления данных это вызов?

Для пользователя - да, это вызов.

поверх которого, естественно, может быть реализован вызов

Значит всё таки вызов?

Нет.

Нет

классная аватарка

Считаешь ли ты достаточным для сохранения названия рпц чтобы вызов был «вызовом для пользователя»?