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

ок.
мой последний пост прокомментируйте.

зачем группироваться.. и вообще не понял о чем речь.. 



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


нет схема вполне могла быть такой :

ss - subservice, например есть сервис игры, а к нему подключаются сервисы конкретной игры...

Добавлено через 3 минуты и 2 секунды

в P2P сетях каждый клиент является и сервером одновременно..

Добавлено через 4 минуты и 22 секунды

   
но ее бы найти бы вначале   



Это сообщение отредактировал(а) mes - 30.3.2011, 23:19

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

  

да. но чтоб найти друг-друга, все равно шлете запросы на трекер.

эволюция должна происходить не путем наращивания функкциональности сервиса, а путем расширения сервисов..

Добавлено через 51 секунду

да но он не является сервером как таковым.

Добавлено через 5 минут
адреса взаимодействующих к примеру могут быть _вшиты_
но это уже шаг в сторону, давайте вернемся к нашей задачке 

говоря об _интерфейсе_узлов_ имею ввиду следующее: есть объект, к примеру, типа base. этот объект, при создании, получает информацию о том, кто сервер(организатор/распределитель_обязанностей/координатор(не знаю как правильно назвать его)). объект, по имеющейся информации о сервере, способен подключиться к серверу. но, так как этот объект типа base, у него _стандартный_базовый_интерфейс_. а этот интерфейс, не требует от этого типа объекта участия в чем либо.

другой пример: наследуемся от base. к примеру, перегружаем его метод required(), который сервер вызывает чтоб получить информацию о том, какие сервисы нужны этому типу узла. все. при подключении, сервер спросит его о нужных ему сервисах. из этого, сервер отдаст ему информацию, необходимую для того, чтоб этот узел смог принять участие в задаче, для которой он предназначен.

как-то так...

Добавлено @ 23:38

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

Добавлено @ 23:40

я и не говорю чтоб он был сервером как таковым.


это нехорошо. ограничивает. навязывает область применения и принцип общения. у нас могут быть не только адреса. а, к примеру, ID`ы ;)
мы же ищем идеальную модель ;)


Это сообщение отредактировал(а) boostcoder - 30.3.2011, 23:47

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

Добавлено через 2 минуты и 37 секунд

еще один термин забыли : задача

а что без созданной задачи сервисы не существуют ?!

поправил.
просто не знаю как еще выразить это.


в моем видении, задача - это то, над чем работают узлы.
т.е. допустим, сервер предоставляет два сервиса: 1) compute_1, 2) compute_2. подключился узел. сервер у него запросил интересующий его сервис. сервер вернул ему информацию о том, кто в сети, условия для входа в сеть, и т.д..


сервис - это то, что предоставляет наш dataflow  

Это сообщение отредактировал(а) boostcoder - 30.3.2011, 23:54

я говорю разве, что хорошо ? я говорю лишь о том что бывает и такое 



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

Добавлено через 56 секунд

приведите в пример реальную ситуацию.. 

распознавание графического образа:
допустим, что узлы - отдельные ПК в мире. каждый ПК, к примеру, создает по одному ноду.
итак.. есть сервер(координатор). в данный момент, к примеру, сервер предоставляет И сервис _распознавание_графического_образа_(РГО).
узел, подключившись к серверу, сообщает ему свой сервис. из этого, сервер знает, что этот узел нужно отправить в dataflow РГО, и сообщает ему необходимую информацию. все. с этого момета, узел, благодаря своему ориентированному под эту задачу интерфейсу, может общаться с другими узлами, в терминах, подобных себе узлов  

Up.
какие требования к узлу я вижу:
1. способ обращения к координатору.
2. сервис.
3. способ обращения к узлам.
....

Это сообщение отредактировал(а) boostcoder - 31.3.2011, 00:15

вообще-то вопрос в достаточной степени проработан. предлагаю взглянуть на CORBA. врядли пионерским наскоком получится революционное решение. CORBA предлагается в качестве примера потому, что она стандартизована.
вобщем-то все такие готовые штуки независимы от ЯП. достоинства и недостатки такого подхода очевидны.
если в постановке задачи С++, то мы сразу можем думать не об IDL, а о статической типизации только средствами компилятора (техническая сторона в некоторой степени вами уже проработана)
далее, клиенты/серверы/сервисы.
у mes было понятие мигранта как средства коммуникации в канале. предлагаю пока этим ограничиться, т.к. тут тоже важен интерфейс, а реализация канала может быть любой, хоть поверх boost::asio, хоть поверх HTTP
давайте сосредоточимся на двух вещах
1. клент: какой общий интерфейс ему нужен. скажем, имеется конкретный сервис в виде класса (определенного в заголовке, как это обычно в С++). его нужно каким-то вызовом связать с сервером, получив объект того самого типа, а дальше работать как с обычным объектом. тут нас пока интересует инфраструктура, т.е. какие возможности предоставляются клиенту - поиск серверов, установка соединения и т.д.
думаю идеологически это должно быть сильно похоже на COM и CORBA с той разницей, что тип определяется не строкой, а собственно типом.
2. сервер: помимо предоставления собственно интерфейса ему так же нужны вспомогательные средства для публикации себя

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



  
я рад, что разговор уходит в более конструктивное русло 

пример, имхо, не очень удачный.. опробовать на нем нам вряд ли удастся..
давайте для начала на чем нибудь более простом.. например на mail_service.. 

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