Дата: 4 сентября 2011 г. 0:37
Тема: Революция в Личных Кабинетах.
Кому: Сергей Пантелеевич Мавроди
Приветствую Вас, уважаемый Сергей Пантелеевич!
Мы разработали концепцию новых кабинетов, так как существующие никуда не годятся:
Пока не введут такое понятие, как "вклад в систему" – кабинеты будут врать. Сейчас они нужны только для лотереи.
Что за "вклад в систему"?
Рассказываю.
Это та сумма денег, которую участник вкладывает в систему за один раз. К примеру, первый вклад в систему = 1000р.
То есть купил он на 300 рублей несколько 20% МММД.
А ещё на 700 рублей несколько 30% МММД(то есть оформил депозит на 3 месяца).
По существу, его рефер ДОЛЖЕН получить 20% от первого вклада, то есть 200р.
В существующих кабинетах – это не реально сделать!
Так как система Вам посчитает бонусные 20% с той операции, которую десятник проведёт первой.
Если десятник проведёт сначала покупку 20%МММД, то в нашем случае рефер получит 20% с 300 рублей и 10% с 700 рублей.
Если десятник проведёт сначала покупку 30%МММД, то рефер получит 20% с 700 рублей и 10% с 300 рублей.
Ни один из этих вариантов не верен, так как рефер должен получить 20% от 1000р. Так как участник внёс именно 1000р!
И это снежный ком неверной информации – так как есть ещё второй уровень реферальных бонусов!
Далее, регистрационный бонус 20$USD.
Самое смешное, что этот бонус тянет за собой начисление реферальных 20% – как будто это первый взнос участника.
Несмотря на то, что это полный бред(так как участник не вложил ни копейки), многие рефы претендуют на 4 доллара с этого бонуса.
А если смотреть правде в глаза, и увидеть, что вчера программисты просто сделали откат базы(с потерей нескольких дней операций) – кошмар творится…
Поэтому в существующих кабинетах следует пользоваться только лотереей.
Ещё рядовой участник может узнать мыло своего сотника и тысячника.
Больше ничего полезного!
Смотрел новости – введение наличных, биржа… Стоп! Основные операции ещё не привели в норму. Поэтому всё расчёты – только на бумажке, в экселе, в документах гугла… Но ни в Личном Кабинете!
Итак, новая система кабинетов:
Думаю, база данных должна быть одна со всеми данными. Только распределена она должна быть по всем клиентам:
- Клиент, стучится к клиенту своего "начальника". Каждый участник знает, кто у него руководитель. Соответственно, при запуске клиента надо ввести свою почту и почту твоего начальника.
- Если у начальника есть запись о таком подчинённом, то он синхронизирует с клиентом ту часть базы, которая относится к данной ячейке. То есть если клиент рядового участника авторизовался у клиента десятника, то клиент десятника передаёт клиенту участника часть базы, где описана вся информация по данной десятке. Если клиент десятника авторизовался у клиента сотника, то десятник сотнику выдаёт полную инфу о своей десятке(обновляя данные у сотника), а сотник отдаёт десятнику инфу по сотне(обновляя данные у десятника). Если клиент сотника авторизовался у клиента тысячника, то сотник тысячнику выдаёт полную инфу о своей сотне(обновляя данные у тысячника), а тысячник отдаёт сотнику инфу по тысяче(обновляя данные у сотника). И так до самого верха.
Таким образом, данные по десятке будут у всех участников десятки, десятника, сотника, тысячника, темника.
Данные по сотне будут у десятника, сотника, тысячника.
Данные по тысяче будут у сотника и тысячника.
Бэкап всей базы по тьме будет у всех обычных участников:
Резервную копию базы по тьме в клиенте темника можно шифрануть, разбить на равные куски, количеством равным кол-во участников/некий коэффициент Х(к примеру – 1000) и раскидать по всем обычным участникам. Пример:
Клиент темника шифрует свою базу(ВСЕ данные по всей тьме), ключ к расшифровке отдаётся тысячникам. Допустим, получилось 200 мегабайт данных. Пусть для ровного счёта в тьме будет ровно десять тысяч обычных участников(не руководителей). Данные об этих участниках есть в базе тьмы. 200 мегабайт делится на 1000(коэф.Х) и получается 200 килобайт – кусочек бэкапа базы. Эти куски базы раскидываются по клиентам обычных участников(всего по 200 килобайт). Таким образом, клиенты обычных участников будут хранить некий "мусор", создавая 10-ти кратную избыточность всей базы.
Взломать её нельзя с обычного клиента, так как там будет храниться только 1 тысячная всей базы, да ещё и шифрованая.
А вот у тысчника появился ещё ключ об бэкапа! Это сделано, чтобы в случае переизбрания темника, клиенты тысячников могли дать темнику ключ для той базы, которую темник может собрать со всех клиентов в виде "мусора".
Причём, после сборки базы воедино, ключ должен поменяться и снова пройти процесс бэкапа.
Можно решить, что мала вероятность появления в сети достаточного кол-ва обычных клиентов, для бэкапа или восстановления базы.
Но тут суть в том, что темник о тьме даёт инфу тысячнику. Пусть в эту инфу подмешивается и наш "мусор".
Тысячник при авторизации сотника – передаст этот "мусор" ниже.
Сотник при авторизации десятника – передаст этот "мусор" ниже.
Десятник при авторизации обычного клиента завершит передачу "мусора" и таким образом закончив бэкап.
Причём можно в клиенте темника видеть в какой стадии находится бэкап.
Меняя коэффициент, можно балансировать между объёмом "мусора" для каждого участника и избыточностью базы.
Вот и получится распределённая база данных. =)
Избыточность базы в моём примере – 10 кратная! То есть каждый кусок находится у 10 разных пользователей. Если этого мало, можно легко увеличить избыточность базы, выбрав другой коэффициент. Более того, кусочки базы спускаются вниз через клиенты руководителей – там тоже можно их хранить, на всякий пожарный.
При взгляде со стороны – это зацикленная пирамида данных. =)
Первую авторизацию клиента можно сделать легко и просто.
При логине в программу-клиент следует указать:
- своё мыло
- мыло своего руководителя
- его ip адрес(можно по телефону узнать или прислать письмом)
Далее участник получает от десятника список ip других участников, других руководителей. И программа хранит это в своём кэше.
Дальнейшая авторизация будет происходить коннектом на предыдущий ip десятника или(в случае неудачи) опросом клиентов из кэша, на предмет нового ip десятника(если у него вдруг нет реального статического ip).
Точно так-же все клиенты вверх по служебной лестнице и авторизуются.
Клиент управляющего он-лайн нужен только для запуска снежного кома(распространения его ip по кэшам клиентов).
Далее клиенты его смогут найти(по кэшу) и он клиентов сможет найти(по своему кэшу).
Если вдруг у него поменялся ip, то найдя хоть одного клиента по ip из своего кэша, он сможет до всех он-лайн клиентов донести свой текущий ip.
Вообще, по сути все клиенты должны по-хорошему общаться друг с другом, обмениваясь следующей информацией:
1. Чат. Ну куда без него? =)
2. "Мусор"(мы ведь помним про децентрализованный, избыточный бэкап всей базы)
3. Кэш ip-клиентов.
4. Про рабочие кусочки базы(для каждого ранга участника со своим допуском, естественно) мы тоже говорили.
В принципе, это всё реально.
Следует заметить, что чем больше участников будет пользоваться данной системой, тем больше будет её отказоустойчивость! =)
Можно при авторизации отдавать всем клиентам ниже рангом некий пароль.
Затем, поменяли ip, снова руководитель входит в сеть, стучится к клиенту ниже рангом – а тот спрашивает "а какой ты пароль в прошлый раз оставил?". Если клиент правильный(а не подставной), то он пароль знает.
Для запутывания следов, можно этот пароль хешировать и раскидывать служебной лестнице вниз(вместе с тем-же бэкапом базы).
Например: тысячник запускает в кафе свой клиент:
1. клиент смотрит свой кэш и находит ip сотников.
2. стучится к ним и сообщает свой последний пароль.
3. клиенты сотника собирают по кусочкам от клиентов-десятников этот пароль и пытаются синхронизировать свои данные с тысячником(в случае удачи).
4. клиент тысячника придумывает новый пароль(на следующую авторизацию) и отдаёт его всем откликнувшимся сотникам.
5. непременным условием должно быть то, что все откликнувшиеся клиенты сотников должны единогласно подтвердить оригинальность своего начальника – то есть клиента тысячника.
В момент отпуска какого-то руководителя ячейки вместо него должен работать его "начальник".
Соответственно эту функцию можно и нужно предусмотреть в новых кабинетах.
Посмотрите историю. На википедии лежит статья о интернет-цензуре в разных странах(в том числе и России).
Прикрыть могут всё, кроме торрентов. С торрент-трекерами пришлось договариваться(об удалении нежелательного контента). Но у них есть всё-же слабое место – сам сервер-трекер. Поэтому надо взять эту идею и допилить по моим выкладкам. Должна получиться настоящая децентрализованная сеть. Сейчас в интернете ведутся наработки по реализации такой отказоустойчивой сети, но у нас есть преимущества:
- количество участников(особенно – программистов)
- финансирование проекта
- действительная важность и востребованность данной сети
Писать новый кабинет надо на языке Java, так как он способен будет работать под ЛЮБОЙ операционной системой!
В настоящий момент мы ищем программистов, которые способны реализовать подобный проект.
Если Вы разместите данную идею в новостях и программисты откликнутся, мы сможем обеспечить техническую стабильность системы.
Мою почту можно не скрывать, основное обсуждение ведётся на форуме http://forummm.ru/viewtopic.php?f=16&t=76&start=10
Комментариев нет:
Отправить комментарий