Здравствуйте, Аноним, Вы писали:

А>Вообще, идея про "сообщения с сервера как удаленный вызов методов" просто гениальна. Она на несколько порядоков мощнее и проще в использовании, чем традиционный "гуманитарный" подход, когда сообщения вручную по отдельности составляются человеком.

Обычно RPC предполагает синхронный вызов. Т.е., то, что выглядит, как вызов процедуры, превращается в отправку запроса и ожидание ответа.

Теперь представьте себе, у вас один компутер в Москве, а другой — в Калифорнии. Типичный round-trip-time — 200 миллисекунд. 5 вызовов — секунда. А вот если бы вы могли отправлять данные, не дожидаясь ответа, ваши 5 запросов мгновенно бы пролетели. И даже 50 пролетели бы быстро, каналы-то сейчас у всех широкие, проблема именно в задержке, а не ширине канала. И никуда эта задержка по мере развития технологии не денется, скорость света-то конечна.

Конечно, бывает и асинхронный RPC. Только его интерфейс уже не выглядит, как "просто позвать функцию".

Здравствуйте, sorc, Вы писали:

S>Это как-то больше похоже на удалённый вызов методов и конструкторов. По-моему этот подход намного проще даже в реализации не говоря уже об использовании. Но все в один голос говорят что это не правильно и первый вариант лучше Рассуди нас RSDN.

ООП идет в …
Во-первых, канал у тебя не резиновый.
Во-вторых, не городи сущности там, где они не нужны.

ИТОГО: твои коллеги правы.

Здравствуйте, Аноним, Вы писали:

А>Вообще, идея про "сообщения с сервера как удаленный вызов методов" просто гениальна. Она на несколько порядоков мощнее и проще в использовании, чем традиционный "гуманитарный" подход, когда сообщения вручную по отдельности составляются человеком.

А>Да что там, я первый подход считаю просто тупым. И использовать его можно только от плохой жизни, когда надо считать каждый байт, в программе проблемы с рефлексией (метаданными) или просто не додумались до лучшего решения.

Вообще-то, на эту тему буржуи наваяли ряд дисеров и вся их суть сводится к тому, что RPC это не есть хорошо. На основании этих исследований и было реализовано, например, разделение на локальные/удалённые интерфейсы в EJB, асинхронный messaging в Erlang. И ни ООП ни рефлексия тут не причем. А при чем — фундаментальная разница между локальным и удалённым вызовом.

Вывод — коллеги топикстартера правы, а топикстартер — нет.

Здравствуйте, sorc, Вы писали:

На мой взгляд, второй подход универсальнее, конструктивнее, автоматизированнее и проще в реализации и использовании. Так что он безусловно лучше.

Вообще, идея про "сообщения с сервера как удаленный вызов методов" просто гениальна. Она на несколько порядоков мощнее и проще в использовании, чем традиционный "гуманитарный" подход, когда сообщения вручную по отдельности составляются человеком.

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

Доводы про "ширину канала" не прокатывают, так как в любом случае это количество информации слишком ничтожно, чтобы на что-то влиять, да и сжатие никто не отменял.

А твои коллеги просто мыслят стереотипами и предрассудками. Это вообще очень раздражающее качество у людей в целом.

Постарайся убедить коллег, с косностью мышления надо бороться.

Всем привет.

Возник такой спор. Сейчас попробую передать его суть. Начну из далека. Вспомните как вы пишите свои программы в стиле ООП. Создаёте классы, вызываете методы. Одни части программы (одни объекты) общаются с другими с помощью сообщений (вызовов методов). Не так давно придумали сериализацию и удалённый вызов процедур, всякие там .net remoting и прочее, чтобы сделать общение между удалёнными частями одной программной системы более естественным: вы как бы вызываете методы и создаёте классы в другой части программной системы, которая может находиться даже на другом конце планеты, через интернет или локальную сеть предприятия. Я всегда был уверен что этот подход правильный, потому что он ведёт к унификации интерфейсов, в конце концов упрощает работу программиста да и надёжность системы возрастает от того, что уменьшается количество преобразований данных из одного формата в другой.

Но сегодня мне просто порвали все шаблоны. Оказалось что то что я выше написал чуждо всем людям с которым я всё это время общался Суть драмы в следующем. Для уведомления клиента игровым сервером о появлении нового игрока или NPC, либо об изменении их атрибутов (в случае если клиент уже знает о существовании данного игрока или NPC) было предложено такое сообщение (json):

["UNITSTATUS",{"type":"PLAYER","unit":{"id":"35","name":"test","i":"5","j":"1","speed":"13"}}]

Собственно тип type может быть PLAYER, если речи идёт об игроке, или NPC, если об NPC. Набор атрибутов в unit может немного меняться в зависимости от типа.

Я уже успел привыкнуть к тому, что сообщения с сервера это как вызовы методов или конструкторов на клиенте, по типу rpc или ремотинга. Поэтому предложил свой вариант. Заменить это сообщение, которое делает 4 дела (создаёт игрока, создаёт нпц, меняет атрибуты игрока, меняет атрибуты нпц) несколькими сообщениями, каждое из которых будет делать одно осмысленное действие:

["NEWPLAYER",{"id":"35","name":"test","i":"5","j":"1","speed":"13"}]    // Если получится так что конструкторы у игрока и NPC одинаковые
["NEWNPC",{"id":"36","name":"test","i":"5","j":"1","speed":"5"}]        // то можно сделать одно сообщение NEWUNIT с указанием типа юнита.
["MOVEPLAYER",{"id":"35","i":"5","j":"1","speed":"13"}}]    // Можно было бы сделать одно сообщение MOVEUNIT и для игроков и для 
["MOVENPC",{"id":"36","i":"5","j":"1","speed":"5"}}]        // NPC если бы id у них были уникальные =\
["SETPLAYERSPEED",{"id":"36","speed":"5"}}]
...

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

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, sorc, Вы писали:

S>>Это как-то больше похоже на удалённый вызов методов и конструкторов. По-моему этот подход намного проще даже в реализации не говоря уже об использовании. Но все в один голос говорят что это не правильно и первый вариант лучше Рассуди нас RSDN.

KP>ООП идет в …
KP>Во-первых, канал у тебя не резиновый.
KP>Во-вторых, не городи сущности там, где они не нужны.

KP>ИТОГО: твои коллеги правы.

Ну да, а RPC, .NET Remoting, Serialization и даже ORM не нужны.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Вообще-то, на эту тему буржуи наваяли ряд дисеров и вся их суть сводится к тому, что RPC это не есть хорошо. На основании этих исследований и было реализовано, например, разделение на локальные/удалённые интерфейсы в EJB, асинхронный messaging в Erlang. И ни ООП ни рефлексия тут не причем. А при чем — фундаментальная разница между локальным и удалённым вызовом.

ANS>Вывод — коллеги топикстартера правы, а топикстартер — нет.

Что-то non sequitur. Можно примерно меня ориентировать на работы, или объяснить хотя бы почему именно это не есть хорошо, и в чем заключается "фундаментальная разница"?

Здравствуйте, Sorc17, Вы писали:

Sorc17 и sorc — это один и тот же человек или два разных?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Sorc17, Вы писали:

А>Sorc17 и sorc — это один и тот же человек или два разных?

Один и тот же, просто я случайно вспомнил логин и пароль от моего предыдущего аккаунта.

Здравствуйте, sorc, Вы писали:

S>Но все в один голос говорят что это не правильно и первый вариант лучше

И они правы, при первом подходе транзакционность и идемпотентность забесплатно идет. Это очень полезное качество в распределенной среде.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Обычно RPC предполагает синхронный вызов. Т.е., то, что выглядит, как вызов процедуры, превращается в отправку запроса и ожидание ответа.

Что вы со своим "RPC"? Я говорил про RPC? Делать такое синхронно может только безумный человек. Я вообще с сетью никогда синхронно не работаю.

Pzz>Конечно, бывает и асинхронный RPC. Только его интерфейс уже не выглядит, как "просто позвать функцию".

Он не выглядит как "просто позвать функцию", но и не сильно отличается.

Честно говоря, у меня уже есть такие успешно используемые реализации, и все там отлично.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, sorc, Вы писали:

S>>Но все в один голос говорят что это не правильно и первый вариант лучше

G>И они правы, при первом подходе транзакционность и идемпотентность забесплатно идет. Это очень полезное качество в распределенной среде.

G>Представь что ты с RPC интерфейсом делаешь последовательность вызовов удаленных методов, потом происходит ошибка и тебе надо откатить все что было сделано. Или еще хуже: отправили запрос еще не получили ответа и порвалась связь.

Если я правильно понял ТС, то весь сыр-бор исключительно из-за способа оформления — завести для каждого сообщения отдельное имя или на всех использовать одно имя + тип (и разный набор атрибутов, в зависимости от типа).
Т.е. тут RPC и транзакции ортогональны.

Какой способ предпочесть — зависит от реализации парсера и характера команд. Надо смотреть по месту.
А проблема актуальна и для сетей, и для файловых форматов.

Здравствуйте, sorc, Вы писали:

S>Всем привет.

S>Это как-то больше похоже на удалённый вызов методов и конструкторов. По-моему этот подход намного проще даже в реализации не говоря уже об использовании. Но все в один голос говорят что это не правильно и первый вариант лучше Рассуди нас RSDN.

Оба правильные. Только первый для отправления команд, изменяющих модель данных.
А второй — для рассылки сообщений об изменении модели. Первый обычно используется
от клиента к серверу. Второй — от сервера к клиентам, с тем, чтобы все клиенты
могли построить в своей памяти одинаковую картину данных.

Здравствуйте, sorc, Вы писали:

S>...
S>Это как-то больше похоже на удалённый вызов методов и конструкторов. По-моему этот подход намного проще даже в реализации не говоря уже об использовании. Но все в один голос говорят что это не правильно и первый вариант лучше Рассуди нас RSDN.

Правильно, не правильно.. Лучше, хуже.. "Ноги. Крылья. Главное хвост!"

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

а) Сетевые вызовы дорогие и медленные, поэтому их кол-во надо минимизировать, а это можно достичь упаковкой (предположим, что речь об HTTP, тогда там есть gzip/deflate) и композицией разнородных данных, что вполне в стиле json. Передавать нужно только то, что нужно, без избыточности.

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, sorc, Вы писали:

S>>>Но все в один голос говорят что это не правильно и первый вариант лучше

G>>И они правы, при первом подходе транзакционность и идемпотентность забесплатно идет. Это очень полезное качество в распределенной среде.

G>>Представь что ты с RPC интерфейсом делаешь последовательность вызовов удаленных методов, потом происходит ошибка и тебе надо откатить все что было сделано. Или еще хуже: отправили запрос еще не получили ответа и порвалась связь.

SVZ>Если я правильно понял ТС, то весь сыр-бор исключительно из-за способа оформления — завести для каждого сообщения отдельное имя или на всех использовать одно имя + тип (и разный набор атрибутов, в зависимости от типа).
SVZ>Т.е. тут RPC и транзакции ортогональны.

В теории да, а на практике — нет. Попробуй на досуге сделать транзакционность RPC без использования готовых средств вроде WS-Transaction.

Вообще говоря многие (в том числе ты) недооценивают трензакционность и идемпотентность в распределенной среде.
Это потом выливается в довольно неэффективные методы работы.

SVZ>Какой способ предпочесть — зависит от реализации парсера и характера команд. Надо смотреть по месту.
SVZ>А проблема актуальна и для сетей, и для файловых форматов.
Это как раз фигня, ибо XML или JSON.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Вообще-то, на эту тему буржуи наваяли ряд дисеров и вся их суть сводится к тому, что RPC это не есть хорошо. На основании этих исследований и было реализовано, например, разделение на локальные/удалённые интерфейсы в EJB, асинхронный messaging в Erlang. И ни ООП ни рефлексия тут не причем. А при чем — фундаментальная разница между локальным и удалённым вызовом.

ANS>>Вывод — коллеги топикстартера правы, а топикстартер — нет.

А>Что-то non sequitur. Можно примерно меня ориентировать на работы, или объяснить хотя бы почему именно это не есть хорошо, и в чем заключается "фундаментальная разница"?

А почему non sequitur? Из разных постов я сейчас допускаю, что не правильно вопрос понял — это возможно.

Что касается работ, то я находил на Sun Labs. После переезда на Oracle там похоже всё почистили. Я подробностей не помню, но это что-то типа A Note on Distributed Computing:

Every ten years (approximately),
members of the language camp notice that the number of
distributed applications is relatively small. They look at
the programming interfaces and decide that the problem is
that the programming model is not close enough to what-
ever programming model is currently in vogue (messages
in the 1970s [7], [8], procedure calls in the 1980s [9], [10],
[11], and objects in the 1990s [1], [2]). A furious bout of
language and protocol design takes place and a new dis-
tributed computing paradigm is announced that is compli-
ant with the latest programming model. After several
years, the percentage of distributed applications is discov-
ered not to have increased significantly, and the cycle
begins anew.

Дисер Joe Armstrong-а по Erlang-у есть в свободном доступе, но ссылки у меня нет. Кратко, о его виденьи разницы в блоге.

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

Здравствуйте, sorc, Вы писали:

S>Это как-то больше похоже на удалённый вызов методов и конструкторов. По-моему этот подход намного проще даже в реализации не говоря уже об использовании. Но все в один голос говорят что это не правильно и первый вариант лучше Рассуди нас RSDN.

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

Задача клиента — сообщить, что должно быть сделано, задача сервера — знать, как это сделать. RPC в вебе активно замещается RESTом, в том числе по причине большей декларативности.

Здравствуйте, sorc, Вы писали:

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

Насчет тех реализаций RPC, когда метод вызывается синхронно, я думаю, что надо долбануться головой об стену, чтобы так делать.

То, что раньше было наделано кривых реализаций "удаленного вызова методов" в виде синхронного RPC, никак не дискредитирует подход, если конечно, рельсы из головы вытащить, чего 95% людей сделать не могут, так как у них это врожденное.

S>Это как-то больше похоже на удалённый вызов методов и конструкторов. По-моему этот подход намного проще даже в реализации не говоря уже об использовании. Но все в один голос говорят что это не правильно и первый вариант лучше Рассуди нас RSDN.
Это классическая модель. Для локальных вызовов используют fine grained интерфейсы, а для удаленных coarse grained. При этом для реализации удаленных используют локальные.
Часто для удаленных вызовов все-же используют fine grained интерфейсы, но при этом переходят на событийную модель и упаковывают комманды в пачки, добавляя к пачке атомарность.