Организация связи в Инфосфере: грид-мобильность

    Если грид — это распределенная структура, в которой каждый узел «весит» немного, зато распределение задач на миллионы таких узлов приводит к быстрому решению, то почему бы не привязать грид к мобильным устройствам?

    Тогда возникает проблема — а как налаживать канал из точки А в точку Б, если обе точки непрерывно перемещаются? В сотовой связи есть неподвижная базовая станция, которая связана с неподвижным коммутатором. Так образуется иерархия поиска: на коммутаторе непрерывно обновляется таблица, к какой базовой станции приписан тот или иной абонент.
    Упрощенно, знаю, но нам сойдет и такая модель.

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

    И как решать задачу позиционирования?
    Рисуется такой алгоритм:
    1. Каждая точка прописывает во внутреннюю таблицу все остальные точки, находящиеся в зоне ее доступа (прямой связи).
    Радиус, кстати. не должен быть велик — иначе в многолюдных местах можно поиметь такую табличку… хотя… Если один человек в минимуме занимает 0,3 кв. метра, то для точки с радиусом приема в 1 км. имеем 10,5 млн. записей — максимум. Это если стоят, как сельди в бочке. Тогда при размере идентификатора в 4 байт имеем базу в 40 МБайт. Немало, конечно…
    Но это — когда люди впихнуты по максимуму. А так средняя плотность порядка 1 человека на 10-15 кв. м., что дает нам 30-кратное уменьшение идентификаторов. Это 1 МБайт.
    Уже терпимо. Если учесть нынешнее скородействие, которое может быть заложено в гриде — более чем терпимо. А если вспомнить, что такой радиус необязателен, а может хватать и 200 м. — нормально, в общем.


    2. При наличии адресата в таблице сообщение отдается ему. При отсутствии — выбирается небольшое число (N) наиболее удаленных пользователей, прописанных в таблицу, и сообщение передается им.

    3. Процедура повторяется до получения сообщения адресатом с корректным ID.

    Вот такая вот штука рисуется. Интересный принцип, но технически его релизовывать — морока страшная…
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 17

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        См. предыдущие записи блога.
        Предполагается, что человек сам себе батарейка :)
        –1
        Алгоритм очень неудачный. за последние 40 лет придумали много чего поинтереснее.

        ...задачу позиционирования...


        И не позиционирвания а маршрутизации.

        ...Это 1 ГБайт...


        А точнее 1 Мбайт

        Если учесть нынешнее скородействие...


        Какой протокол и какую пропускную способность берём под данное определение?

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


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

          +1
          давно уже всё придумано и в софтк реализовано
          http://www.netsukuku.org/index.php?pag=a…
            0
            узлы в ней должны быть физически связаны между собой когда Netsukuku создаётся таблицу маршрутизации....
            ...Необходима Wi-Fi антенна...
            ...Сейчас мы работаем над Netsukuku для беспроводных точек доступа (например Linksys)...
            - взято отсюда

            Не совсем "уже реализовано", как можно видеть. Но в целом, практически то, о чем я написал. Однако я об этой штуке ранее не слыхал, думал сам. Радоваюсь за себя - что своим умом дошел до этой штуки, не являясь специалистом по связи.

            Буду следить, как она развивается. Спасибо за ссылку на ресурс.
              0
              надо разделять проект в целом и ту его часть, которая относится к протоколу маршрутизации...
              насколько я помню, а я могу путать и с другими проектами, их далеко не один, там некая фрактальная логика в построении таблиц маршрутизации. что делает их исключительно компактными и растущими не линейно от числа узлов, а логарифмично или даже ещё выгоднее
                0
                Ох уж мне эти фракталы! Модная фишка, каждой бочке затычка...
                А уж "фрактальная логика" - вообще страшный зверь, который все данные сожрет (сожмет) в полтора бита, и будет всем нирвана.

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

                Синергетический эффект от этих проектов (мобилизация + гридизация), думаю, начнет проявляться, когда ЭВМ нынешнего офисного уровня (2 ГГц, 512 Мбайт ОЗУ, 80-100 ГБайт ПЗУ) будет таких размеров, при которых ее можно положить в карман рюкзачка-шмотника. Тогда принципы, которые сейчас разрабатываются в Нецукуке, очень понадобятся, будь они на фрактальной логике или нет...
          0
          Алгоритм очень неудачный. за последние 40 лет придумали много чего поинтереснее.
          А поконкретнее?

          точнее 1 Мбайт
          Thnx. Проверил, поправил. Тем лучше.

          Какой протокол и какую пропускную способность берём под данное определение?
          Я имел в виду, что базу объемом в 1 МБайт и при нынешних мощностях процессоров можно довольно быстро обрабатывать на предмет "кто в базе где". Протоколы и пропускная способность тут будут внутренние - между CPU, RAM и шиной.

          Вы гвозди забивать микроскопом не пробовали? тож морочно, но под траву очень занимательно.
          Чувствуется немалый опыт в Вашем суждении :)
          Вопрос-то в другом: как далеко может зайти "мобилизация", и не возникнут ли предпосылки для формирования некоторых совершенно новых общественных институтов.
          0
          И еще. Понятное дело, что для оптимизации передачи данных можно будет вести статистику "наиболее частые местонахождения точки" и слать данные в том направлении.

          И вот если оттуда не получено подтверждение, тогда уже "искать" везде.
            +1
            Главная проблема такой архтектуры - одноранговость сети. когда 250к пойнтов будут посылать в сеть широковещательные запросы о своём существовании, то мне кажется, что может элементарно не хватить пропускной способности протокола на конкретной частоте.

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

            А поконкретнее?
            Посмотрите на реализацию стека TCP/IP. Шлюзы, Маршруты, TTL. Без TTL я отправлю запрос на несуществующий айдишник и он будет путешевствовать во вселенной до судного дня ;)

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

            А если я нахожусь в Китае а адресат в Турции? Какие затраты пойдут на организацию канала? какое будет его качество? Какие пинги?
              0
              Так канала-то и не будет...
              250 тыс. пойнтов - это, если учитывать плотность человеков на кубометр (примерно 0,1 ч./куб.м - 2,5м х 2м х 2м), 2,5 млн. кубометров. Это немаленький объем - куб со стороной примерно 85 м. Особенно если учесть, что основная концентрация идет все-таки по плоскости...

              Далее. Трафик этот будет все-таки пиковым: нет нужды непрерывно опрашивать всех окружающих. Раз в 4-5 минут для зоны досягаемости в 100 м - более чем достаточно. "Размазать" опросы по времени - тоже небольшая проблема.

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

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

              Впрочем, обсуждаемость технических моментов вызывает мысли о принципиальной возможности реализации данного варианты.
              Quod erat demonstrandum. Спасибо.
                +1
                Возможно рассматреть подобную ситуацию.
                При достижении определенной плотности, точки объединяются в кластер и выбирают временного лидера, который занимается задачей распределения задач и запросов. При определенной плотности кластеров, кластеры объединяются в кластер более высокого уровня и так далее. При выходе лидер сообщает своему кластеру, что он "сваливает". Члены кластеры производят перевыборы. Механизм там уже прост наверное будет. При появлении новой точки в кластере, лидер производит учет. Тем более любой из членов кластера может сообщить "новичку" кто лидер. Члены кластера знают о своем лидере и все вопросы к нему. Вот и не надо хранить каждому таблицу об окружающих.
                  0
                  Я примерно к этой же идее и пришел. Фишка в том, что при наличии грид-сети "лидер" не нужен - достаточно выделить некоторый ресурс грида для хранения. Этакую распределенную таблицу, где будет прописано, как да что.
                  Тогда проблема выхода лидера будет отсутствовать.
                    0
                    Хотелось бы узнать, как подобная таблица будет выглядеть? Точнее, как будет производиться поиск в ней?
                    Уже из поиска можно представить как будет производится поиск оптимального транзита информации в такой грид-среде.

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

              Спасибо, господа.

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

              Самое читаемое