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