[Don_Ambrosio 0]

Использовали ли Вы при программировании абстракцию сети кроме задач построения локальных сетей? Т.е. где удобно использовать абстракцию сети/графа при работе с программными объектами. Т.е. организовать программу как локальную сеть: передаём «пакет» одному объекту, тот анализирует «пакет» и если он предназначен не ему - передаёт другому, И так далее. Т.е. происходит определение «маршрута» и следование «пакета» по этому «маршруту», хотя объекты (т.е. экземпляры класса) находятся в ОЗУ единственного процессора и можно было бы передать «пакет» сразу напрямую нужному объекту. В каких случаях используется такая многоступенчатость вместо передачи «напрямую»?

 

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

 

 

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

 

P.S. Хочу разработать сетевую RTOS, в которой реализовать прозрачность работы с потоками и экземплярами класса. Т.е. для юзверя было глубоко "фиолетово" где находится поток или экземпляр класса: на том же самом процессоре или вообще где-то на другом узле локальной сети на удалении 10-ти хопов. Чтобы он работал с ними однообразно

 

 

 

 

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

 

P.S. Хочу разработать сетевую RTOS, в которой реализовать прозрачность работы с потоками и экземплярами класса. Т.е. для юзверя было глубоко "фиолетово" где находится поток или экземпляр класса: на том же самом процессоре или вообще где-то на другом узле локальной сети на удалении 10-ти хопов. Чтобы он работал с ними однообразно

 

Добавление от 29.06.2008 11:53:

 

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

 

Или наоборот. Абстрагироваться от существоания одного процессора, и решать задачу так, как будто есть целая сеть процессоров

 

 

Зачем это нужно? Да чтоб отлаживать сеть симулируя её на одном единственном процессоре. Т.е. софт верхнего уровня, чтоб даже не предполагал, что никакой сети нет, и всё "действо" происходит на одном единственном процессоре

 

 

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

[vshemm 0]

MPI (http://en.wikipedia.org/wiki/Message_Passing_Interface)?

 

Еще в qnx нечто подобное есть, через qnet обеспечивается прозрачная связь с удаленными процессами как с локальными.

Примерно так: http://qnxcs.unomaha.edu/help/product/neut..._arch/qnet.html

[Don_Ambrosio 0]

А как быть с реализацией отладки распределёных сетевых приложений и стеков сетевых протоколов не имея всей сети, на которой они будут работать, а имея в распоряжении один единственный процессор?

 

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

 

Хотя у меня задача даже ещё сложней :

Не распределённое приложение СКРЫТЫМ для него образом будет параллельно работать на нескольких узлах сети (т.е.приложение не должно даже "догадываться" о том, что оно выполняется не на одном, а на нескольких процессорах сети). А сеть я хочу софтово имитировать на одном процессоре. Т.е. получается два уровня абстракции и 4 уровня отладки:

- отладка самого целевого не распределённого приложения

- отладка средств его распараллеливания и распределения по узлам сети

- отладка стеков сетевых протоколов сети на одном процессоре

- отладка средств скрытия от кода сетевых протоколов того, что они реально выполняются на одном процессоре, а не на нескольких

Изменено 29 июня, 2008 пользователем Дон Амброзио

[vshemm 0]

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

Разумеется, приложение должно создаваться в модели передачи сообщений между процессами.

 

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

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

[Don_Ambrosio 0]

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

Разумеется, приложение должно создаваться в модели передачи сообщений между процессами.

Не совсем так. Да, для приложения надо имитировать, что оно работает на одном процессоре. Но ОДНОВРЕМЕННО для средств распаралливания и стеков сетевых протоколов нужно иммитировать, что имеется несколько узлов и они работают не них

[AlexandrY 2]

Есть куча технологий на этот счет:

DCOM, SOAP, CORBA, RMI ...

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

Т.е. решается на самом деле проблема документирования этими методиками и не более.

 

Но неопытные головы обычно не понимают этой проблемы и поэтому не понимают до конца и смысла существования распределенных протоколов.

 

Ставлю 100 против 1, что вам на самом деле не нужна никакая абстракция сети если вы всю систему разрабатываете один.

 

 

Не совсем так. Да, для приложения надо имитировать, что оно работает на одном процессоре. Но ОДНОВРЕМЕННО для средств распаралливания и стеков сетевых протоколов нужно иммитировать, что имеется несколько узлов и они работают не них

[Don_Ambrosio 0]

вам на самом деле не нужна никакая абстракция сети если вы всю систему разрабатываете один.

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

 

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

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

Изменено 29 июня, 2008 пользователем Дон Амброзио

[AlexandrY 2]

Чет это вы о себе в 3-ем лице?

 

Так себе делаете или программеру верхнего уровня?

Себе делайте че хотите.

Но вам любой студент скажет, что распределенные технологии типа DCOM, CORBA, RMI - это верх

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

И никакому моделированию на виртуальных платформах они не поддаются.

Их тестируют нудно и упорно. И все равно сдают глючными.

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

Откуда у вас вообще уровни взялись, и как вы беретесь их определить?

 

 

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

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

[Don_Ambrosio 0]

Чет это вы о себе в 3-ем лице?

 

Так себе делаете или программеру верхнего уровня?

Себе делайте че хотите.

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

 

 

Но вам любой студент скажет, что распределенные технологии типа DCOM, CORBA, RMI - это верх

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

И никакому моделированию на виртуальных платформах они не поддаются.

Их тестируют нудно и упорно. И все равно сдают глючными.

Ужоснах :( Неужели всё так печально? А как же там запуски сотен вирутальных машин на одном компе и прочее? Ну чтоб отладить стек сетевых протоколов.

 

 

Откуда у вас вообще уровни взялись, и как вы беретесь их определить?

Первый уровень - прикладная не распределённая софтина

Второй уровеь - Софт распаралеливания прикладной софтины и раскидывания её частей по процессорам. Сюда же стек сетевых протоколов. Т.е. все это скрывает от приложения факт наличия сети.

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

 

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

Да не силён я в терминологии. Признаю

[AlexandrY 2]

Ну так я и знал. Все скатится к мистике.

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

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

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

Нет в мире никакого автоматического распаралеливания и распределения. Все делается ручками.

А уж когда это работает можете впаривать другим что у вас там типа уровни, типа все на автомате...

:smile3046:

 

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

Ужоснах :( Неужели всё так печально? А как же там запуски сотен вирутальных машин на одном компе и прочее? Ну чтоб отладить стек сетевых протоколов.

Первый уровень - прикладная не распределённая софтина

Второй уровеь - Софт распаралеливания прикладной софтины и раскидывания её частей по процессорам. Сюда же стек сетевых протоколов. Т.е. все это скрывает от приложения факт наличия сети.

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

Да не силён я в терминологии. Признаю

[Don_Ambrosio 0]

Ну так я и знал. Все скатится к мистике.

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

Согласен. Хотя бы межуровневые интерфейсы должны быть оговорены.

 

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

 

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

 

Получается фигово :)

 

Сначал разберусь с софтинкой, а потом на досуге подумаю как лучше Вам всё сформулировать.

 

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

 

Прям как в программах

Изменено 29 июня, 2008 пользователем Дон Амброзио

[Don_Ambrosio 0]

Господа! А на вопрос так и не ответили:

где удобно использовать абстракцию сети/графа при работе с программными объектами. Т.е. организовать программу как локальную сеть: передаём «пакет» одному объекту, тот анализирует «пакет» и если он предназначен не ему - передаёт другому, И так далее. Т.е. происходит определение «маршрута» и следование «пакета» по этому «маршруту», хотя объекты (т.е. экземпляры класса) находятся в ОЗУ единственного процессора и можно было бы передать «пакет» сразу напрямую нужному объекту. В каких случаях используется такая многоступенчатость вместо передачи «напрямую»?