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


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


вот тут у нас и ошибка.. 

какая?

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

Добавлено через 1 минуту и 9 секунд
а ошибка в том, что не можем взглянуть шире и сфокусировали действия не на том..

Добавлено через 1 минуту и 36 секунд
точнее на том, но сильно узко сократили рамки задачи.. 

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

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

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

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

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

ну а прежде чем определять, хорошо бы набросать условную схему..


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

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

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


поясните. не очень понимаю...


эм... тоже не понял..


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

зы
онлайн диаграммы очень удобно рисовать тут: http://www.mind42.com/
при том, одновременно могут изменять диаграмму несколько человек, и всем остальным рассылается сообщением об изменении  

вроде да.. 


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

начало положено...


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

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

S - server
s - service
c - client

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

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

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

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

clients:
 user 
 chat_bot 
 game_ai 

services: 
 talk_svc
 mail_svc
 game_svc

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

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

мысли закончились...

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

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

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

Добавлено @ 22:49

перефразирую: из сервиса, узел узнает о других узлах, принимающих участие в нужной узлу задаче.

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

пока все верно?

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

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

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


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


в примере да, а как в вашей задаче нужно не знаю 


да это сервер ориентированная модель.. но в распределенной системе сервер как таковой может не быть... 

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


Вы случаем сервер и сервис нигде не спутали?


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


а кто будет разруливать узлы в нужные русла?