распределенная БД организованная в сеть. с распределенной транзакцией. очень интересный пример  


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

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

ну... это явно лишнее)

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

например?

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

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

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

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

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

Добавлено @ 20:50

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


Это сообщение отредактировал(а) mes - 2.4.2011, 21:58

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

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

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

зачем ?!


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

я это к тому, чтоб не было главного узла.


я потому и предлагаю вообще избавится от сервера.

  


  

даже в том же jabber`e с его децентрализованной системой, есть сервера 

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

пример: http://ru.wikipedia.org/wiki/Kad

 


Вы уверенны что это именно то, что Вам нужно ? 

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


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

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

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


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

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

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

что именно подразумевается под _транспортом_ ?

Добавлено через 5 минут и 14 секунд

не совсем так.. 

механизмы взаимодействия.

Добавлено через 1 минуту и 12 секунд
мы ходим по кругу. утвердить принципы/архитектуру нужно вначале. имхо.