Evgeny_CD, Архитектор (28.02.2013 13:41, просмотров: 535)Очень здравые идеи заложены в COOJA - симулятор сети, идущий с тулчейном Contiki. -> http://dunkels.com/adam/osterlind10cooja.pdf
http://wiki.contiki-os.org/doku.php?id=an_introduction_to_cooja
Сам С код Contiki скомпилирова в либу. Java имеет доступ через Java Native Interfaces (JNI). Симулятор со всеми понтами написан на Java. Есть даже модели MAC контроллеров всякмх разных для более точной симуляции сети. Contiki рекламируется как event-driven http://ru.wikipedia.org/wiki/Contiki http://ru.wikipedi …0%B0%D0%BD%D0%B8%D0%B5 Т.е. в общем случае, для нее совсем не важно RT. Есть события, есть куски кода, которые привязаны к ним. И есть внешняя среда. В котором есть понятие времени, и именно к нему привязываются события. Время не обязательно должно быть реальным. Дальше, наверное, сделано так. Есть универсальный код узла, и есть указатель на структуру - состояние узла. И есть некий long long int, который представляет время. Вызвали узел. Он вернул, что в такой-то момент времени у него будет событие. Он что-то там попытаеся передать или принять, или у него просто сработает таймер и переключатся задачи. Все остальное время для узла не интресно. В нем ничего не происходит, его нет для мира. Узел вернул указатель на список своих событий с временем в будущем. Заносим эти события в большое дерево для поиска - время, класс события, узел. Есть еще некий "коммутатор событий". На вход событие, которое породилось - на выходе кого надо информировать об этом событии. + есть какие-то задачи собственно симулятора сети. Тикаем время. Смотрим по указателю - кого надо вызвать. Вызываем. Заносим события. И т.д. Делать из C кода некий "доступный через вызовы код" не обязательно. Можно запустить С код с неким менеджером, по сути - специализированным монитором, который будет принимать команды по IP и туда же закидывать ответ. Причем эта конструкиция может жить под Linux, живущим, в свою очередь, на виртуальной машине. Или на отдельной физический - IP он на то и IP... Мораль: * среда разработки для сложных проектов должна состоять из "двух систем программирования". -- Одна - это реализация целевого языка, С|C++. -- Вторая - это очень мощная система со встроеннцм удобным программизмом визуализации, в которой будут программироваться тестовые воздействия. HLL далее. -- Единая универсальная база кода -- система взаимодействия. Единая база кода нужна для того, если есть С функция, и я знаю ее имя - тот при написании кода в HLL мне тут же подсовывают все необходимые именя и врапперы для С типов данных. * Принцип KISS рулит. http://ru.wikipedi …0%BD%D1%86%D0%B8%D0%BF) Т.е. можно на SystemC сделать модельку проца, и пустить на нем цевой бинарник, но когда мы отлажиаем сетевую архитектуру - это лишее. Прежде чем перейти к пониманию того, есть ли у проца в ноде утечка памяти, надо понять - а нода вообще целевую задачу решает или как? Модельки на SystemC - это важный и необходимый элемент, он легко вписывается в приведенную выше архитектуру, но начинать отладку сети с него неразумно. * Вероятно, Tcl является неплохим кандидатом на "второй язык". -- Tk для "рабочего GUI программизма". Без гламура, но чтобы пол экрана кода на визуализацию простых вещей, и они гарантировано работали. -- достаточно HLL -- хорошая экосистема -- нативная интеграция с С * Java, возможно, тоже кандидат на "второй язык". Уж большо хорошо на ней всякий абстракциониз пишется...
http://wiki.contiki-os.org/doku.php?id=an_introduction_to_cooja
Сам С код Contiki скомпилирова в либу. Java имеет доступ через Java Native Interfaces (JNI). Симулятор со всеми понтами написан на Java. Есть даже модели MAC контроллеров всякмх разных для более точной симуляции сети. Contiki рекламируется как event-driven http://ru.wikipedia.org/wiki/Contiki http://ru.wikipedi …0%B0%D0%BD%D0%B8%D0%B5 Т.е. в общем случае, для нее совсем не важно RT. Есть события, есть куски кода, которые привязаны к ним. И есть внешняя среда. В котором есть понятие времени, и именно к нему привязываются события. Время не обязательно должно быть реальным. Дальше, наверное, сделано так. Есть универсальный код узла, и есть указатель на структуру - состояние узла. И есть некий long long int, который представляет время. Вызвали узел. Он вернул, что в такой-то момент времени у него будет событие. Он что-то там попытаеся передать или принять, или у него просто сработает таймер и переключатся задачи. Все остальное время для узла не интресно. В нем ничего не происходит, его нет для мира. Узел вернул указатель на список своих событий с временем в будущем. Заносим эти события в большое дерево для поиска - время, класс события, узел. Есть еще некий "коммутатор событий". На вход событие, которое породилось - на выходе кого надо информировать об этом событии. + есть какие-то задачи собственно симулятора сети. Тикаем время. Смотрим по указателю - кого надо вызвать. Вызываем. Заносим события. И т.д. Делать из C кода некий "доступный через вызовы код" не обязательно. Можно запустить С код с неким менеджером, по сути - специализированным монитором, который будет принимать команды по IP и туда же закидывать ответ. Причем эта конструкиция может жить под Linux, живущим, в свою очередь, на виртуальной машине. Или на отдельной физический - IP он на то и IP... Мораль: * среда разработки для сложных проектов должна состоять из "двух систем программирования". -- Одна - это реализация целевого языка, С|C++. -- Вторая - это очень мощная система со встроеннцм удобным программизмом визуализации, в которой будут программироваться тестовые воздействия. HLL далее. -- Единая универсальная база кода -- система взаимодействия. Единая база кода нужна для того, если есть С функция, и я знаю ее имя - тот при написании кода в HLL мне тут же подсовывают все необходимые именя и врапперы для С типов данных. * Принцип KISS рулит. http://ru.wikipedi …0%BD%D1%86%D0%B8%D0%BF) Т.е. можно на SystemC сделать модельку проца, и пустить на нем цевой бинарник, но когда мы отлажиаем сетевую архитектуру - это лишее. Прежде чем перейти к пониманию того, есть ли у проца в ноде утечка памяти, надо понять - а нода вообще целевую задачу решает или как? Модельки на SystemC - это важный и необходимый элемент, он легко вписывается в приведенную выше архитектуру, но начинать отладку сети с него неразумно. * Вероятно, Tcl является неплохим кандидатом на "второй язык". -- Tk для "рабочего GUI программизма". Без гламура, но чтобы пол экрана кода на визуализацию простых вещей, и они гарантировано работали. -- достаточно HLL -- хорошая экосистема -- нативная интеграция с С * Java, возможно, тоже кандидат на "второй язык". Уж большо хорошо на ней всякий абстракциониз пишется...