|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Этот текст мог стать продолжением цикла статей "Разделяй и властвуй". Но
кое-что изменилось, в голову пришли более интересные идеи по организации
процесса плетения сетей. Поэтому эта статья оставлена для общего развития,
возможно кого-то она натолкнет на новые мысли.
Вот и подошла очередь разговоров об организации сети. Если ты не являешься
большим ценителем бреда на компьютерную и околокомпьютерную темы, можешь
пропустить прочтение этой статьи. А зачем публиковать бред? Э-э-э, брат.
Тематический бред является полезной штукой, он позволяет сразу увидеть все
нестыковки... Польза тут есть.Но если ты для себя твердо знаешь,как правильно
плести сети, то смотри другую (не бредовую) статью. Там ты познакомишься с
МОЕЙ точкой зрения.А тут мы немного порассуждаем...Это пока только разговоры,
но ведь и пресловутый протокол HTTP был придуман не сразу, да и очевидным его
не назовешь. А почему он такой, причем для всех одинаковый? Все дело в RFC.
Request For Comments,а по-русски это можно озвучить как "спецификация".А наша
текущая задача - создать спецификацию для работы нашей софтинки с сетью.
Вообще-то основных путей развития только два: централизованная сеть с
выделенным сервером и децентрализованная сеть. В первом случае адрес сервера
зафиксирован, а он сам играет роль диспетчера заданий.
Во втором случае все машины равноправны. Но тут тоже есть нюансы. Самым
утопическим кажется "коммунистический" подход к распределению заданий. Т.е.
каждая машина принимает на выполнение любые задания (естественно, не более 1
задания от 1 машины при данном подходе). Он хорошо реализуем только в малых
масштабах сети. А т.к. планируется, что сеть распределения вычислений будет
насчитывать не менее сотни машин, то в один "прекрасный" момент все рухнет.
Более уместным я считаю "капиталистическую" модель, при которой будет
производиться обмен заданиями (во избежание мошенничества с отправкой ложных
отчетов и тд можно ввести уровни доверия и соотношения принимаемых/отсылаемых
заданий для любой пары групп). Естественно, эта модель только кажется
децентрализованной. На самом деле, подразумевается, что на каком-либо сайте
будет создан специальный cgi-скрипт (вариант: irc-бот), который позволит
вносить адреса онлайн-участников в базу данных, получить адреса других
участников для обмена заданиями и т.д. Только в этом случае не обязательно
владение сервером. Вариант со скриптом, наверно, будет более безотказен, т.к.
мы сами были свидетелями стойких глюков у сети irc-серверов, в которой
существовал (да и сейчас существует) канал "SunlimiteD team".
Таким образом, на сервере должен быть скрипт, выдающий примерно такой
HTML-документ на пустой запрос (знаки подчерка заменяют пробелы):
<!--
CompName1______7255.255.255.001
LongerCompName23255.255.255.088
ShortCN3_______1080.080.080.080
-->
<html>
<table>
<tr>
<td>
CompName1
</td>
<td>
255.255.255.001
</td>
<td>
Rank: 7
</td>
</tr>
<tr>
<td>
LongerCompName2
</td>
<td>
255.255.255.088
</td>
<td>
Rank: 3
</td>
</tr>
<tr>
<td>
ShortCN3
</td>
<td>
080.080.080.080
</td>
<td>
Rank: 1
</td>
</tr>
</table>
</html>
В итоге получаем страницу,удобочитаемую в браузере пользователя и удобную для
разбора программой. Конечно,тогда IP участников будут "засвечены",но тут есть
несколько доводов:
1. Взлом хешей сам по себе противоправным действием не является
2. При хорошей распространенности программы будет довольно большое количество участников, среди которых будет сложно найти нужных кому-либо людей
3. Записи из базы будут выбираться случайным образом
4. Новые адреса будут выдаваться не чаще, чем через время, равное периоду обновления информации об участнике (т.е. 10-20 минут)
Но в варианте с использованием irc-бота также не приходится говорить об
анонимности.
Эти n записей выбираются из таблицы случайным образом,причем одинаковое число
записей для каждого ранга (если необходимое количество машин данного ранга
есть в онлайне). Я рекомендовал бы выдавать по 5 машин каждого ранга. Этот же
скрипт может регистрировать машину, вышедшую в онлайн (скажем, в параметрах
request=online, ip, name и pass передавать свои ip, логин и хеш пароля каждые
10-20 минут). Данный скрипт можно использовать также и для регистрации
запросов на обработку (request=srcreq,srcname - имя отправителя,srcpass - хеш
пароля отправителя, srchash - хеш текста задания (для идентификации задания))
и подтверждения запросов (request=dstnreq,dstnname - имя обработчика,dstnpass
- хеш пароля обработчика,dstnhash - хеш текста задания). При получении одного
из этих запросов, в базе данных ищется парный ему. Делается общая запись,
которая хранится некоторое время (например, 72 часа), исходные 2 записи
удаляются. Если в течение этого времени жалоб у отправителя нет, то запись
удаляется. Все остальные вопросы (например, разбор неочевидных споров) можно
будет рассмотреть при работе непосредственно над правилами сети. После
выполнения задания отправляется еще пара подтверждений выполнения
(request=srcans, srcname - имя обработчика, srcpass - хеш пароля обработчика,
srchash - хеш текста задания и request=dstnans, dstnname - имя обработчика,
dstnpass - хеш пароля обработчика, dstnhash - хеш текста задания). Они
обрабатываются так же, как и запросы на обработку.
Итого, в базе данных должно быть таблиц:
1. Таблица логинов и хешей (поля: логин, ранг, хеш)
2. Таблица онлайн-участников (поля: логин, ip, время подтверждения статуса онлайн)
3. Таблица запросов (поля: тип запроса, логин, хеш текста задания, время получения запроса)
4. Таблица выполнения запросов (поля: тип сообщения, логин отправителя, логин обработчика,хеш текста задания,время получения запроса отправителя, время получения запроса получателя)
5. Таблица жалоб (поля: логин отправителя, логин обработчика, хеш текста задания, время получения запроса отправителя, время получения запроса получателя, время получения отчета отправителя, время получения отчета получателя, время поступления жалобы)
6. Таблица перевода количества заданий между группами (поля: номер 1й группы, номер 2й группы, соотношение 1й ко 2й)
7. Таблица получения информации об участниках (поля: имя участника, время запроса)
Примечание. Чтобы не позволить БД разрастись до колоссальных объемов,
предполагается НЕ ВЕСТИ историю расчетов между пользователями. Т.е. если по
таблице обмен 1:5,а у второго участника только 4 свободные ячейки под задания,
то первый может согласиться и на обработку 4 заданий, при этом никаких долгов
второму участнику не начисляется.
Примеры запросов:
Скрипт: script.cgi
Параметры: нет
Определяется ip участника, вызвавшего скрипт. В таблицах 2 и 7 удаляются все
записи с временем подтверждения статуса онлайн меньшим, чем текущее время
минус 10 (20) минут. Из таблицы 2 выбирается запись с ip, совпадающим с ip
участника, вызвавшего скрипт. Если такой записи нет, то генерируется страница
с ошибкой "Не онлайн". Если в таблице 7 есть запись об участнике с таким
именем,от генерируется страница с ошибкой "Попробуй позже". Иначе в таблицу 7
заносится имя участника и текущее время. Случайным образом выбираются по m
участников каждого ранга и генерируется обычная страница.
Скрипт: script.cgi
Параметры: request=online, ip=7.15.10.20, name=AtariMan, pass=XfHg.iMOLAfIn
Из таблицы 1 выбирается запись с полями логина и хеша из запроса. Если такой
записи нет, то генерируется страница "Неправильный логин". Иначе в таблицу 2
вносится соответствующая запись. Генерируется таблица "Логин успешен".
И т.д.
Но самое важное - обмен заданиями. После получения адреса обработчика,
отправитель самостоятельно "договариваеся" относительно выполнения задания.
Механизм взаимодействия я вижу так:
а) К обработчику подсоединяется отправитель и отсылает запрос на обработку некоторого количества заданий
б) Обработчик с помощью скрипта проверяет, имеет ли отправитель права на выполнение такого количества заданий обработчиком. Если нет, количество снижается в соответствии с квотами
в) Резервируется необходимое количество ячеек.Если количество свободных ячеек меньше количества заданий, то отправитель выбирает, подходит ли ему такой обмен
г) Если в течение 3 минут в зарезервированные ячейки не поступили задания, то они освобождаются
д) После отправления заданий скрипту передается запрос на обработку
е) После приема заданий скрипту передается запрос на выполнение
ж) Отправитель отсоединяется
Возможно, я тут написал очень много лишнего, где-то запутался, упустил что-то
важное...Но ведь это еще не спецификация,а только ее черновик,причем черновик
описанный одним человеком. Поэтому всем, у кого появилась на этот счет хоть
одна идея,предлагаю принять участие в обсуждении. Все слать на ящик журнала -
[email protected] (предпочтительно) или постить в форум команды "Acolytez"
(http://forum.acolytez.com).
Bye.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
