Грузите апельсины чанками

Непониманию основ работы протокола bittorrent и камням в огород Transmission посвящается.

Благодаря наличию удобных клиентов многие сложности и особенности протокола обмена файлами bittorrent скрыты от пользователя. Это хорошо, но в этом удобстве кроются и некоторые подводные камни, т.к. понимание особенностей позволяет лучше разбираться в работе клиентов и помогает оптимально настраивать их под свои нужды.



Не будем вдаваться в глубокие технические дебри и рассмотрим только те аспекты работы, которые нам понадобятся. Внешне процесс обмена прост: один клиент готовит файлы к раздаче, закачивает торрент на сервер и становится на раздачу. Остальные скачивают фалы и присоединятся к раздаче. Остается понять, что есть .torrent файл и зачем он нужен. То, что раздача на торрентах должны быть соответствующим образом подготовлена, не является секретом. Но мы говорим не об оформлении (описании, картинках), а о технической составляющей. Вот .torrent файл и является техническим описанием раздачи. Так вот: в торрентах водку наливают стаканами :), а файлы раздают кусками (chunks). Каждая раздача, состоящая из одного или нескольких файлов, разбивается на куски определенной длины. Если файлов несколько, они какбы сливаются в один непрерывный файл, и потом уже кусается. Описание содержит список файлов, из размеры, и описание всех кусочков: контрольную сумму и какие файлы внутри куска содержатся Во время раздачи и скачивания каждый такой кусочек внутри раздачи получает определенную независимость, т.к. он может быть скачан или роздан независимо от остальных сотоварищей, в том числе и у разных участников раздачи.

В то же время следует понимать, что такая раздача водки только стаканами ведет к ситуации, когда невозможно запросить полтора стакана. Если вам хочется пол-литра в стаканах по 200 грамм, то вы получите именно 3 стакана, половина 3-го будет или пуста, или заполнена тем, что вы не заказывали. Можете пить, можете вылить - ваше дело. Последний пункт объясняет тут ситуацию, когда Transmission скачивает якобы лишние файлы, если вы отметили только несколько из раздачи. Суть в том, что он их получил в силу того, что они содержались в этих самых пол-стаканах. И просто не захотел вылить, на тот случай, если вы надумаете докачивать еще. Клиенты переодически сообщают, а сервер хранит и динамически обновляет информацию о том, какие куски кем были скачаны, у кого и с какой скоростью. Кроме того, сервер владеет данными о версии ПО клиента, его ip адресе

И вот тут начинается шаманство и магия клиента в выборе оппонентов. Т.е. сервер выдал целый список товарищей, кого выбрать? Очевидно, выгодный кандидат должен обладать следующими свойствами

1. Иметь нужный кусок в наличии
2. Иметь хорошую скорость отдачи
3. Иметь небольшую очередь жаждущих

А еще можно немного пошаманить в пределах правил и предпочитать клиентов таких-же версий, дабы стимулировать пользователей пользоваться именно этим клиентом, намекая им на более высокие скорости скачивания и раздачи и, как следствие, более выгодные условия и рейтинг на треккере.. Вот такие субъективные получаются пирожки и стаканы. Вернемся к нашим баранам стаканам. Независимость каждого куска в пределах раздачи и тот факт, что он раздается и скачивается независимо, ведет к тому, что сетевая и дисковая активность процесса обмена весьма высока. Есть определенные способы оптимизации, они успешно применяются, но конечный выигрыш все равно не настолько весом, как этого хотелось. Выбор начального размера кусочка - это тоже определенный простор для оптимизации. Чем меньше размер, тем больше данных необходимо для описания всей раздачи и тем больше телодвижений необходимо произвести для склеивания всех частей в одно целое, но зато при ошибке в одном куске ее легче перекачать заново и тем больше народу момжно вовлечь во всеобщий процесс, а, следовательно, более гибкой и независимой становится вся раздача. Возьмем простенький пример: один файлик размером 4Gb, размер куска - 256Кб, в итоге более 15-ти тысяч кусочков. Что делать в самом начале? Создать нужный файл целиком сразу и потом заполнять данными по мере скачивания? Или создавать куски по мере скачки? Хранить это все в памяти, или выгрузить на диск и подсасывать по необходимости? И тот и другой методы имеют как свои достоинства, так и свои недостатки, баланс тонок и непредсказуем в разных условиях При раздаче такого файла следует иметь в виду, что в теории 15 тысяч человек на том конце интернета могут запросить у вас одновременно каждый свой кусок. Это значит 15 тысяч входящих соединений, 15 тысяч дисковых операций чтения блока.. Понятно, что тут имеет место быть утрирование ситуации, но и на практике не так все радужно. Поэтому многие из torrent-клиентов имеют свои настройки, позволяющие ограничивать скорости скачивания и раздачи, количество одновременно подключенных пиров (соседей) как глобально, так и в пределах одной раздачи.

Раздаем...

В завершении коснемся такой тонкой и эротической стороны вопроса, как процесс раздачи и его эффективность. Как только вы скачали какой-то кусок или присоединились к раздаче целиком, вы потенциально начинаете раздавать этот кусок или все остальные, но следует понимать однозначно, что (ну дабы зря не пенять на зеркало)

• Если этот кусок никому не уже/еще нужен - вы в пролете
• Если среди всех владельцев ваша скорость отдачи ниже - вы в пролете
• Если у других есть и соседние кусочки и их можно забрать в один присест, а у вас их нет - вы в пролете
• Если сервер тормозит и никто о вас еще не знает - вы в пролете

Есть один нюанс, вызывающий самые широкие толкования и самый обширный набор преданий - это так называемый порт торрента и факт его открытости. Предлагаю окончательно поставить все точки над Ï в этом набившем оскомину вопросе. Итак, прежде всего это касается вопроса раздачи, на процесс скачивания это влияет очень мало и очень редко. Сам процесс файлообмена между двумя участниками, образно говоря, бывает двух типов: "сейчас я заберу" и "пульни в меня, а я подхвачу". Первый, как вы понимаете, гораздо проще и короче: установление соединения, запрос, данные в ответ" и все в одном сеансе. Но требует, чтобы ответная сторона была доступна для запросов со стороны жаждущего. Второй сценарий гораздо длиннее: "сервер, передай товарищу xxx, что yyy нужен кусок zzz", но зато xxx может быть недоступен извне, а просьбы забирает сам из очереди. Но даже при таком раскладе одна из сторон, yyy, должны быть доступна, чтобы раздающий xxx мог осуществить передачу данных в ее сторону. Таким образом бывают три варианта развития событий

1. Обе стороны открыты - все отлично
2. Одна сторона открыта - скачивание с открытого ок, раздача со стороны закрытого затруднена, но возможна
3. Обе закрыты - работа невозможна полностью

Для определения, какой категории вы относитесь, прежде всего необходимо узнать, какой тип адресов раздает ваш провайдер. Для этого зайдите по адресу www.myip.ru, страница отобразит адрес, под которым вы выходите в мир интернета. Если ваш адрес принадлежит одному из диапазонов 10.0.0.0 – 10.255.255.255, 192.168.0.0 – 192.168.255.255, 172.16.0.0 – 172.31.255.255 - у меня для вас плохие новости. Раздавать вы сможете, но медленно и печально, редко и не всем. Никакие танцы с бубном и прочие настройки не исправят ситуацию в корне. Аминь. Все остальные могут продолжать чтение Зайдите в настройки сети Transmission и взгляните на статус порта,

Если зеленая лампа указывает на открытый порт, у вас все хорошо с этой точки зрения, а причину проблем следует искать в другом месте. Если вы подключены к интернет при помощи базовой станции AirPort производства Apple (Base, Extreme и прочие, без разницы), установите определенное значение номера порта (выделено красным), включите использование UPnP (выделено зеленым). Соответственно нужно включить поддержку UPnP в базовой станции Опцию случайный порт (отмечено желтым) следует использовать, если torent-клиент запущен на нескольких маках вашей домашней сети Список маршрутеризаторов других производителей, поддерживающих UPnP, можно посмотреть здесь В случае недоступности UPnP, необходимо настроить проброс порта (PortForward, Virtual Server) торрента вовнутрь вручную.

В качестве private и public порта указывается одно и то-же значение, выбранное в клиенте, в качестве ip адреса - внутренний адрес макинтоша в домашней сети Ой.