sfn-software / sfn-d Goto Github PK

References #19.

• Receive no-md5 files;
• Optionally send no-md5 files.

Прогресс передачи файла в псевдографическом виде, как в pacman.
Прикольно было бы, если на экране отображалась вся очередь.

(15:08:15) Skynet: А ещё было бы просто супер офигенно сделать возможность соединяться через прокси.
(15:08:56) Skynet: Потому что бывают случаи, когда ни у одного, ни у другого нет возможности соединиться напрямую.
(15:08:45) m1kc: Socks proxy имеешь в виду?
(15:09:01) Skynet: Да.

Details will follow.

У меня возникает всё больший и больший диссонанс от того, что sfn передаёт файлы между клиентом и сервером параллельно, если оба решили передать файлы. Во-первых, это сильно уменьшает скорость передачи в отличие от последовательной (лично замерил) и не даёт никакого профита, кроме того, увеличивает нагрузку. Я считаю, что от неё надо избавиться и предоставить приоритет передачи файла серверу. Сначала передаёт файл сервер, затем, когда сервер закончил, передаёт клиент. Эту задачу лучше всего будет реализовать вместе с задачей по модернизации протокола.

После отправки блока 0x01 с названием и размером файла отправляемой стороной, принимающая сторона должна убедиться в наличии такого количества свободного пространства и проверить, нет ли случайно уже такого файла (на предмет докачки). Если объём позволяет, принимающая сторона отправляет блок 0x04 с отступом в байтах или нулём, если нужно качать полностью. После этого отправляющая сторона шлёт начинку файла с того места, откуда её попросили. Если файл на принимаемой стороне уже есть в полном объёме, шлётся блок 0x02, который всегда шлётся с успешным окончанием. Если места не оказалось, шлётся блок 0x03, который всегда сообщает об ошибках на удалённой стороне. В том числе, когда произошла ошибка чтения файла при отправке - на принимающую сторону должен прийти не блок 0x02 об успехе, а 0x03 с возможным описанием или индексом ошибки.
Кроме того, предлагаю ввести начальный блок 0x00, в котором присутствует версия протокола (целое число) и строка - название клиента. Этот пакет шлётся сразу после установки соединения обоими сторонами. Таким образом, если протокол несовместим (а только тогда меняется число), то дальше и разговаривать программам не о чем и с уведомлением соединение закрывается (в таком случае, правда, можно запускать передачу данных по версии протокола 1, то есть текущей, чтобы файл передать можно было в любом случае). Если всё успешно, программы показывают строчку, составленную из информации удалённой стороны, вроде: "Вас обслуживает sfn версии 1.3".

Fukken shit:

Sending a file: /data/m1kc/Видео/PSY - GANGNAM STYLE (강남스타일) M-V.mp4
93076756 bytes
43076756 bytes sent

Fukken awesome:

Sending a file: /data/m1kc/Видео/PSY - GANGNAM STYLE (강남스타일) M-V.mp4
93076756 bytes
[|||||     ] 45.1% sent (43076756 bytes), 950 KB/s

And maybe even do reverse DNS lookup.

Fukken shit:

sfn -s -f file1 -f file2 -f file3 -f file4 -f file5 -f file6 -f file7

Fukken awesome:

sfn -s file1 file2 file3 file4 file5 file6 file7
sfn -s file*

Specified in command line. If two clients have different session keys, they refuse to transfer anything. This saves us from data steal.

Let's encrypt any data between clients using session keys. Why not?

Requires: #3

• md5 должна считаться после передачи, а не до неё
• Программа должна объяснять, что она делает

Необходима возможность докачки. Если файл на принимаемой стороне есть, она обязана сообщить размер скачанный.

Почему бы нам не поменять протокол, да.

Суть: обмен информацией состоит из сообщений. Сообщение содержит тип и поля. Если какие-то поля клиенту неизвестны, он их игнорирует. Сообщение может содержать один или несколько потоков. Передача файла - сообщение с одним потоком. Поток имеет длину. Его можно направить в файл или обработать как-то ещё. Поток кончился - читаем сообщение дальше. Поток можно не обрабатывать, но принять нужно.