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

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

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

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

я об этом и говорю.


зачем? почему?


оно не лишнее. оно базовое 

оно не базовое, так как нет взаимодействия CS -> CS 

будет! 

я не понимаю почему Вы против. мне кажется чего-то Вы недоговариваете...

Добавлено @ 19:53
наверное нужно создать новую тему..
в каком разделе?
тут?: http://forum.vingrad.ru/forum/tech-algorit...que-method.html

может во флейме? там максимум народа тусит)

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

потому что для описания всех комбинаций достаточно S и C, а SC вынуждает на трудности.. 
если не согласны  приведите пример кода где CS успешно эмулирует S и С..
или аргумент что C никогда не нужна на примере хотя бы простого чата..

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

  

кодом? псевдокодом? словами?

как удобно 

кажется я понял, о чем Вы..  о том что каждый узел обладает равноценным кусочком знаний об общей сети.. 
так это стоит за спинами : т.е.  узлы выглядит так 
(C-D-S) или (C-D) или (D-S), где  D - data_context

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

Добавлено через 1 минуту и 58 секунд
итак нам нужно ряд тезисов характеризующих сеть.. можно обрывистых.. 


Это сообщение отредактировал(а) mes - 5.4.2011, 20:49

второй день размышляю, и записываю.
завтра выдам 

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

мысль не закончена. не все расписано.
во первых - не все поймете.
во вторых - потратите время.

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

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

т.е. _math по отношению к _server   является удаленной, так же как и _server по отношению к клиенту..

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

Добавлено через 7 минут и 45 секунд
опять помойму только запутал своими высказываниями.. 

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

при этом 



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

если поделить сообщения на вопросы и ответы, то получается примерно следующее :

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

Это сообщение отредактировал(а) mes - 9.4.2011, 14:00