FTP СИСТЕМА

Мне нужна простая ftp система.Там будут два главных компонента, подробно описанные ниже. Работая вместе в пассивном способе передачи FTP сервер соединится с другим FTP сервером под номером "два" и передаст файлы по частям. Прогер должен быть знаком с Паскалем, Perl, RFC-959 FTP протоколом http://www.freesoft.org/CIE/RFC/959/ и соображать в криптологии. Компоненты сервера должны понимать основной стандарт FTP команд и правильно реагировать на них. Программы должны быть закодированы, чтобы оптимизировать систему, используя схему модуля и соответствующими функциями.Полной оплаты не будет, пока проект не будет сделан на 100 %, и не протестирован на работоспособность. Заказчик соглашается, что одна из исходных разработок, полная и частичная, вместе с компилируемым, будет собственностью покупателя.Качество, быстрое выполнение и добросовестность работы будут вознаграждены.

FTP СЕРВЕР ПОД НОМЕРОМ ОДИН

--------------

Должен быть написан в Delphi или FreePascal и работоспособный на Windows. Программа должна быть "невидима", и иметь опцию запуска только один раз, чтобы не было нескольких одновременных запусков. При удачной посылке партии файлов автоматически серверу два - должно усыпить программу.При ожидании связи, программа должна использовать ресурсы сисемы по минимуму. На Windows XP программа предпочтительно должна работать в фоновом режиме.

Связь должна отвечать на 421 Запрещенный доступ конфигурируемыми 220 сообщениями. Если опция localcopy разрешена, то программа будет ждать команды USR, которая в нашем случае описывает источник данных. Если быть точным, то мы теперь соединимся с сервером два с подтверждением связи (см. ратификацию приложения), иначе мы ответим снова сообщением 421. Если предыдущая исходная дорожка существует SITE SOURCE "$source" "$volume, имя" посылают связанным. Теперь приход FTP команды и данные (описанный в следующей части) будет "передан" серверу два. Справочник приказывает, чтобы CDUP CWD PWD LIST NLIST добрались до сервера два, но если настройки опции localcopy позволяют, мы также изменим текущий местный справочник для более поздней восстанавливающей информации файла САЙТА ATTR . Некоторые основные команды типа SYST, TYPE, RETR,PASV, NOOP будет обработан в местном масштабе вместе с ответами на не поддержанные команды. FEAT (RFC 2389) внесет в список команду MDTM способную установить и читать свойства файла. При получении команды QUIT разъединит от сервера два.

При получении нового STOR делает так, чтобы мы послали SITE DEST "$filname" команду - которая должна сказать серверу два, что мы начинаем с нового файла. Тогда мы будем читать и разбивать поступающие данные в частях по 60.000 байтов (конфигурируемых), или меньше если мы - в конце файла или файл является меньше этогот размера. Теперь мы сожмем (см., что приложение по сжатию) данные и после того будет SHA-256 с 64 байтами http: // en.wikipedia.org/wiki/SHA-1*A_description_of_SHA-256 будет рассчитана и послана серверу два с командой $string. Мы тогда получим одно из двух возможных сообщений от сервера два, указывая находиться ли часть уже в памяти или нет. Если нет, мы продолжим шифрование (приложение crypto метод) и наконец пошлем это серверу два стандарта использования ftp команды типа PASV и STOR. Если посылается новая часть, сервер два должен ответить после того, как передача увенчалась успехом, рассчиталась, расшифровалась и сохранилась с другой стороны. Если неудачно, то мы пробовали бы снова послать часть файла. Этот процесс должен повторяться до тех пор, пока данные файла успешно не переданы серверу два. После того, как файл передан, сервер, который каждый должен послать SITE ATTR с полными признаками файла типа даты создания, защищенности от записи, скрытости и так далее (localcopy=1). В резервном режиме 1 (по умолчанию - 0), часть сначала сжата и зашифрована,рассчитана и послана серверу два.

Все имена файла, директивные названия и дорожки должны также быть зашифрованы (если уровень не 0), когда сервер один и два связывается обоими способами - с маленьким усовершенствованием схемы шифрования. Перед этим шифрованием общее количество от 0 до 256 случайных дополнительных байтов будет вставлено в вереницу данных, содержащую фактическое имя или дорожку наугад. Первый байт говорит, что это специальный байт, появляющийся где-нибудь на названии и представляет случайную последовательность. Например 02 [*?] 02 08 [*?] там 02 - специальный байт, и следующие 08 байтов - только ерунда - случайные байты.

(ini файл, и так далее, отделенный от массы) 220 сообщений ответа система (SYST команда) ответ конфигурируемый порт, для проверки ip маски (каким ip:s позволяется использовать этот сервер) localcopy (0 или 1) serveraddress/hostname или IP:port (ftp сервер два) имя пользователя (-"-) cryptokey cryptolevel (0-512 байтов) backupmode (0 или 1) privatecryptokey (если резервный способ 1) privatecryptolevel (если резервный способ 1) chunksize (60000 по умолчанию) список файлов и или справочников, которые будут автоматически переданы на каждое выполнение

FTP СЕРВЕР НОМЕР ДВА

--------------

Написанный в Perl и работающий под Linux. Для начала посмотрите - http: // search.cpan.org / ~ rwmj/Net-FTPServer-1.122/lib/Net/FTPServer.pm (свободный ftp сервер, написанный в Perl). Используйте MySQL, поскольку база данных и движок хранения - Perl интерфейс и модуль доступны в http://mysql.org.

Сервер будет ждать связи на конфигурируемом порту. Если ip существует в области failedlogin sql , и последний логин был менее тогда 15 минут назад - должен немедленно послать 120 (обслуживание, готовое в nn минуты) сообщение, сопровождаемое 421 ответом запрещенного доступа и закрыть связь. Если нет, то сервер должен ответить с 220 сообщениями и должен спршивать логин.Имя пользователя проверяется в sql таблице пользователей, и если существует,то мы продолжим (см. ратификацию приложения). Отказ логина, включая перерыв, закроет ip,при успешной авторизации будет отмечен в таблице пользователей.

Затем программа будет ждать SITE SOURCE "$source" команда - остановка всего остального с 451 сообщением "451 Ожидание SOURCE команды, нельзя продолжить". Как только эта команда получена, и цепочка данных, содержащие фактические исходные вереницы расшифрованы, программа должна искать дорожку в директивном таблице. Заметьте - sub источник (eq. c:temp2) будет найден, рассматривая от начала корня (eq. c: в базе данных). Если не найдется новым постом, то будет создан в справочнике таблицы. Также - тот же самый источник с различными именами объема должен быть сохранен в отдельных постах. Нормальное дерево с одним sub справочником будет включать следующие посты. 1 пост корня (rooid.directory=0, название directory=$rootsourcename, nextlevel=$x, пользователь directory=$currentuser, servertimestamp.directory=$timestamp, attr.directory=$volymename) 1 корень выравнивает пост - с subdirecoty, больше постов с тем же самым $x - они лучше, если больше подсправочников или файлов на этом уровне (rooid.directory=$x, названии directory=$directoryname, nextlevel=$y; вложения в этом справочнике, directory=$currentuser, timestamp.directory=$timestamp, servertimestamp.directory=$timestamp, attr.directory=$attr). Возможно будет росматривание с CDUP и командой CWD.

Когда сервер, у которого запрашивают директивные списки, информационный файл или что-то подобное,то сервер под номером два должен послать первому файл или список начинающийся с поста корня как описано выше. Заметьте только последний файл, или директивная версия должны быть видимы (проверка timestamp области), и любое действие типа замен признака файла или DTM должно применяться на эту версию. Эти две вкладки не должны конечно быть видимы при нормальных обстоятельствах. Если послали специальный SITE DEST команды DEST , мы готовы принять новый файл. После того мы создадим новый вход в директивной таблице, поле rootlevel, заполненная от nextlevel области - в зависимости от исходной дорожки и предыдущих директивных команд (сервер одно позиция в "дереве"). За дополнительной информацией о передаче частей, см. на сервере.

Пожалуйста обратите внимание, что мы сохраняем новый вход на каждый файл для каждой сессии, но и показ последней версии копии, смотрящей на timestamp. Каждая часть id для файла сохранена в области частей в директивной таблице, что позволяет восстановить любую версию файла. Новая часть (не существующий в базе данных) расшифрована, если резервный способ 0, но если способ 1 - и способ сохранён в области backupmode. Если sub справочник удален и позже создан снова (то же самое имя) с MKD делает новую запись - отделяет от старой nextlevel в справочниках. Наконец программа сервера должна иметь опцию сохранения любого внесения в список справочника и файлов.Для хранения в уменьшенном сжатом формате возможно нужен отдельный perl сценарий.

ПРИЛОЖЕНИЕ - SQL ТАБЛИЦЫ

------------------------

failedlogin

> ip

> timestamp

пользователи

> имя пользователя

> maxchunks (максимальные части, созданные пользователем, сервер два

> должен ответить 552 если превышено) maxfiles (максимальное число

> файлов в хранении, сервер два должен ответить 552 если превышено)

> uniquechunksused (число уникальных частей, созданных пользователем)

> totalchunksused (число} полных частей, связанных пользовательскими

> файлами) numberofbackupsfilescurrentlyinstorage (см. файлы Макса)

> cryptokey cryptolevel (0-512 байтов) lastlogin (будет обновлен после

> каждого успешного логина) lastbackup (servertime) numberofdays

> (увеличенный на тот всякий раз, когда новый резервный отличаются от

> последнего резервного) userid

Части

> hashvalue (в расшифрованном формате)

> данные (сжатый, но расшифрованный если используется резервный способа

> 0 - иначе зашифрованный) numberofrepeatedusage (увеличивается каждый

> раз, когда эта часть содержится в файле)

Директория

> rootid (всегда 0 на исходном корне, или с увеличивающемся с уникальным

> номером для каждого нового созданного уровня) имя (источник, файл или

> директивное название) nextlevel (если это - справочник, sub уровень

> может быть достигнут с пользователем ВЫБОРА = $user И rootid =

> nextlevel.value) пользователь (владелец соединился с userid в таблице

> пользователей) timestamp (timestamp полученный от сервера один с FTP

> DTM команда) servertimestamp (наш внутренний timestamp, когда этот

> пост был создан, должен быть универсальный формат yymmddhhss) attr

> (оригинал приписывает от сервера один, SITE ATTR) backuptype (0 или 1)

> разделенная область для будущего использования части (" *DEL * " если

> удалено, то файл оценивает в единственном ряде за каждую часть данных

> в пределах этого) totalsizeinbytes (файлы только, может отличаться от

> числа{номера} байтов, содержавшихся в кусках, из-за сжатия)

ПРИЛОЖЕНИЕ - БЫСТРОЕ СЖАТИЕ

------------------------

Чтобы сохранить некоторую полосу пропускания и уход от некоторых образцов, каждый пакет с данными куска файла должен быть сжат. Каждый байт в потоке данных - по сравнению с предыдущим и если 4 или больше байта те же самые, мы удалим их от потока и вместо этого добавим кодексы для них в списке, который должен быть добавлен в конец в начале потока данных. Конец *00 марок Op-кодекса списка (поток данных следует) *01, говорит, что число повторений - 2-байтовое слово после этого op-кодекса, иначе *04-FF говорит число копий. Следующий байт - тот, которые повторные и следующие два байта отвечают первоначальному размещению, куда повторные байты были помещены в поток данных, и так далее. Вот - небольшой пример; 06 2A 00 02 00 65 01 03 4F - переведет к 65 01 2A 2A 2A 2A 2A 2A 03 4F.

ПРИЛОЖЕНИЕ - РАТИФИКАЦИЯ

---------------------------

Вместо отдельного пароля сервера один и два должны обеспечить идентификацию, используя некоторую ратификацию. В то же самое время сервер, который должен сказать серверу два, какие crypto выравнивают эту сессию, будет использовать, если файлы рассматривают типом резервного способа 0 или 1. Схема должна быть сейфом криптологии i.o. Эта часть, в которой я полностью не уверен,не знаю как проектировать, но есть несколько примеров в сети. Я думал использовать некий один пароль времени. Сервер два начинает с вопроса о пользователе, проверенном с sql пользователями таблицы. После того, как принятый сервер два выберет случайный пароль, читая x байты от потока и зашифрует один пароль времени с нашим секретным паролем. Зашифрованные данные - показаnm как текст в 331 (Пользователь Авторизирован, Требуемый Пароль), сообщение 331 Входит в один пароль времени к серверу который расшифровывает пароль и возвращение байтов от потока. Конечно ответ от сервера каждый также зашифрован. Проблема состоит в том, что эта схема работает однобоко - как будет сервер знать, что сервер номер два является подлинным и какой будет сервер номер один набор, crypto и г резервный способ? Это - к программисту, берущегося этот проект.

ПРИЛОЖЕНИЕ - CRYPTO МЕТОД

------------------------

Программное обеспечение сервера должно использовать форму шифра потока, при передаче частей, файла или директивных имен (не команды!) как было объяснено ранее. Байты от потока добавляются или xored к байтам, которые будут зашифрованы. Это сделано с секретной ключевой долей и cryptographically обеспечивают псевдослучайный генератор чисел по имени ISAAC. Пример и для Паскаля и для Perl есть здесь http://burtleburtle.net/bob/rand/isaacafa.html. Также каждый пакет (максимальная длина равняется конфигурируемому размеру части), будет зашифрован. Используя уникальный "ключ сообщения", который был создан в управляемое время с соединением текущего времени системы в микросекунды, программирует случайная функция и ISAAC. Ключ сообщения зашифрован непосредственно с секретным ключом и добавлен в конец к пакету. Секретная ключевая нить (ini файл в сервере один и в таблице пользователей) должна быть представлена как hexadecimal число любой длины. Это число уменьшено к длине 0 (выключенный) к 512 битам, в зависимости от уровеня потока crypto как и определено в ini-файле.

Тип Работы:

Delphi

Perl/CGI

==============

БЕЗ ПРЕДОПЛАТЫ