Foreword:

Definitions:

Structure

    • Коммуникационные устройства (они же Node, x, n), способные общаться между собой, называются группой, или GNode. Группы вложены друг в друга - как планеты в солнечные системы, те - в галактики, галактики в скопления и т.д. Устройство, могущее без посредников передавать сообщения данному, называется его соседом, иначе RNode, gateway (все его соседи вместе обозначаются как V). Устройство называется экстремальным, если имеет только одного соседа. Называется граничным, BNode, если имеет соседа из другой группы. Новое устройство, подсоединяющееся к сети, называется HNode (видимо "hooking node"). Communication devices (they are also Node, x, n), which is able to communicate with each other, have name group, or GNode. Groups are enclosed into each other - like planets into solar systems, solar systems into galaxies, galaxies into accumulations, and so on. Device, able to transfer messages to other device without mediator, is named as its neighbour, or RNode, gateway (all its neighbours together is designated as V). Device is named as extreme device, if it has only one neighbour. Device is named as border device, BNode, if it has neighbour from another group. New device, connecting to net, has name HNode (obviously "hooking node").

2.

3.

Каждая группа выбирает в группе, в которую она вложена, одно устройство в качестве маяка. Таким образом устройства также предстают перед нами подобно XML-элементам, и к ним применимы понятия "XPath: корень, ребенок, родитель, потомок, предок, брат" (термин "path" не будем использовать, т.к. он вызывает когнитивный диссонанс с термином маршрут для сообщений). Адресом любого устройства является перечень идентификаторов маяков из всех предковых групп плюс идентификатор самого этого устройства. Т.е. адрес "резиновый", состоит из произвольного количества идентификаторов. Если корень одной "иерархии" устройств оказывается в пределах досягаемости группы другой иерархии, то две иерархии сливаются - либо в первой иерархии дистальнее этой группы, либо во всей второй иерархии изменяются адреса. Адреса изменяются в том конгломерате устройств, который численно меньше. Численно меньшим считается тот, у которого меньше вычислительная мощность (вычисляется функция f(x) mod k; f(x) еще не придумали; k - случайное число из диапазана [216...232]).

  1. Присоединяющееся устройство узнает идентификатор маяка от собственных братьев. Основывающее устройство спрашивает в родительской группе, какие её устройства не являются маяками; выбирает один из них как маяк, информирует его об этом, и спрашивает у него его адрес, чтобы вычислить свой. Правильно?
  2. Каждое устройство должно помнить всех своих детей чтобы сообщать им об изменении своего адреса, если это случится, не так ли?

Each group choose one device as beacon in group, into which it is nested. Thus devices appear also before us like XML-elements, and notions "root, child, parent, descendant, ancestor, sibling" of "XPath" are appliable for them (we will not use term "path", because it make cognitive dissonance with notion route for messages). Address of any device is list of identifiers of beacons from all ancestor's groups plus identifiers of this device itself. I.e. address is "rubber", consists of arbitrary quantity of identifiers. If root of one "hierarchy" of devices occurs within reach of group of other hierarchy, two hierarchies merge - addresses are changed either more distant than this group in first hierarchy, or in whole second hierarchy. Addresses are changed in conglomerate of devices, which is numerically less. So conglomerate is considered numerically less, which has less computability power (function f(x) mod k is calculated; f(x) is not imagined just now; k is random number inside [216...232]).

  1. Appending device find identifier of beacon from own siblings. Founding device ask parent group about what its devices are not beacon; choose one of them as beacon, inform it about this, and asks its address to calculate own address. Right?
  2. Each device should remember all own children to inform them about changing of own address, if it will happen, isn't it?

4.

Дублет {hash(UID), адрес} хранится и обновляется в "DHT". P.S. Понятие HashGNode, используемое ниже в QSPN для криптографии, возникает так. Результат хэш-функции от UID называется H. Устройство, чей адрес равен вычисленному H, называется HashNode, или nH. Группа, которой принадлежит HashNode - HashGNode, gH. Ближайшая к ней все еще активная группа - RoundedHashGNode, rgH; дублеты храняться на всех устройствах этой последней. Процесс копирования дублетов на устройство, примкнувшее к RoundedHashGNode, называется AndnaHook. Устройства регистрируют не более 250 дублетов (чтобы не перегружать маломощную аппаратуру типа сотовых телефонов), для 251-го предлагают выбрать другой UID.

  1. Чтобы защититься от подмены дублета крекером, устройство, регистрирующее дублет, должно по адресу из дублета запросить UID. Решение, предложенное в документации - 30-дневное хранение (andna.pdf, #3.7) - не решает поставленной задачи, не так ли?
  2. Количество байт |H|=const, в то время как количество байт в адресе переменно, он "резиновый". Какова функция отображения H в адрес?

  3. Пока еще не поздно (существует только альфа-версия продукта), унификация и экономия программистских усилий требует, чтобы для всех сервисов (SukuInter, ANDNA, кэширование web-страниц в DHT, раздавание и выкачивание частей файлов через P2P, электронная почта, луковичная маршрутизация, tor/carciofo, все другие будущие сервисы) был использован универсальный повторно используемый формат подобный XML (BinaryXML), а не изобретались частные форматы подобные ANDNA для каждого нового сервиса, не так ли? P.S. К сведению: на передаваемые таким образом xml-элементы удобно вешать триггеры, если складывать элементы в СУБД по мере поступления (см. sql50.euro.ru/sql5.19.2.pdf)

Doublet {hash(UID), address} is stored and updated in "DHT". P.S. Term HashGNode, used in QSPN for cryptography, appears so. Result of hash-function from UID has name H. Device, whose address is equal to calculated H, has name HashNode, or nH. Group, to which HashNode belongs - HashGNode, gH. Group, still active and nearest to HashGNode - RoundedHashGNode, rgH; doublets are stored in all devices of this the last group. Process of coping of doublets to device, appended to RoundedHashGNode, is named as AndnaHook. Devices register no more 250 doublets (to not overburden not powerful equipment like cellular phones), and seggest to imagine other UID for 251-th dublet.

  1. To protect against changing of doublet by cracker, device, registering doublet, should ask UID on base of address from doublet. Decision, proposed in documentation - 30-days storing (andna.pdf, #3.7) - does not solve task, isn't it?
  2. Quantity of bytes |H|=const, while quantity of bytes in address is variable, address is "rubber". What is the function to convert H into address?

  3. While it is not too late (only alpha version of product exists), unification and economy of efforts of software engineers require to use some universal repeatedly-used format like XML (BinaryXML) for all services (SukuInter, ANDNA, cashing of web-pages in DHT, scattering and downloading of parts of files via P2P, email, onion routing, tor/carciofo, all other future services), instead to invent particular format like ANDNA for each new service, isn't it? P.S. For information: it is comfortable to hang triggers on xml-elements, transfered so, if elements are entered into DBMS on arrival (see sql50.euro.ru/sql5.19.2.pdf)

5.

Несколько маршрутов, r называются множеством, R. Множество с одинаковым последним адресом называется классом эквивалентности, r . Класс эквивалентности с одинаковым первым адресом называется букетом. Наилучшим маршрутом B (обозначается заглавной буквой !) является кратчайший. Качество маршрута характеризуется числом REM, которое равно сумме REM для частей маршрута и увеличивается(!), когда качество улучшается. Каждое устройство является роутером. "Таблица маршрутизации" состоит из триплетов [адресат, сосед, REM] (таким образом в таблице не более 256+256*(N-1)=256*N триплетов, где N - количество уровней в "иерархии" устройств, т.е. размер таблицы растет как логарифм количества устройств) и не содержит альтернативных триплетов, указывающих дублирующие маршруты, т.к. обычно все дублирующие маршруты имеют общие части, и обрыв одного маршрута означает обрыв и альтернативных. Таблица состоит из внутренней карты, задающей марштуры к собственным братьям (её частью являются BNode map), и внешней карты, задающей маршруты ко всем предкам и их братьям.

  1. Вероятно, REM не является отрицательным числом - каков же тогда алгоритм его подсчета?
  2. Во внешней карте достаточно триплета для маршрута к родителю, остальные триплеты лишние, не так ли (сообщения идут не поднимаясь по иерархии, а непосредственно между братскими группами; о реорганизации сети перемещающееся устройство может сообщить одновременно с обновлением своего дублета в DHT)?

Several routes, r have name set, R. Set with identical last address has name class of equivalence, r . Class of equivalence with identical first address has name bouquet. The best route B (designated by capital letter !) is the most short. Quality of a route is characterized by number REM, which equal summ of REM for part of route and encreases(!), when quality improves. Each device is a router. "Routing table " consists of triplets [addressee, neighbour, REM] (thus there are no more 256+256*(N-1)=256*N triples in table, where N is quantity of levels in "hierarchy" of devices, i.e. size of table grows as logarithm of quantity of devices), and does not contain alternative triplets, specifing duplicated routes, because usually all duplicated routes have common parts, and break of one route means break of alternative routes too. Table consists of internal map, specifing routes to own siblings (BNode map is part of it), and of external map, specifing routes to all ancestors and their siblings.

  1. Probably, REM is not negative number - so what is the algorithm to calculate it?
  2. In external map, triplet for route to parent is enough, another triplets are redundant, isn't it (messages go not arising in hierarchy, but directly between sibling's groups; moving device can

inform about re-organization of net simultaneously with the update of own dublet in DHT)?

    • Распределение трафика между двумя устройствами по всем возможным маршрутам называется едкой маршрутизацией, CR; сами эти маршруты - едкими букетами, CRT; таблица маршрутизации, хранящая триплеты для всех возможных маршрутов - едкой таблицей. Линия связи, у которой выбрана вся пропускная способность, называется насыщенной. Distribution of traffic between two devices on all possible routes are named as caustic routing, CR; these routes themselves - as caustic bouquet, caustic routing tree, CRT; routing table, storing triplets for all possible routes - as caustic table. Link, whole bandwidth of which is already used, has name saturated.
    • Существует два способа перестроения таблиц маршрутизации - OLSRD для мобильных устройств и QSPN для стационарных. There are two ways to reconstruct routing tables - OLSRD for mobile devices and QSPN for stationary ones.

Functioning along OLSRD

    • временное сообщение: OLSRD должно быть изучено и описано здесь. Сайт olsrd.org (www.olsrd.org), на который ссылается документация, недоступен.
      temporary note: OLSRD should be studied and described here. Site olsrd.org (www.olsrd.org), to which documentation refers, is not available.

Functioning along QSPN

    • Перестроение таблицы маршрутизации осуществляется служебными пакетами следующих разновидностей: tracer package (TP, T), acyclic tracer package (ATP), continuous tracer package (CTP), extended tracer package (ETP). TP, ATP, CTP записывают в себя пройденные адреса. ETP несет в себе таблицу маршрутизации. Все служебные пакеты подвергаются преобразованиям при прохождении устройств до достижения экстремального устройства. TP - преобразованию под названием "групповое правило": [11.22.1, 11.22.80, 11.22.35, 11.44.13, 55.32.20] -> [11.22.*, 11.44.13, 55.32.20] -> [11.*, 55.32.20]. ATP - под названием ациклическое правило: устройство удаляет пакет, если обнаруживает свой идентификатор в нем. CTP - преобразованию под названием "правило интересной информации": устройство удаляет пакет, если обрануживает дублирующийся переход (от устройства к устройству). Для перестроения своей таблицы маршрутизации каждое (!?) устройство порождает служебный пакет и передает его всем своим соседям, те размножают пакет и пересылают всем соседям дальше, таким образом устраивая наводнение (flood). Соответственно существуют TP-наводнение, ATP-наводнение, CTP-наводнение.

      1. Внутреннюю, внешнюю или обе карты несет в себе ETP?
      2. Подвергаются ли служебные пакеты преобразованиям при прохождении устройств _после_ достижения экстремального устройства?
      3. Существует ли ETP-наводнение как отдельное явление?
      4. Что отсутствует в сообщениях о реорганизации сети (см. вопрос Structure.5.2), чтобы сделать наводнения ненужными (i.e. Δ vs. flood)?
      5. Почему недостаточно выполнять наводнения из не-граничных устройств только в пределах группы, а из граничных - в пределах группы и в соседней группе (граничные устройства задерживают пакеты наводнения в своей группе до тех пор, пока наводнение в соседних не будут завершены)? Ведь за пределами групп и соседних групп служебные пакеты собирают одну и ту же информацию.

      Reconstruction of routing table is executed by service packages of the following varieties: tracer package (TP, T), acyclic tracer package (ATP), continuous tracer package (CTP), extended tracer package (ETP). TP, ATP, CTP write gone addresses into themselves. ETP carries routing table in itself. All service packages are subjected to transformation during passing via devices before achievement of extreme device. TP - to transformation under name "group rule": [11.22.1, 11.22.80, 11.22.35, 11.44.13, 55.32.20] -> [11.22.*, 11.44.13, 55.32.20] -> [11.*, 55.32.20]. ATP - under name acyclic rule: device removes package, if has found own identifier in it. CTP - to transformation with name "interesting information rule": device removes package, if has found duplicated hops (from device to device). To reconstruct own routing table, each (!?) device create service package and send it to all own neighbours, which duplicate package and send to all neighbours further, so making flood. Thus TP-flood, ATP-flood, CTP-flood exist.

      1. Internal, external, or both maps are caried in ETP?
      2. Are service packages subjected to transformation during passing via devices _after_ achievement of extreme device?
      3. Exist ETP-flood as separate phenomena?
      4. What is absent in messages about re-organization of net (look at question Structure.5.2) to make floods unnecessary (i.e. Δ vs. flood)?
      5. Why it is not enough to perform floods from not-border devices only inside group, and from border devices - inside group and in neighbour group (border devices delay service packages of own group, until flood in neighbour group will be finished)? You see, service packages collect the same information outside groups and neighbour groups.

#

Для перестроение группы в ней выделяется CoordinationNode; кто из группы им будет - устройства договариваются по принципу P2P. Устройства перемещаются из группы в группу последовательно, по одному, регистрируясь в CoordinationNode; процесс перемещения(!) называется сериализацией. Чтобы не одна группа не стала насыщенной, т.е. для постоянного существования возможности перестроения сети, все группы поддерживаются в состоянии с равным количеством устройств в каждой группе.

  1. Из каких групп или из каких устройств состоит communication vessel?
  2. Что такое компактная группа?
  3. Как вычисляется attraction value?

To reconstruct group, CoordinationNode is assigned in it; who from group will be it - devices decide by principle P2P. Devices are transfered from group into group consecutively, by one, with registration in CoordinationNode; process of transfer (!) has name serialization. That no one group becomes saturated, i.e. for permanent existence of possibility to reconstruct a net, all groups is supported in state with equal quantity of devices in each group.

  1. Of which groups, or of which devices are consist communication vessel?
  2. What is the compact group?
  3. How attraction value is calculated?

#

Для HNode вместе с идентификатором генерируются открытый PubKey и закрытый PrivKey ключи по алгоритму RSA. Устройство, чей адрес равен hash(PubKey), называется CounterNode, cr; оно рассматривается в теории вместо HashNode. На практике вместо HashGNode применяется CounterGNode. В него записываются: PubKey новичка; дуплет, подписанный PrivKey новичка; счетчик, содержащий количество устройств, зарегистрировавших дуплет. TP содержит адреса, подписанные PrivKey устройств, через которые TP прошел.

  1. Зачем нужен счетчик?
  2. Вставка информации в CounterGNode происходит в две итерации: первая зановит дублеты со счетчиками, равными 1; вторая изменяет все счетчики?

  3. Содержимое ATP, CTP, ETP также подписывается PrivKey?

Open key PubKey and close PrivKey are generated by algorithm RSA for HNode together with identifier. Device, whose address equal hash(PubKey), has name CounterNode, cr; it is considered in theory instead of HashNode. On practice, CounterGNode is used instead of HashGNode. PubKey of HNode; dublet, signed by PrivKey of HNode; counter, containing quantity of devices, registered dublet, are written into CounterGNode. TP contains addresses, signed by PrivKey of devices, via which TP has gone.

  1. What counter is necessary for?
  2. Inserting of information into CounterGNode occurs in two iterations: the first enters dublets with counters, equal 1; the second changes all counters?

  3. Content of ATP, CTP, ETP is signed by PrivKey too?

Netsukuku/Documentation (last edited 2010-10-08 09:20:06 by anonymous)