Основная цель: написать до конца семестра торрент-трекер (консольное приложение) и торрент-клиент (GUI)
- 04.04.2016 23:59: Консольный прототип (клиент + сервер)
- На трекере хранится список файлов и информация об активных на данный момент пользователях, у которых есть те или иные файлы (возможно не целиком).
- С помощью клиентского приложения можно просматривать список файлов на трекере, а также добавлять новые и выбирать файлы из списка для скачивания.
- Файлы условно разбиваются на последовательные блоки бинарных данных константного размера (например 10M). Последний блок может иметь меньший размер. Блоки нумеруются с нуля.
- Клиент при подключении отправляет на сервер запрос update, обновляя список раздаваемых им файлов.
- При скачивании файла клиент получает у трекера информацию о клиентах, раздающих файлы (сидах), и далее <<общается>> с ними напрямую.
- У отдельного сида можно узнать информацию о том, какие полные части у него есть, а также скачать соответствующие части.
- После скачивания отдельных блоков некоторого файла клиент также становится сидом.
-
Хранит мета-информацию о раздаваемых файлах:
- идентификатор
- активные клиенты (недавно был update), у которых есть этот файл целиком или некоторые его части
-
Порт сервера: 8081
-
Запросы:
- list — список раздаваемых файлов
- upload — публикация нового файла
- sources — список клиентов, владеющих определенным файлов целиком или некоторыми его частями
- update — загрузка клиентом данных о раздаваемых файлах
- Сервер хранит список файлов (вместе с идентификаторами) между запусками
Формат запроса:
<1: Byte>
Формат ответа:
<count: Int> (<id: Int> <name: String> <size: Long>)*,
count — количество файлов
id — идентификатор файла
name — название файла
size — размер файла
Формат запроса:
<2: Byte> <name: String> <size: Long>,
name — название файла
size — размер файла
Формат ответа:
<id: Int>,
id — идентификатор файла
- Если клиент А и клиент Б решили опубликовать файл abc.txt, то это будут разные файлы, иными словами каждый запрос на публикацию файла возвращает новый id
Формат запроса:
<3: Byte> <id: Int>,
id — идентификатор файла
Формат ответа:
<count: Int> (<ip: ByteByteByteByte> <port: Short>)*,
count — количество клиентов, раздающих файл
ip — ip клиента
Формат запроса:
<4: Byte> <seed_port: Short> <count: Int> (<id: Int>)+,
count — количество раздаваемых файлов,
id — идентификатор файла
Формат ответа:
<status: Boolean>,
status — True, если информация успешно обновлена
- Клиент обязан исполнять данный запрос каждые 60 секунд, иначе сервер считает, что клиент ушел с раздачи
-
Порт клиента конфигурируется через пользовательский интерфейс и передаются на серверв рамках запроса update.
-
Каждый файл раздается по частям, размер части — константа на всё приложение
-
Клиент хранит и раздает эти самые части
-
Запросы:
- stat — доступные для раздачи части определенного файла
- get — скачивание части определенного файла
Формат запроса:
<1: Byte> <id: Int>,
id — идентификатор файла
Формат ответа:
<count: Int> (<part: Int>)*,
count — количество доступных частей
part — номер части
- Часть считается доступной для раздачи, если она хранится на клиенте целиком
Формат запроса:
<2: Byte> <id: Int> <part: Int>
id — идентификатор файла,
part — номер части
Формат ответа:
<content: Bytes>,
content — содержимое части
- Maven/Gradle проект
- Консольные трекер и клиент, позволяющие исполнять указанные запросы
- Тесты
- Клиент должен сохранять информацию о раздаваемых файлах между перезапусками, трекеру это делать необязательно
- Разрешается использовать библиотеки для упрощения ввода-вывода
- Рекомендуется взглянуть на DataInputStream и DataOutputStream
- То, как пишутся и читаются данные из потока, определяется реализацией DataInputStream и DataOutputStream
- Для передачи типа String используется алгоритм DataOutputStream.writeUTF
- IP адреса передаются как четыре последовательных байта: 127.0.0.1 -> 127/0/0/1