= Сообщение: 1371 из 15065 ======================================= R50.SYSOP =
От : Sergey Sokoloff 2:5063/88 24 Mar 14 23:02:18
Кому : Sergey Anohin 24 Mar 14 23:02:18
Тема : Файлообмен по Фидонету
FGHI : area://R50.SYSOP?msgid=2:5063/88+5330815b
На : area://R50.SYSOP?msgid=2:5034/10.1+206f97e9
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
════╤╤═════ Паспортисты в сладострастье залпом пьют ямайский ром:
//│/│ ││ │/│/ Тост за ``Mithgol the Webmaster'', что отсутствует во ``From''.
Так было 21:53 23 Mar 14 написано от Sergey Anohin к Sergey Sokoloff:
SS>> Два важнейших недостатка:
SS>> 1) хэш файла зависит от имени файла (переименовал файл ── раздавай
SS>> заново);
SA> Имхо это не страшно, надо просто дополнять имя файла версией.
Дополнил имя файла версией ── хэш ещё раз изменился, раздавай вдругорядь.
Вот и подумай, помог ты себе таким дополнением или навредил.
SS>> 2) раздача файла зависит от Интернета (отключили Интернет ── нет
SS>> файлораздачи).
SA> Так все фидо на интернете сейчас, плюс если успели скачать кто-нибудь,
SA> так оно лавинообразно пойдет раздаваться. Конечно в первыем минуты или
SA> часы есть сложности. Ну можно сделать общефидошный сервис, который будет
SA> всегда на раздаче например.
А почему всё Фидо на Интернете сейчас и нужно ли усугублять это? Вот вопрос.
Иными словами: нельзя ли устроить так, чтобы файлообмен шёл по фидонетовским
взаимосвязям от узла к узлу вне зависимости от того, как именно были связаны
эти узлы (по Интернету, по радиоканалу Wi-Fi или Bluetooth, по межсисопскому
обмену многогигабайтными флэшками с фидопочтою, по оптическому каналу Li-Fi...)
между собою; но чтобы в случае Интернета транспортом для файлообмена была бы
торрентовая технология, а в остальных случаях ── файлэхи.
У меня подозрение вот какое: кажется мне, что для этого достаточно создать лишь
новый тикер (файлэхопроцессор). Уметь он должен вот чего:
*) Получив по файлэхе метаданные, считать файл пришедшим и раздавать его
(на самом деле ── его метаданные) далее даунлинкам. Быть готовым, однако,
также и к тому, что и сам файл может прийти (тогда файл, пришедший по фэхе,
достаточно сохранить, а получать его по файлообмену не надо; при наличии
Интернета можно зато поддержать раздачу этого файла по файлообмену).
*) В случае наличия Интернета и настроенности на немедленный приём файлов
уметь скармливать метаданные торрентовому (или иному) файлообменному
клиенту для получения файла через файлообмен. Уметь получить файл, когда
файлообменный клиент добудет его из файлообменной сети.
*) В случае наличия Интернета, но ненастроенности на немедленный приём файлов,
уметь делать всё то же самое по мере появления действительной нужды в файле
(то есть когда файл понадобится фидобраузеру или даунлинку).
*) Уметь реагировать на просьбу даунлинка о рескане файла, доставая желаемое
либо (при фактическом наличии) со своего диска, либо (при наличии Интернета)
через торрентовый файлообмен, либо (при отсутствии того и другого) ресканом
на собственном аплинке.
*) При отсутствии Интернета получать файл ресканом с аплинка, в зависимости
от настроек, либо без промедления, либо после появления действительной нужды
в файле (то есть когда файл понадобится фидобраузеру или даунлинку). Уметь
ожидать в том случае, когда аплинк сообщает, что у него файла нет ещё, что
файл должен ещё быть получен (по файлообмену или через аплинков).
При этом для фидобраузера классические файловые эхоконференции не должны никак
отличаться от вышеописанной системы. Потому что и в том, и в другом случае
при возникновении у фидобраузера действительной нужды в файле (когда надо
показать этот файл читателю Фидонета) возможны только три ситуации: 'файл есть'
(прошёл по файлэхе и лежит на диске), 'файла нет' (мы его в эхе не видели,
и аплинки тоже), 'файл может появиться' (идёт рескан с аплинка или получение
файла по файлообмену), причём последняя ситуация одновременно означает также
'файл может и не появиться' (аплинк может сказать 'и я также не видел файла'
или получить этот отклик от своего собственного аплинка и передать даунлинку,
а файлообмен может показать, что у файла 0 сидеров на протяжении NN дней).
В идеале у тикера (файлэхопроцессора) должен быть CLI-интерфейс, на вход
которому подаётся URL fecho://..., а на выходе получаем числовой код одного
из этих трёх состояний, причём в наиболее благоприятном состоянии ('файл есть')
получаем также (например, с новой строки после кода) ещё и полный путь к файлу.
SS>> Скажем, uTorrent для создания magnet-гиперссылки требует
SS>> телодвижений сисопа, а не софта. То есть через GUI он ссылку
SS>> создать может, а через CLI нет.
SA> Уверен есть консольные проги, ну в плане автоматизации прикрутить
SA> не сложно, падает файл в папку, автоматом генерится магнет, и пошла
SA> раздача, например.
Имея magnet-ссылку и тот файл, которому эта ссылка соответствует, как ты
заставишь uTorrent раздать этот файл? Задача эта не кажется простою хотя бы
потому, что magnet-ссылка содержит хэш файла метаданных (.torrent), а файла-то
ещё нет нигде (в том числе и в DHT). Похоже, что эта CLI-программа должна также
создавать и .torrent, а не только magnet-гиперссылку. И даже тогда мне не очень
ясно, каким манером ты все три их: magnet-гиперссылку, .torrent-файл, исходный
(раздаваемый) файл ── намерен скормить в uTorrent, причём одновременно.
Mithgol the Webmaster. ═[Mithgol.Ru]═[FGHI]═[Ru.Mozilla]═[Team А я меняю subj]
--- Эшелону: президент ISFR ISSO walburn шестой Дефкон DC6 Larson P99 кокаин
* Origin: Но я лишь голос вопиющего в пустыне ── ``RTFM, LMD!!!'' (2:5063/88)
|
