согласен 

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

Добавлено через 2 минуты и 46 секунд
дал теме новое название. а то уже приелось)

распределенная равноправная система

распределенная иерархическая сеть

cS = Sc = server + client
sS = sS = server + service
ss = subservice

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


Это сообщение отредактировал(а) mes - 3.4.2011, 09:11

плохо понял диаграммы...

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

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

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


Это сообщение отредактировал(а) boostcoder - 3.4.2011, 17:19

зачем клиенту распологающемуся на мобильнике и имеющему ограничения на трафик быть равноправным ?

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


сейчас Вы говорите о частном случае.

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

Это сообщение отредактировал(а) boostcoder - 3.4.2011, 17:22

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

или




Это сообщение отредактировал(а) mes - 3.4.2011, 17:56

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

дело не столько в трафике, сколько в бесмысленности заставлять _цеплять_ сервер на каждый узел..

Добавлено через 2 минуты и 54 секунды
в том числе и заставлять программиста писать лишнее.. просто клиент гораздо проще сдвоенного узла..

Добавлено через 6 минут и 58 секунд
к тому же при _обмене_информации_ будет взаимодействовать только пол узла.. 

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

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

я как не понял приведенные вами диаграммы, так и код..


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

как это _заставляет_ делать каждый узел двойным ? 


никуда от этого не денетесь 


ну так может начнем с разбора этого ? 

а зачем плодить сущности?


эт мы еще посмотрим   


давайте...

 а зачем две разные сущности объединять насильно в одну, связывая программисту руки ?