Comments 17
UFO just landed and posted this here
Алгоритм очень неудачный. за последние 40 лет придумали много чего поинтереснее.
И не позиционирвания а маршрутизации.
А точнее 1 Мбайт
Какой протокол и какую пропускную способность берём под данное определение?
Вы гвозди забивать микроскопом не пробовали? тож морочно, но под траву очень занимательно.
...задачу позиционирования...
И не позиционирвания а маршрутизации.
...Это 1 ГБайт...
А точнее 1 Мбайт
Если учесть нынешнее скородействие...
Какой протокол и какую пропускную способность берём под данное определение?
Интересный принцип, но технически его релизовывать - морока страшная...
Вы гвозди забивать микроскопом не пробовали? тож морочно, но под траву очень занимательно.
давно уже всё придумано и в софтк реализовано
http://www.netsukuku.org/index.php?pag=a…
http://www.netsukuku.org/index.php?pag=a…
узлы в ней должны быть физически связаны между собой когда Netsukuku создаётся таблицу маршрутизации....
...Необходима Wi-Fi антенна...
...Сейчас мы работаем над Netsukuku для беспроводных точек доступа (например Linksys)... - взято отсюда
Не совсем "уже реализовано", как можно видеть. Но в целом, практически то, о чем я написал. Однако я об этой штуке ранее не слыхал, думал сам. Радоваюсь за себя - что своим умом дошел до этой штуки, не являясь специалистом по связи.
Буду следить, как она развивается. Спасибо за ссылку на ресурс.
...Необходима Wi-Fi антенна...
...Сейчас мы работаем над Netsukuku для беспроводных точек доступа (например Linksys)... - взято отсюда
Не совсем "уже реализовано", как можно видеть. Но в целом, практически то, о чем я написал. Однако я об этой штуке ранее не слыхал, думал сам. Радоваюсь за себя - что своим умом дошел до этой штуки, не являясь специалистом по связи.
Буду следить, как она развивается. Спасибо за ссылку на ресурс.
надо разделять проект в целом и ту его часть, которая относится к протоколу маршрутизации...
насколько я помню, а я могу путать и с другими проектами, их далеко не один, там некая фрактальная логика в построении таблиц маршрутизации. что делает их исключительно компактными и растущими не линейно от числа узлов, а логарифмично или даже ещё выгоднее
насколько я помню, а я могу путать и с другими проектами, их далеко не один, там некая фрактальная логика в построении таблиц маршрутизации. что делает их исключительно компактными и растущими не линейно от числа узлов, а логарифмично или даже ещё выгоднее
Ох уж мне эти фракталы! Модная фишка, каждой бочке затычка...
А уж "фрактальная логика" - вообще страшный зверь, который все данные сожрет (сожмет) в полтора бита, и будет всем нирвана.
Впрочем, на какой базе делать эти талбички - особой рояли не играет. Важен сам принцип - окончательное отделение от стационарных точек обработки данных, и меня донельзя радует, что уже появились проекты на эту тему.
Синергетический эффект от этих проектов (мобилизация + гридизация), думаю, начнет проявляться, когда ЭВМ нынешнего офисного уровня (2 ГГц, 512 Мбайт ОЗУ, 80-100 ГБайт ПЗУ) будет таких размеров, при которых ее можно положить в карман рюкзачка-шмотника. Тогда принципы, которые сейчас разрабатываются в Нецукуке, очень понадобятся, будь они на фрактальной логике или нет...
А уж "фрактальная логика" - вообще страшный зверь, который все данные сожрет (сожмет) в полтора бита, и будет всем нирвана.
Впрочем, на какой базе делать эти талбички - особой рояли не играет. Важен сам принцип - окончательное отделение от стационарных точек обработки данных, и меня донельзя радует, что уже появились проекты на эту тему.
Синергетический эффект от этих проектов (мобилизация + гридизация), думаю, начнет проявляться, когда ЭВМ нынешнего офисного уровня (2 ГГц, 512 Мбайт ОЗУ, 80-100 ГБайт ПЗУ) будет таких размеров, при которых ее можно положить в карман рюкзачка-шмотника. Тогда принципы, которые сейчас разрабатываются в Нецукуке, очень понадобятся, будь они на фрактальной логике или нет...
Алгоритм очень неудачный. за последние 40 лет придумали много чего поинтереснее.
А поконкретнее?
точнее 1 Мбайт
Thnx. Проверил, поправил. Тем лучше.
Какой протокол и какую пропускную способность берём под данное определение?
Я имел в виду, что базу объемом в 1 МБайт и при нынешних мощностях процессоров можно довольно быстро обрабатывать на предмет "кто в базе где". Протоколы и пропускная способность тут будут внутренние - между CPU, RAM и шиной.
Вы гвозди забивать микроскопом не пробовали? тож морочно, но под траву очень занимательно.
Чувствуется немалый опыт в Вашем суждении :)
Вопрос-то в другом: как далеко может зайти "мобилизация", и не возникнут ли предпосылки для формирования некоторых совершенно новых общественных институтов.
А поконкретнее?
точнее 1 Мбайт
Thnx. Проверил, поправил. Тем лучше.
Какой протокол и какую пропускную способность берём под данное определение?
Я имел в виду, что базу объемом в 1 МБайт и при нынешних мощностях процессоров можно довольно быстро обрабатывать на предмет "кто в базе где". Протоколы и пропускная способность тут будут внутренние - между CPU, RAM и шиной.
Вы гвозди забивать микроскопом не пробовали? тож морочно, но под траву очень занимательно.
Чувствуется немалый опыт в Вашем суждении :)
Вопрос-то в другом: как далеко может зайти "мобилизация", и не возникнут ли предпосылки для формирования некоторых совершенно новых общественных институтов.
И еще. Понятное дело, что для оптимизации передачи данных можно будет вести статистику "наиболее частые местонахождения точки" и слать данные в том направлении.
И вот если оттуда не получено подтверждение, тогда уже "искать" везде.
И вот если оттуда не получено подтверждение, тогда уже "искать" везде.
Главная проблема такой архтектуры - одноранговость сети. когда 250к пойнтов будут посылать в сеть широковещательные запросы о своём существовании, то мне кажется, что может элементарно не хватить пропускной способности протокола на конкретной частоте.
+ попробуйте прикинуть примерный траффик, который будет генерироваться таким количеством узлов и нагрузку (по пропускной способности ) для обеспечения маршрутизации для одного узла.
А поконкретнее?
Посмотрите на реализацию стека TCP/IP. Шлюзы, Маршруты, TTL. Без TTL я отправлю запрос на несуществующий айдишник и он будет путешевствовать во вселенной до судного дня ;)
И вот если оттуда не получено подтверждение, тогда уже "искать" везде.
А если я нахожусь в Китае а адресат в Турции? Какие затраты пойдут на организацию канала? какое будет его качество? Какие пинги?
+ попробуйте прикинуть примерный траффик, который будет генерироваться таким количеством узлов и нагрузку (по пропускной способности ) для обеспечения маршрутизации для одного узла.
А поконкретнее?
Посмотрите на реализацию стека TCP/IP. Шлюзы, Маршруты, TTL. Без TTL я отправлю запрос на несуществующий айдишник и он будет путешевствовать во вселенной до судного дня ;)
И вот если оттуда не получено подтверждение, тогда уже "искать" везде.
А если я нахожусь в Китае а адресат в Турции? Какие затраты пойдут на организацию канала? какое будет его качество? Какие пинги?
Так канала-то и не будет...
250 тыс. пойнтов - это, если учитывать плотность человеков на кубометр (примерно 0,1 ч./куб.м - 2,5м х 2м х 2м), 2,5 млн. кубометров. Это немаленький объем - куб со стороной примерно 85 м. Особенно если учесть, что основная концентрация идет все-таки по плоскости...
Далее. Трафик этот будет все-таки пиковым: нет нужды непрерывно опрашивать всех окружающих. Раз в 4-5 минут для зоны досягаемости в 100 м - более чем достаточно. "Размазать" опросы по времени - тоже небольшая проблема.
Одноранговость сети позволяет "отвязаться" от стационара. В условиях грид-социума можно создавать виртуальные уровни иерархии - это вполне решит возникающие задачи.
Плюс динамически меняющийся компонент ID, включающий в себя информацию о номере виртуальной подсети. При переходе, естественно, замещается.
А чтобы не потерять отправителя, помимо динамического ID можно установить еще и постоянный.
Впрочем, обсуждаемость технических моментов вызывает мысли о принципиальной возможности реализации данного варианты.
Quod erat demonstrandum. Спасибо.
250 тыс. пойнтов - это, если учитывать плотность человеков на кубометр (примерно 0,1 ч./куб.м - 2,5м х 2м х 2м), 2,5 млн. кубометров. Это немаленький объем - куб со стороной примерно 85 м. Особенно если учесть, что основная концентрация идет все-таки по плоскости...
Далее. Трафик этот будет все-таки пиковым: нет нужды непрерывно опрашивать всех окружающих. Раз в 4-5 минут для зоны досягаемости в 100 м - более чем достаточно. "Размазать" опросы по времени - тоже небольшая проблема.
Одноранговость сети позволяет "отвязаться" от стационара. В условиях грид-социума можно создавать виртуальные уровни иерархии - это вполне решит возникающие задачи.
Плюс динамически меняющийся компонент ID, включающий в себя информацию о номере виртуальной подсети. При переходе, естественно, замещается.
А чтобы не потерять отправителя, помимо динамического ID можно установить еще и постоянный.
Впрочем, обсуждаемость технических моментов вызывает мысли о принципиальной возможности реализации данного варианты.
Quod erat demonstrandum. Спасибо.
Возможно рассматреть подобную ситуацию.
При достижении определенной плотности, точки объединяются в кластер и выбирают временного лидера, который занимается задачей распределения задач и запросов. При определенной плотности кластеров, кластеры объединяются в кластер более высокого уровня и так далее. При выходе лидер сообщает своему кластеру, что он "сваливает". Члены кластеры производят перевыборы. Механизм там уже прост наверное будет. При появлении новой точки в кластере, лидер производит учет. Тем более любой из членов кластера может сообщить "новичку" кто лидер. Члены кластера знают о своем лидере и все вопросы к нему. Вот и не надо хранить каждому таблицу об окружающих.
При достижении определенной плотности, точки объединяются в кластер и выбирают временного лидера, который занимается задачей распределения задач и запросов. При определенной плотности кластеров, кластеры объединяются в кластер более высокого уровня и так далее. При выходе лидер сообщает своему кластеру, что он "сваливает". Члены кластеры производят перевыборы. Механизм там уже прост наверное будет. При появлении новой точки в кластере, лидер производит учет. Тем более любой из членов кластера может сообщить "новичку" кто лидер. Члены кластера знают о своем лидере и все вопросы к нему. Вот и не надо хранить каждому таблицу об окружающих.
Я примерно к этой же идее и пришел. Фишка в том, что при наличии грид-сети "лидер" не нужен - достаточно выделить некоторый ресурс грида для хранения. Этакую распределенную таблицу, где будет прописано, как да что.
Тогда проблема выхода лидера будет отсутствовать.
Тогда проблема выхода лидера будет отсутствовать.
Хотелось бы узнать, как подобная таблица будет выглядеть? Точнее, как будет производиться поиск в ней?
Уже из поиска можно представить как будет производится поиск оптимального транзита информации в такой грид-среде.
Я тоже прокатывал кое-какие мысленные модели, и вот как время будет попробую реализовать механизм, который ассоциативно похож на поток воды, который со временем в породе пробивает более-менее оптимальный вариант.
Уже из поиска можно представить как будет производится поиск оптимального транзита информации в такой грид-среде.
Я тоже прокатывал кое-какие мысленные модели, и вот как время будет попробую реализовать механизм, который ассоциативно похож на поток воды, который со временем в породе пробивает более-менее оптимальный вариант.
Интересное обсуждение получается :) полезные ссылки падают (правда, мне переводить лениво...), хорошие вопросы задают...
Спасибо, господа.
Спасибо, господа.
Sign up to leave a comment.
Организация связи в Инфосфере: грид-мобильность