Почему так мало людей пользуются трушными технологиями?

Ещё троллинг.

То есть аргументировать свою позицию ты не можешь. Ясненько-понятненько.

Да. Нет. Довольно живенько. Живее eDonkey2000. Использую клиент DC++. При старте программа подключается ко всем хабам из списка публичных.

Любое копирование, любого вида, формата или протокола - это передача байтов между программами. и складирование их на файловой системе согласно правил.

Это не объясняет почему ни один протокол не позволяет копировать файл напрямую с сервера А на сервер Б.

Зачем здесь PHP и move_uploaded_file (move_uploaded_file — Moves an uploaded file to a new location)?

Это не объясняет почему ни один протокол не позволяет копировать файл напрямую с сервера А на сервер Б.

Потому что не существует протоколов, пойми уже это. Существует программный стек, реализующий последовательность байтов. Все.

То что ты называешь «протоколом» - это стандарт передачи байтов между программами, а не что-то магическое.

Копирование файла, как я уже сказал выше - это запись последовательности байтов в файловую систему. Этим не занимается протокол, этим занимается ПРОГРАММА. Чтобы скопировать файл с одного сервера на другой - на одном сервере одна программа должна передать последовательность байтов (точнее битов), на другом сервере другая программа должна их принять и записать средствами файловой системы как файл.

Ну ты что никогда связь между МКшками не программировал по последовательному порту?!

Зачем здесь PHP и move_uploaded_file (move_uploaded_file — Moves an uploaded file to a new location)?

Затем что это пример передачи файла через HTTP.

FTP - с самого начала было такое себе. Сам способ передачи файла в FTP весьма странен. SFTP вытеснил FTP достаточно давно для персонального использования, а HTTP для публичного.

eDonkey по-сути эволюционировал в torrent, который столь же тру, и дико популярен и по сей день.

IRC, Jabber, e-mail вообще никуда не делись, и пользователей у них сегодня наверняка больше чем было раньше. То, что процент от общего количества пользователей интернета сильно упал, не значит что абсолютное число пользователей сократилось. Просто появились миллиарды хомячков которые о существовании в интернете чего-либо кроме сраных централизованных социалочек нихера не знают.

NNTP - вот это да, единственное что скорее всего реально просело. NNTP поначалу проиграл отдельным тематическим форумам, потому что в отличии от NNTP на форумах правила устанавливали их владельцы, а не владельцы NNTP сервера для всех групп, и разумеется форум, где не запрещено выкладывать что-то сомнительной в плане сраных IP rights, оказывался на порядки предпочтительнее NNTP сервака, на котором за выкладывание схемы или сервис-мануала можно было лишиться не только подписки, но и всей ньюсгруппы, потому что владелец NNTP сервера зассал или отсосал у проприераста. А потом, когда с форумов новоприбывшие мимокрокодилы попёрли в централизованную социальную помойку, «ПатАмушТА УдоБНее и В СмАРТфоНи!!!111» никто не стал слушать тех, кто помнил почему все разбежались с ньюсов.

Я бы поставил диагноз, но не знаю какой. Это надо уметь съехать к тому что передавать файлы по HTTP удобнее чем по FTP (file transfer protocol - протокол передачи файлов) потому что вот, смотрите запускаем HTTP-сервер с прикрученным PHP а в PHP есть фукция move_uploaded_file которая перемещает загрженный файл из одно папки в другую.

Не согласен по поводу IRC и Jabber. Хоть я и не пользуюсь ими со дня появления, но всё же стал свидетелем исхода в Gitter, Telegram, Discord и ХЗ ещё куда. У подкаста Radio-t раньше был чатик в Jabber. Переехали в Дурограм. В ЖЖ можно было писать через Jabber. Был такой livecoding.tv (Twitch для программистов) в котором к чату трансляции можно было подключиться через Jabber, потом эту возможность убрали а потом и сам сайт закрылся.

И по поводу eDonkey тоже не согласен.

NNTP поначалу проиграл отдельным тематическим форумам, потому что в отличии от NNTP на форумах правила устанавливали их владельцы, а не владельцы NNTP сервера для всех групп

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

и разумеется форум, где не запрещено выкладывать что-то сомнительной в плане сраных IP rights, оказывался на порядки предпочтительнее NNTP сервака, на котором за выкладывание схемы или сервис-мануала можно было лишиться не только подписки, но и всей ньюсгруппы, потому что владелец NNTP сервера зассал или отсосал у проприераста.

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

XMPP в некий момент времени коропорации попытались сделать протоколом для централизованных мессенджеров на замену ICQ. Какое-то количество хомячков, разумеется перетекло с ICQ на XMPP (QIP тот же, ЖЖшечка, Google talk и пр.). Это не был осознанный выбор XMPP, просто «новая асечка», не более. Очень быстро корпорации поняли что XMPP не даёт достаточного контроля и слежки за пользователем, и даже если ограничить пользователя единственным сервером с отрезанной федерацией, то хомячки всё равно норовят использовать какие-то чортовы свободные или фришные клиенты, а не поделки корпораций с зондами. Нет ничего удивительного в том, что вскоре «концепция изменилась», и хомячки, точно так же ничесоже сумняшеся перетекли в уже полностью огороженные мессенджеры с зондами и пр. В общем, всё как корпорациям нравится.

Учитывать эти короткие набеги хомячков на IRC,XMPP и пр., организованные корпорациями в попытке использовать открытые технологии в своих целях, в вычислении количества пользователей - некорректно. Никто же не причисляет пользователей какого-нибудь Steam к пользователеям торрента, хотя, если я правильно помню, технология используемая для распространения игрух и обновлений та же.

Не поэтому, а потому что форумы с доступом через браузер были банально удобнее ньюс-групп.

Чего? Ты вообще браузеры того времени видал? Даже консольный tinn был на порядок удобнее.

Никто не мешал свою ньюс-группу хостить на своем сервере, если почему-то другие не устраивали.

Никто не мешал, но так сложилось, что Usenet перетёк на несколько очень крупных NNTP серверов.

часто спокойно выкладывают многое такое, что на форумах не рискнут. Из-за принципа неуловимого Джо конечно, но все же факт.

Сейчас - да.

Ни один протокол не позволяет копировать файл напрямую с сервера А на сервер Б.

Вот от того, что пользователи стали такими безграмотными, трушные технологии и не пользуются популярностью.

Вот от того, что пользователи стали такими безграмотными, трушные технологии и не пользуются популярностью.

Вот из-за того что пользователи открывают википедию вместо RFC959 - им и кажется, что протокол позволяет копировать файлы напрямую.

Although FXP is often considered a distinct protocol, it is in fact merely an extension of the FTP protocol and is specified in RFC 959.

Если какие-то слова не понятны, можете обратиться к словарю. От себя лично рекомендую multitran.com.

Если какие-то слова не понятны, можете обратиться к словарю. От себя лично рекомендую multitran.com.

rfc959

data port

         The passive data transfer process "listens" on the data port
         for a connection from the active transfer process in order to
         open the data connection.

Перевод

порт данных

Пассивный процесс передачи данных «прослушивает» порт данных

в ожидании подключения от активного процесса передачи данных, чтобы
открыть соединение для передачи данных.

rfc959

DTP

         The data transfer process establishes and manages the data
         connection.  The DTP can be passive or active.

Перевод

ППД

Процесс передачи данных устанавливает и управляет соединением для передачи данных.
DTP может быть пассивным или активным.

Поэтому еще раз, любой протокол - это набор байтов, передаваемых по определенным правилам, обрабатываемый определенными программами.

Читайте RFC, а не википедию, и не несите больше ерунду.

rfc959

Классический пример «смотрю в книгу, вижу фигу». RFC 959 не описывает расширение RFC 959, потому что тогда бы расширение не было бы расширением, а было бы частью протокола. Логика!

data port … DTP …

Определения не имеют ни малейшего отношения к предмету разговора: «как передать данные между двумя серверами, не копируя их локально».

любой протокол - это набор байтов, передаваемых по определенным правилам, обрабатываемый определенными программами.

Бессмысленный трюизм. Вы там, надеюсь, бухаете?

Поднимитесь выше, и вспомните что именно вы оспариваете.

Ни один протокол не позволяет копировать файл напрямую с сервера А на сервер Б.

Вот это вот заблуждение. Оспаривается контрпримером: file exchange protocol разработан именно для этого.

Вот это вот заблуждение. Оспаривается контрпримером: file exchange protocol разработан именно для этого.

Чувак, что конкретно тебе не понятно в фразе «The data transfer process establishes and manages the data connection» ?

Две вещи: мне непонятно, почему вы опираетесь на определения из RFC 959, когда речь идёт о его расширении. Как бы мысль о том, что протокол и расширение протокола не одно и то же довольно очевидная. Простая. Не трудная. Второе, где вы здесь смогли прочитать невозможность прямого копирования данных между серверами.

Ладно, давайте заканчивать эту болтологию, и вы мне дадите ссылку на полное техническое описание «расширения», и на его конкретную реализацию.

Вам надо, вы и ищите. А мне археологией заниматься недосуг. Достаточно знать, что оно было и работало. Могу подсказать, что фишка была в разделении на порт команд и порт данных, которая позволяла творить вот такие весёлые приколы, но заставляла ненавидеть FTP всех, кто вынужден был настривать firefwall.

Какой еще ПОРТ?

На сервере нет никаких портов )))

На сервере нет никаких портов )))

Если это троллинг тупостью, то он определённо удался. Вы заставили вспомнить вещи, которые лет 15 уже лежали глубоко-глубоко в пыльном чулане моей памяти.

 In another situation a user might wish to transfer files between
      two hosts, neither of which is a local host. The user sets up
      control connections to the two servers and then arranges for a
      data connection between them.  In this manner, control information
      is passed to the user-PI but data is transferred between the
      server data transfer processes.  Following is a model of this
      server-server interaction.


                    Control     ------------   Control
                    ---------->| User-FTP |<-----------
                    |          | User-PI  |           |
                    |          |   "C"    |           |
                    V          ------------           V
            --------------                        --------------
            | Server-FTP |   Data Connection      | Server-FTP |
            |    "A"     |<---------------------->|    "B"     |
            -------------- Port (A)      Port (B) --------------


                                 Figure 2

      The protocol requires that the control connections be open while
      data transfer is in progress.  It is the responsibility of the
      user to request the closing of the control connections when
      finished using the FTP service, while it is the server who takes
      the action.  The server may abort data transfer if the control
      connections are closed without command.

И эта. Почитайте что ли как TCP/IP работает. Хотя бы в самых общих чертах.

Ну понятно. Все же сервер FTP «A» и сервер FTP «B». Что и требовалось доказать.

Почитайте что ли как TCP/IP работает.

TCP/IP работает при помощи программы, которая обрабатывает байты, а что? Эта программа называется «драйвер» и в случае Linux является частью ядра, но тем не менее программой.

В современных реалиях из-за CDN/load balancer’ов у сервера A не факт что будет прямое соединение с сервером B. Так что фича сомнительная. Но если совсем надо, перекинуть файлы между васянскими подкроватными серваками можно через sftp.

Спрашивалось «чего FTP может, а HTTP нет». Вопрос «как решить задачу синхронизации данных в конкретных условиях» — это уже несколько другое.