Пишем свой BitTorrent клиент на Go
Перевод “Building a BitTorrent client from the ground up in Go”
Что происходит с момента визита на thepiratebay и появлением mp3 файла на вашем компьютере? В этом посте мы реализуем BitTorrent протокол на достаточном для скачивания образа Debian уровне. Можете сразу посмотреть исходный код и пропустить все подробные объяснения. Можете начинать с исходного кода и потом переходить к подробным объяснениям.
BitTorrent это протокол для скачивания файлов и распространения их через интернет. В отличие от традиционного клиент-серверного взаимодействия(например, просмотров фильмов на Netflix или загрузка интернет страничек), участники BitTorrent сети, которые называются peer'ами, скачивают части файлов друг с друга. Такое взаимодействие называется peer-to-peer протоколом. Мы разберемся как он работает, и напишем свой собственный клиент, который сможет находить peer'ы и обмениваться с ними данными.
Последние 20 лет протокол эволюционировал. Различные организации и разработчики расширяли его и добавляли новые функции для шифрования, частных торрентов и новых способов поиска peer'ов. Мы реализуем оригинальный протокол 2001 года, чтобы наш учебный проект оставался маленьким и реализуемым за одни выходные.
Для экспериментов будем использовать Debian ISO как подопытного кролика. Это большой файл, но не огромный: 350мб.
Поиск peer'ов
И так, нам нужно скачать файл с помощью BitTorrent. Но это peer-to-peer протокол и пока мы понятия не имеем, где найти peer'ов для скачивания. Похоже на переезд в новый город и поиск новых друзей: вы можете познакомиться в баре поблизости или на каком ни будь митапе. Эта идея лежит в основе централизованных трекеров, которые позволяют peer'ам знакомиться друг с другом. Как правило, это обычные серверы, работающие через HTTP. Например, образ Дебиана есть тут http://bttracker.debian.org:6969/
Такие централизованные серверы подвергаются нападкам со стороны правообладателей. Возиожно, вы читали про трекеры TorrentSpy, Popcorn Time и KickassTorrents, которые были закрыты за распространение нелегального контента. Сегодня уже существуют методы поиска peer'ов без посредников: одноранговый распределенный поиск. Мы не будем реализовывать эти алгоритмы, но если вам интересно - почитайте про DHT, PEX и магнет ссылки.
Разбор .torrent файла
В .torrent файле содержится информация о трекере и о самом файле, который нужно скачать. Для начала скачивания этого достаточно. Дебиановский .torrent файл выглядит так:
d8:announce41:http://bttracker.debian.org:6969/announce7:comment35:"Debian CD from cdimage.debian.org"13:creation datei1573903810e9:httpseedsl145:https://cdimage.debian.org/cdimage/release/10.2.0//srv/cdbuilder.debian.org/dst/deb-cd/weekly-builds/amd64/iso-cd/debian-10.2.0-amd64-netinst.iso145:https://cdimage.debian.org/cdimage/archive/10.2.0//srv/cdbuilder.debian.org/dst/deb-cd/weekly-builds/amd64/iso-cd/debian-10.2.0-amd64-netinst.isoe4:infod6:lengthi351272960e4:name31:debian-10.2.0-amd64-netinst.iso12:piece lengthi262144e6:pieces26800:(binary blob of the hashes of each piece)ee
Данные в .torrent файле закодированы в формате Bencode и нам нужно его декодировать.
В bencode такие же типы как в JSON: строки, числа, списки и словари. Данные в формате bencode, в отичии от JSON, не особо человеко-читаемые. Но такой формат очень удобен для бинарных данных и потокового чтения. Строки начинаются с префикса, в котором указана длина, и выглядят так 4:spam. Числа начинаются и заканчиваются маркерами, например 7 будет выглядеть как i7e. Списки и словари очень похожи: l4:spami7ee это ['spam', 7], а d4:spami7ee означает {spam: 7}.
Если отформатировать наш .torrent файл, то все становится намного понятней:
d
8:announce
41:http://bttracker.debian.org:6969/announce
7:comment
35:"Debian CD from cdimage.debian.org"
13:creation date
i1573903810e
4:info
d
6:length
i351272960e
4:name
31:debian-10.2.0-amd64-netinst.iso
12:piece length
i262144e
6:pieces
26800: (binary blob of the hashes of each piece)
e
e
Из этого файла можно узнать URL трекера, имя и размер файла, дату создания(в unix формате), размер частей(piece length) на которые разбит нужный нам файл. Кроме этого, в файле есть большой кусок бинарных данных, в котором содержаться SHA-1 хэши всех частей(pieces). Размер частей для разных торрентов может быть разный, но, как правило, в пределах 256KB и 1MB. Большой файл может состоять из тысяч частей. Нам нужно скачать каждую часть с наших peer'ов, проверить хэши по нашему торрент файлу, собрать эти части вмести и готово!
Такой механизм позволяет проверить отдельно каждую часть файла и защититься от случайного и намеренного повреждения файла. Если злоумышленник не взломал SHA-1, то мы получим тот файл, который ожидаем.
Было бы прикольно написать свой bencode парсер. Но хочется сконцентрироваться на важных вещах, поэтому будем использовать готовый парсер github.com/jackpal/bencode-go. А если вы хотите получше разобраться с bencode форматом - посмотрите парсер от Fredrik Lundh в 50 строчек кода.
1import (
2 "github.com/jackpal/bencode-go"
3)
4
5type bencodeInfo struct {
6 Pieces string `bencode:"pieces"`
7 PieceLength int `bencode:"piece length"`
8 Length int `bencode:"length"`
9 Name string `bencode:"name"`
10}
11
12type bencodeTorrent struct {
13 Announce string `bencode:"announce"`
14 Info bencodeInfo `bencode:"info"`
15}
16
17// Open parses a torrent file
18func Open(r io.Reader) (*bencodeTorrent, error) {
19 bto := bencodeTorrent{}
20 err := bencode.Unmarshal(r, &bto)
21 if err != nil {
22 return nil, err
23 }
24 return &bto, nil
25}
Я стараюсь оставлять структуры максимально плоскими и отделять структуры сериализации от структур приложения. Поэтому я сделал экспортируемой другую, более плоскую структуру TorrentFile и добавил несколько методов для преобразования между ними.
Обратите внимание, я разбил pieces (во внутренной структуре это обычная строка) на список хэшей по 20 байт. Так с ними будет проще работать. И вычислил общий SHA-1 хэш всего bencode закодированного словаря info(в котором содержится имя, размер и хэши всех частей). Этот общий хэш будет работать как идентификатор и понадобится для взаимодействия с трекером и peer'ами. Об этом чуть позже.
1type TorrentFile struct {
2 Announce string
3 InfoHash [20]byte
4 PieceHashes [][20]byte
5 PieceLength int
6 Length int
7 Name string
8}
9
10func (bto *bencodeTorrent) toTorrentFile() (*TorrentFile, error) {
11 // ...
12}
Получаем peer'ов через трекер
Теперь у нас есть информация о файле и трекере, давайте сделаем запрос на сервер чтобы объявить(announce) о нашем присутствии как peer’a и получить список других peer'ов. Для этого нужно сделать GET запрос на announce URL трекера с нужными параметрами:
1func (t *TorrentFile) buildTrackerURL(peerID [20]byte, port uint16) (string, error) {
2 base, err := url.Parse(t.Announce)
3 if err != nil {
4 return "", err
5 }
6 params := url.Values{
7 "info_hash": []string{string(t.InfoHash[:])},
8 "peer_id": []string{string(peerID[:])},
9 "port": []string{strconv.Itoa(int(Port))},
10 "uploaded": []string{"0"},
11 "downloaded": []string{"0"},
12 "compact": []string{"1"},
13 "left": []string{strconv.Itoa(t.Length)},
14 }
15 base.RawQuery = params.Encode()
16 return base.String(), nil
17}
Что тут важно:
info_hash- идентифицирует файл, который мы хотим скачать. Это хэш, который мы вычислили раньше по словарюinfo. Трекеру нужно знать этот хэш, чтобы показать нам правильных peer'ов.peer_id- 20-ти байтное имя, которое идентифицирует нас на трекере и для других peer'ов. Используем случайно сгенерированную последовательность. Реальные BitTorrent клиенты используют идентификаторы вида-TR2940-k8hj0wgej6ch, в котором закодированы используемая программа для скачивания и ее версия. В нашем примере, TR2940 это клиент Transmission версии 2.94.
Разбираем ответ трекера
В ответе от сервера приходят bencod закодированные данные.
d
8:interval
i900e
5:peers
252:(another long binary blob)
e
Поле interval указывает как часто мы можем делать запрос на сервер для обновления списка peer'ов. Это значение в секундах(900 секунд = 15 минут).
Поле peers - это большой кусок бинарных данных, в котором содержаться IP адреса каждого peer'а. Его нужно разбить на группы по 6 байтов. Первые 4 байта - это IP адрес узла, последние 2 байта - порт(uint16 в big-endian кодировке). Big-endian(или сетевой порядок) означает, что можно интерпритировать целое число как группу байтов, просто составляя их по порядку слева на право. Например, байты 0x1A, 0xE1 будут кодироваться в порядке 0x1AE1 или 6881 в десятичном формате.
1// Peer encodes connection information for a peer
2type Peer struct {
3 IP net.IP
4 Port uint16
5}
6
7// Unmarshal parses peer IP addresses and ports from a buffer
8func Unmarshal(peersBin []byte) ([]Peer, error) {
9 const peerSize = 6 // 4 for IP, 2 for port
10 numPeers := len(peersBin) / peerSize
11 if len(peersBin)%peerSize != 0 {
12 err := fmt.Errorf("Received malformed peers")
13 return nil, err
14 }
15 peers := make([]Peer, numPeers)
16 for i := 0; i < numPeers; i++ {
17 offset := i * peerSize
18 peers[i].IP = net.IP(peersBin[offset : offset+4])
19 peers[i].Port = binary.BigEndian.Uint16(peersBin[offset+4 : offset+6])
20 }
21 return peers, nil
22}
Скачивание с peer'ов
Теперь у нас есть список peer'ов. Настало время соединиться с ними и начать скачивать части файла. Этот процесс можно разбить на несколько этапов. Для каждого peer'а нужно:
- Начать TCP соединение c peer'ом. Это как начать телефонный разговор.
- Выполнить двухсторонний BitTorrent хендшейк. “Hello?” “Hello."
- Обмен сообщениями для скачивания частей файла. “Мне нужна часть №231, пожалуйста.”
Начинаем TCP соединение
1conn, err := net.DialTimeout("tcp", peer.String(), 3*time.Second)
2if err != nil {
3 return nil, err
4}
Тут используется таймаут для соединения, чтобы не зависать долго на попытках подключения к peer'ам.
Выполняем хендшейк(рукопожатие)
Мы подключились к peer'у, но теперь нежно выполнить рукопожатие, чтобы убедится
- Peer может взаимодействовать по BitTorrent протоколу
- Может понимать ниши сообщения и отвечать на них
- Знает про файл, который мы хотим скачать
Мой старик отец как-то сказал мне, что секрет хорошего рукопожатия в его крепкость и зрительном контакте. Для хорошего BitTorrent рукопожатия тоже нужно знать несколько секретов:
- Длина идентификатора протокола всегда 19 (0x13 в hex)
- Сам идентификатор, который называется pstr, всегда
BitTorrent protocol - Восемь зарезервированных байтов, которые используются для указания расширенных возможностей. В нашем случае - все выставлены в 0.
- Хэш для идентификации файлов(infohash, инфохэш), который мы вычислили раньше.
- Идентификатор нашего peer'а.
Собираем все вместе. Наш хендшейк выглядит так:
\x13BitTorrent protocol\x00\x00\x00\x00\x00\x00\x00\x00\x86\xd4\xc8\x00\x24\xa4\x69\xbe\x4c\x50\xbc\x5a\x10\x2c\xf7\x17\x80\x31\x00\x74-TR2940-k8hj0wgej6ch
После отправки хендшейка, в ответ ожидаем получить аналогичную строку. Инфохэш, который мы получили в ответе, должен совпадать с нашим - так мы будем знать что говорим об одном и том же файле. Если все прошло хорошо, то переходим к следующему этапу. Если нет, то можем повторить, а если ошибки повторяются, то просто разрываем соединение.
Давайте реализуем структуру для хендшэйка и несколько дополнительных методов для сериализации и чтения.
1// A Handshake is a special message that a peer uses to identify itself
2type Handshake struct {
3 Pstr string
4 InfoHash [20]byte
5 PeerID [20]byte
6}
7
8// Serialize serializes the handshake to a buffer
9func (h *Handshake) Serialize() []byte {
10 pstrlen := len(h.Pstr)
11 bufLen := 49 + pstrlen
12 buf := make([]byte, bufLen)
13 buf[0] = byte(pstrlen)
14 copy(buf[1:], h.Pstr)
15 // Leave 8 reserved bytes
16 copy(buf[1+pstrlen+8:], h.InfoHash[:])
17 copy(buf[1+pstrlen+8+20:], h.PeerID[:])
18 return buf
19}
20
21// Read parses a handshake from a stream
22func Read(r io.Reader) (*Handshake, error) {
23 // Do Serialize(), but backwards
24 // ...
25}
Отправка и получение сообщений
Как только мы выполнили руопожатие, можем посылать и получать сообщения. Ну не совсем. Пока peer не согласится принимать сообщения, то нет смысла ему что-то отправлять. Сейчс мы считаемся “задушенными”(choked) для других peer'ов. Они должны отправить нам сообщение unchoke итолько после этого мы сможем отправлять им сообщения и запрашивать у них данные. По умолчанию, считаем что все драгие peer'ы нас “душат”.
Когда нам присылают сообщение unchoked, можем начитать отправлять запросы за частями файла и ждать в ответ сообщения с этими частями.
Разбор сообщений
В сообщении содержится длиа, идентификатор и полезная нагрузка. Это выглядит так:
Сообщение начинается с указания длины. Это 32-х битное целое число в виде 4 байтов в big-endian кодировке. Следующий байт - ID(идентификатор), который означает какой тип сообщения мы получили. Например, 2 означает тип сообщения “interested”. Псоледня часть сообщения содержит полезную нагрузку.
1type messageID uint8
2
3const (
4 MsgChoke messageID = 0
5 MsgUnchoke messageID = 1
6 MsgInterested messageID = 2
7 MsgNotInterested messageID = 3
8 MsgHave messageID = 4
9 MsgBitfield messageID = 5
10 MsgRequest messageID = 6
11 MsgPiece messageID = 7
12 MsgCancel messageID = 8
13)
14
15// Message stores ID and payload of a message
16type Message struct {
17 ID messageID
18 Payload []byte
19}
20
21// Serialize serializes a message into a buffer of the form
22// <length prefix><message ID><payload>
23// Interprets `nil` as a keep-alive message
24func (m *Message) Serialize() []byte {
25 if m == nil {
26 return make([]byte, 4)
27 }
28 length := uint32(len(m.Payload) + 1) // +1 for id
29 buf := make([]byte, 4+length)
30 binary.BigEndian.PutUint32(buf[0:4], length)
31 buf[4] = byte(m.ID)
32 copy(buf[5:], m.Payload)
33 return buf
34}
Вычитываем сообщение из потока и разбираем его следуя формату. Сначала читаем 4 первых байта и интерпритируем их как uint32. Это длина нашего сообщения, которую используем чтобы прочитать все сообщение. Получаем ID(идентификатор) - первый байт и payload(полезеную нагрузку) - остаток сообщения.
1// Read parses a message from a stream. Returns `nil` on keep-alive message
2func Read(r io.Reader) (*Message, error) {
3 lengthBuf := make([]byte, 4)
4 _, err := io.ReadFull(r, lengthBuf)
5 if err != nil {
6 return nil, err
7 }
8 length := binary.BigEndian.Uint32(lengthBuf)
9
10 // keep-alive message
11 if length == 0 {
12 return nil, nil
13 }
14
15 messageBuf := make([]byte, length)
16 _, err = io.ReadFull(r, messageBuf)
17 if err != nil {
18 return nil, err
19 }
20
21 m := Message{
22 ID: messageID(messageBuf[0]),
23 Payload: messageBuf[1:],
24 }
25
26 return &m, nil
27}
Bitfields
Самый интересный тип сообщения - bitfield. Это структура, которую peer'ы используют для эффективного кодирования фрагментов, которые они могут нам отправить. Bitfield работает как массив битов. Биты, выставленные в 1, указывают какие части файлов есть у peer'а. Это похоже на карту локальности кофейни. Начинаем с пустой карты(все биты 0), заканчиваем когда вся карта проштампована(все биты в 1).
Работа с битами экономичней чем работа с байтами, такие структуры намного копмпактней. Мы можем закодировать информацию о 8 частях в одном байте - это размер типа bool. Но с такими структурами не так удобно раотать. Самый маленький размер для адресации - байт. Поэтому для работы с битами нужно выполнять дополнительные манипуляции.
1// A Bitfield represents the pieces that a peer has
2type Bitfield []byte
3
4// HasPiece tells if a bitfield has a particular index set
5func (bf Bitfield) HasPiece(index int) bool {
6 byteIndex := index / 8
7 offset := index % 8
8 return bf[byteIndex]>>(7-offset)&1 != 0
9}
10
11// SetPiece sets a bit in the bitfield
12func (bf Bitfield) SetPiece(index int) {
13 byteIndex := index / 8
14 offset := index % 8
15 bf[byteIndex] |= 1 << (7 - offset)
16}
Собираем все вместе
Теперь у нас есть все, чтобы начать скачивать файл: у нас есть список peer'ов с трекера, мы можем общаться с ними по TCP, можем провести рукопожатие, отправлять и получать сообщения. Но нужно учесть, что придется работать с несколькими peer'ами конкурентно и хранить состояния отдельно для каждого peer'а пока мы с ними взаимодействуем. Это непростые задачи.
Управление конкурентностью: каналы и очереди
В Go принято разделять память через общение.
Настроим два канала для синхронизации наших воркеров: одни для распараллеливания работы между peer'ами, второй для сбора скаченных частей. Когда загруженные фрагменты попадают в канал с результатами, мы копируем их в буфер для сборки полного файла.
1// Init queues for workers to retrieve work and send results
2workQueue := make(chan *pieceWork, len(t.PieceHashes))
3results := make(chan *pieceResult)
4for index, hash := range t.PieceHashes {
5 length := t.calculatePieceSize(index)
6 workQueue <- &pieceWork{index, hash, length}
7}
8
9// Start workers
10for _, peer := range t.Peers {
11 go t.startDownloadWorker(peer, workQueue, results)
12}
13
14// Collect results into a buffer until full
15buf := make([]byte, t.Length)
16donePieces := 0
17for donePieces < len(t.PieceHashes) {
18 res := <-results
19 begin, end := t.calculateBoundsForPiece(res.index)
20 copy(buf[begin:end], res.buf)
21 donePieces++
22}
23close(workQueue)
Запускаем воркеры в горутинах для каждого peer'а. В воркерах выполняется соединение, рукопожатие, а потом воркер получает задачи из workQueue в которых указаны фрагменты для скачивания, пытается загрузить нужны фрагменты и скидывает их в канал results.
1func (t *Torrent) startDownloadWorker(peer peers.Peer, workQueue chan *pieceWork, results chan *pieceResult) {
2 c, err := client.New(peer, t.PeerID, t.InfoHash)
3 if err != nil {
4 log.Printf("Could not handshake with %s. Disconnecting\n", peer.IP)
5 return
6 }
7 defer c.Conn.Close()
8 log.Printf("Completed handshake with %s\n", peer.IP)
9
10 c.SendUnchoke()
11 c.SendInterested()
12
13 for pw := range workQueue {
14 if !c.Bitfield.HasPiece(pw.index) {
15 workQueue <- pw // Put piece back on the queue
16 continue
17 }
18
19 // Download the piece
20 buf, err := attemptDownloadPiece(c, pw)
21 if err != nil {
22 log.Println("Exiting", err)
23 workQueue <- pw // Put piece back on the queue
24 return
25 }
26
27 err = checkIntegrity(pw, buf)
28 if err != nil {
29 log.Printf("Piece #%d failed integrity check\n", pw.index)
30 workQueue <- pw // Put piece back on the queue
31 continue
32 }
33
34 c.SendHave(pw.index)
35 results <- &pieceResult{pw.index, buf}
36 }
37}
Управление состояниями
Мы будем хранить состояние каждого peer'а и изменять его в зависимости от полученных сообщений. Для этого сделаем отдельную структуру, в которой будут храниться данные о том, сколько мы загрузили с этого peer'а, сколько мы запрашивали и “задушены” мы или нет. Для больше гибкости, эту логику можно реализовать в виде конечного автомата. Но пока нам достаточно обычного свитча.
1type pieceProgress struct {
2 index int
3 client *client.Client
4 buf []byte
5 downloaded int
6 requested int
7 backlog int
8}
9
10func (state *pieceProgress) readMessage() error {
11 msg, err := state.client.Read() // this call blocks
12 switch msg.ID {
13 case message.MsgUnchoke:
14 state.client.Choked = false
15 case message.MsgChoke:
16 state.client.Choked = true
17 case message.MsgHave:
18 index, err := message.ParseHave(msg)
19 state.client.Bitfield.SetPiece(index)
20 case message.MsgPiece:
21 n, err := message.ParsePiece(state.index, state.buf, msg)
22 state.downloaded += n
23 state.backlog--
24 }
25 return nil
26}
Время отправлять запросы!
Файлы, фрагменты и хэши фрагментов - еще не вся история, можно пойти дальше и разюить фрагменты на блоки. Блоки - это части фрагментов и мы можем идентифицировать их по индексу фрагмента в который он входит, смещению внутри фрагмента и длине блока. Когда мы делаем запросы к peer'ам, фактически мы запрашиваем блоки. Обычно блок имеет длину сообщения в 16кб. Это значит, для фрагмента в 256кб может понадобится 16 запросов.
Peer должен разрывать соединение, если получает запрос на блок размером больше 16кб. Но, судя по моему опыти, большинство клиентов прекрасно обрабатывают запросы на блоки до 128кб. Тем не менее, я получил не очень большой прирост скороси при использовании большого размера блока, поэтому лучше придерживаться спецификации.
Пайплайн
Сетевые запросы довольно дорого стоят. И запросы блоков одного за другим не увеличивают производительность нашей программы. Поэтому важно распределять запросы так, чтоб в полете постоянно было некоторое кол-во незавершенных запросов. Это может на порядок повысить пропускную способность нашего соединения.
Классические BitTorrent клиенты держат очередь из 5 пайплайновых запросов. Мы тоже так поступим. Поэксперементировав с этим значением, я обнаружил, что можно в два раза увеличить скорость загрузки. Современные клиенты поддерживают адаптивный размер очереди для лучшей утилизации сети. Сделаем это настраиваемым параметром и оставим это место для будующей оптимизации.
1// MaxBlockSize is the largest number of bytes a request can ask for
2const MaxBlockSize = 16384
3
4// MaxBacklog is the number of unfulfilled requests a client can have in its pipeline
5const MaxBacklog = 5
6
7func attemptDownloadPiece(c *client.Client, pw *pieceWork) ([]byte, error) {
8 state := pieceProgress{
9 index: pw.index,
10 client: c,
11 buf: make([]byte, pw.length),
12 }
13
14 // Setting a deadline helps get unresponsive peers unstuck.
15 // 30 seconds is more than enough time to download a 262 KB piece
16 c.Conn.SetDeadline(time.Now().Add(30 * time.Second))
17 defer c.Conn.SetDeadline(time.Time{}) // Disable the deadline
18
19 for state.downloaded < pw.length {
20 // If unchoked, send requests until we have enough unfulfilled requests
21 if !state.client.Choked {
22 for state.backlog < MaxBacklog && state.requested < pw.length {
23 blockSize := MaxBlockSize
24 // Last block might be shorter than the typical block
25 if pw.length-state.requested < blockSize {
26 blockSize = pw.length - state.requested
27 }
28
29 err := c.SendRequest(pw.index, state.requested, blockSize)
30 if err != nil {
31 return nil, err
32 }
33 state.backlog++
34 state.requested += blockSize
35 }
36 }
37
38 err := state.readMessage()
39 if err != nil {
40 return nil, err
41 }
42 }
43
44 return state.buf, nil
45}
main.go
Это очень просто. Мы почти закончили
1package main
2
3import (
4 "log"
5 "os"
6
7 "github.com/veggiedefender/torrent-client/torrentfile"
8)
9
10func main() {
11 inPath := os.Args[1]
12 outPath := os.Args[2]
13
14 tf, err := torrentfile.Open(inPath)
15 if err != nil {
16 log.Fatal(err)
17 }
18
19 err = tf.DownloadToFile(outPath)
20 if err != nil {
21 log.Fatal(err)
22 }
23}
Это еще не все
Для краткости я фключил только несколько важных фрагментов кода. Я опусти весь код для синтаксического анализа, тестов и другие скучные части. Полный код можно посмотреть на гитхабе.