Обсуждение:Передача файлов

Убить все способы кроме httpUpload. Нет httpUpload - Нет передачи файлов!

Что это за горячечный бред был? Для начала, разберитесь хотя бы, что такое XEP-0363: HTTP File Upload, чтобы понять, что он никак не может быть способом передачи файлов. Этот XEP создан для совершенно других целей и при передаче файлов может быть использован только как вспомогательный для заливки файла на сервер и получения ссылки на него, при использовании в качестве транспорта XEP-0066: Out of Band Data.--Yagiza (обсуждение) 09:38, 25 февраля 2018 (UTC)

Yagiza Вы отстали от жизни. Для начала разберитесь конверсатионс, дино, гажим, омемо. httpUpload уже основной способ передачи файлов на мобильных. Другие ХЕПЫ будут постепенно отключать

Да и вообще, статью следует полностью переписать, т. к. она во-первых устарела и не отражает современных реалий, а во-вторых, какой-то вандал не залогинившись ещё и дополнительно испоганил её некоторое время назад.

Если Rain не против, я могу написать новую статью.--Yagiza (обсуждение) 09:46, 25 февраля 2018 (UTC)

Страница менялась только сегодня, так что изменения не такие старые. Без проблем, можно переписать, если она станет лучше и актуальнее.--Rain (обсуждение) 14:15, 25 февраля 2018 (UTC)

Ok. Займусь.--Yagiza (обсуждение) 09:32, 4 марта 2018 (UTC)

Человек утверждающий что httpUpload "никак не может быть способом передачи файлов" не может написать актуальную статью. Сейчас все только и говорят о конверсатионс, дино, гажим, омемо, httpUpload на каждом углу. Новая волна Jabber клиентов с омемо и httpUpload. Где httpUpload, как средство отправки файлов

Почитайте XEP. И ткните в нём тот пункт, где описано, как с его помощью можно передавать файлы. Там нет ничего подобного. Данный XEP лишь описывает XMPP-сервис, имеющий HTTP-морду, позволяющий посредством XMPP получать ссылки для загрузки файла на HTTP-сервер и для скачивания оттуда. Ни о каком прикладном применении в данном XEP речи не идёт. Для прикладного применения этой технологии (в том числе и для передачи файлов) существуют другие XEP (например, XHTML-IM, OOB и т. п.), позволяющие использовать полученные HTTP-ссылки.

И не надо мне, автору клиента, который находится в активной разработке, подробно изучившему эти XEP, втирать какую-то дичь.-- Yagiza (обсуждение) 09:32, 4 марта 2018 (UTC)

Всем глубоко по-фиг кто Вы и откуда. Мы здесь пишем страницу, а не меримся авторитетами.Если ваш мессенджер не поддерживает http upload пишите поддержку, а не вводите людей в заблуждении. Всем по-фиг что написано в XEP. Де-факто http Upload основной способ передачи файлов в новой версии Gajim, Dino, XMPP мессенджер, Conversations и десятках других мобильных клиентов. Не дополнительный, а основной

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

В продолжение темы про настройку файлопередачи - я наконец-то поставил отдельную систему, дал ей внешний динамический IP и попробовал перегонять файлы на различных клиентах - Miranda, Psi+ и QIP Infium. Как я и говорил, настройки в этом случае не требуется никакой, если у компьютера внешний адрес и один шлюз в интернет - то все работает из коробки. Пруфскрины - [1], [2], [3], [4]. Для всех остальных случаев, когда до машины нельзя достучаться "снаружи" (NAT) - используем прокси. В результате настройку просто описывать, принципы просты для понимания пользователю и статьи сводятся к "Jabber-клиент $CLIENTNAME поддерживает $TYPES типы передачи файлов. //* Допустим, там был out of bound и OOB через прокси *// Если у Вашего компьютера внешний IP-адрес, то можно использовать первый способ, настройка при этом обычно не требуется, если же нет - то необходимо использовать прокси-сервер на Вашем сервере либо выбрать один из публичных из списка. Для того, чтобы использовать прокси, bla-bla-bla..." и дальше последовательность нажатий на прилагающихся скриншотах. Для Gajim'a (и подобных предварительно настроенных клиентов) корректировать текст в стиле "Gajim изначально настроен на использование второго способа с использованием прокси. Если же Ваш компьютер имеет внешний адрес в интернет и Вы хотите исключить прокси при передаче файлов либо просто хотите изменить стандартные значения на другие - то bla-bla-bla..." и далее по скриншотам в "Расширенные настройки". --rain 15:50, 9 марта 2009 (UTC)

Не! Ну нельзя же такой сумбур в терминологию вносить!

OOB не имеет никакого отношения ко второму способу передачи файлов, описанному в статье.

На самом деле, XEP-0066: Out of Band Data это вот что: файл размещается в интернете (как он туда попадает XEP не оговоривает), и передающая сторона передаёт принимающей стороне ссылку на него. Принимающая сторона должна скачать файл и уведомить об этом передающую сторону ответным запросом. Либо, сообщить об ошибке, если файл скачать не удалось, либо пользователь просто отказался скачивать файл.

А вот способ, описанный в статье, на самом деле XEP-0065: SOCKS5 Bytestreams.--Yagiza 15:15, 26 ноября 2010 (UTC)

Если вернуться к терминологии, то по ссылке на 0065-й XEP:

XEP-0065: SOCKS5 Bytestreams
Abstract:	This document defines an XMPP protocol extension for establishing an out-of-band bytestream between any two XMPP users,
mainly for the purpose of file transfer.
The bytestream can be either direct (peer-to-peer) or mediated (though a special-purpose proxy server).

Так что без паники, это тоже OOB, только не Data, а Bytestreams. --Rain 15:52, 27 ноября 2010 (UTC)

Ты - хозяин сайта, тебе виднее, что и как писать. Я лишь предлагаю чтобы не вносить сумбура, называть расширения так, как они называются официально, а не использовать в качестве названия XEP'а текст, встречающийсяв его описании...--Yagiza 03:26, 30 ноября 2010 (UTC)

Он не просто в описании, это один из вариантов передачи данных для корневого метода - SI (XEP-0095; XEP-0096). Рассматривай структуру описания от корня к веткам (как тут, например) и все будет понятнее:

XEP-0095 (SI) -> XEP-0096 (SI File transfer)---> In band --> SI/IBB
                                             |           |
                                             |            -> SI/IQIBB
                                             | 
                                              -> Out of band -> XEP-0065 (socks5 bytestream)--> напрямую
                                                             |                              |
                                                        (а могут быть и другие)              -> через прокси

Как видишь, ставить на один уровень In band и socks5 bytestream немного неправильно. Уточнять про соответствующий XEP есть смысл только в том случае, если начнут использоваться еще какие-то методы, помимо XEP-0065. На других вики-проектах тоже закрепилось противопоставление IB - OOB (как, например, тут). Да и продвинутому конечному пользователю понять разницу между "в канале" и "вне канала" проще, чем между "в канале" и непонятно откуда взявшемуся "sock5...." --Rain 11:32, 30 ноября 2010 (UTC)

Раз такое дело пошло...А что происходит, если у обоих сторон не настраивать прокси, а прописать внутренний IP и при этом обе стороны находятся за НАТом? P.S. Похоже я понял, зачем нужно указывать внешний адрес - это для тех, кто вообще полностью подключается через прокси. H31 18:47, 9 марта 2009 (UTC)

Если хотя бы одна из сторон находится за NATом, то PROXY прописать необходимо. Естественно, если обе машины не сидят в одной сети. Т. е. если пинг от одной машины до другой проходит, то ничего прописывать не надо - файлы можно передавать напрямую. А что тут понимается под внешними/внутренними адресами вообще, не понятно? Адрес проксика в Jabber? Или IP-адрес?--Yagiza 15:15, 26 ноября 2010 (UTC)

Не обязательно. Если принимающий за NATом, а передающий без него, то можно без прокси.

Ах, да...Об этом я как-то не подумал.--Yagiza 03:26, 30 ноября 2010 (UTC)

Внутренний адрес - это тот, который можно посмотреть в ifconfig/ipconfig и который назначается для сетевого интерфейса. Внешний - это адрес самого последнего NATа (если их несколько), т.е. тот, от которого идут данные по Интернету. H31 22:58, 26 ноября 2010 (UTC)

Ясно. Т. е. имеются в виду всё же айпишнеги? Тогда где же ты собрался их прописывать?--Yagiza 03:26, 30 ноября 2010 (UTC)

Ну, это уже варианты... Самое простое и доступное, что надо описывать - вариант с внешним и без внешнего адреса, соответственно, без и с прокси. Кстати, а смысл в твоем варианте не использовать прокси? Как я уже писал, ты можешь вписать его, но если ты и другой человек находятся в одной сети, то передача пойдет напрямую (я уже приводил пример между моим десктопом и ноутом, когда оба были за НАТом, но в одной сети и скорость была около 20 Мб/сек). Хотя могу попробовать этот вариант дома. --rain 21:02, 9 марта 2009 (UTC)

Кстати, передача напрямую может пойти, а может и не пойти. Всё зависит от клиента с передающей стороны. Он может предложить прямое соединение, но не обязан этого делать. А в наиболее продвинутых клиентах это опционально.

И ещё. Правильный клиент должен уметь прежде всего поискать прокси на родном сервере. Такой клиент будет работать безо всяких дополнительных настроек, если пользователь оказался достаточно умным и зарегистрировался на сервере с проксиком(ами).--Yagiza 15:15, 26 ноября 2010 (UTC)

Не думаю, что сильно влияет. Либо прямое соединение возможно, либо нет. А всякие штуковины типа NAT Traversal я только в имплементациях Jingle видел. Разве что зависит от того, правильный ли адрес сообщит передающая сторона. Как раз для этого клиент и нужно настраивать. H31 22:58, 26 ноября 2010 (UTC)

Это вообще, о чём было? Ни строчки не понял. Что на что не сильно влияет? Как ты собрался учить передающую сторону адреса сообщать? Пойми: проксик(и), который(е) ты прописываешь - вовсе не тот(те) адрес(а), который(е) клиент потом сообщит! Механизм определения адресов не такой примитивный.--Yagiza 03:26, 30 ноября 2010 (UTC)

Кстати, у Psi+ интересный глюк был при обмене файлами с ботом - пытаешься обмениваться файлами - ругается на НАТ (которого нет), закрываешь появившуюся табличку, снова жмешь "Отправить" - все отлично отправляется :). --rain 10:02, 10 марта 2009 (UTC)

OMG... Действительно "Band"... Вот что бывает, когда невнимательно правки проверяешь - теперь оно по всей вики разошлось >_<. --Rain 08:47, 19 июня 2009 (UTC) Тут еще такой момент: адрес может быть внешним, но у провайдера перекрыты входящие подключения (попадалось такое), в таком случае тоже нужен прокси (соединение устанавливается со стороны клиента). --Rain 14:18, 10 июля 2009 (UTC)

Т.е. внешний адрес статический, но стоит NAT? H31 15:02, 10 июля 2009 (UTC)

Не обязательно статический, просто внешний, но на стороне провайдера что-то типа -A INPUT -j DENY. Иначе говоря, ты не можешь предоставлять никаких сервисов для сети. --Rain 15:15, 10 июля 2009 (UTC)

Т.е. оно от NAT'а с практической стороны не отличается? В любом случае, при сканировании портов оно не ответит - так что всё нормально :-) H31 15:53, 10 июля 2009 (UTC)

Ну, оно не НАТ, но да, прокси в этом случае должен помочь. Просто юзеры могут путаться - IP вроде как и внешний, а приходится юзать прокси. --Rain 16:57, 10 июля 2009 (UTC)

Схема графиков для mermaid:

Общая схема

graph TD
    %% Уровень представления и метаданных
    subgraph UI ["Уровень уведомления и метаданных"]
        SIMS["<br/><b>SIMS (XEP-0385)</b><br/>Превью, тип, размер и хэш файла<br/><br/>"]
        OOB["<br/><b>OOB (XEP-0066)</b><br/>Передача прямой URL-ссылки<br/><br/>"]
    end

    %% Уровень управления сессиями
    subgraph Control ["Уровень согласования (Signaling Layer)"]
        HTTP["<br/><b>HTTP File Upload (XEP-0363)</b><br/><b>(Современный)</b> Загрузка на сервер<br/><br/>"]
        X166["<br/><b>Jingle (XEP-0166)</b><br/><b>(Современный)</b> Базовый протокол сессий<br/><br/>"]
        X095["<br/><b>Stream Initiation (XEP-0095)</b><br/><b>(Устаревший)</b> Старый SI протокол<br/><br/>"]
    end

    %% Конкретные реализации файловой логики
    subgraph Logic ["Реализация обмена (File Logic)"]
        X234["<br/><b>Jingle File Transfer (XEP-0234)</b><br/>Логика передачи файлов в Jingle<br/><br/>"]
        X096["<br/><b>SI File Transfer (XEP-0096)</b><br/>Логика передачи файлов в SI<br/><br/>"]
    end

    %% Уровень транспорта с приоритетами
    subgraph Transport ["Уровень транспорта и Приоритеты"]
        P1["<br/><b>Приоритет 1: Web / HTTPS</b><br/>Стандартный веб-транспорт<br/><br/>"]
        P2["<br/><b>Приоритет 2: SOCKS5 (XEP-0065)</b><br/>Быстрый бинарный поток (P2P)<br/><br/>"]
        P3["<br/><b>Приоритет 3: IBB (XEP-0047)</b><br/>Медленный XML-поток (Fallback)<br/><br/>"]
    end

    %% Вспомогательные узлы
    P65["<br/><b>Proxy65 (SOCKS5 Proxy)</b><br/>Помощь NAT для SOCKS5<br/><br/>"]

    %% Связи
    SIMS -.->|описывает| HTTP
    HTTP === P1
    OOB --- P1

    %% Jingle связи
    X166 === X234
    X234 -- "XEP-0260" --> P2
    X234 -- "XEP-0261" --> P3

    %% SI связи
    X095 === X096
    X096 -- "Выбор S5B" --> P2
    X096 -- "Выбор IBB" --> P3

    %% Транспортные связи
    P2 -.->|если нужен обход NAT| P65

    %% Стилизация
    style SIMS fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style X166 fill:#fff3cd,stroke:#ffc107,stroke-width:2px
    style X095 fill:#f8d7da,stroke:#dc3545
    style HTTP fill:#d4edda,stroke:#28a745,stroke-width:3px
    style P1 fill:#c8e6c9,stroke:#2e7d32
    style P2 fill:#fff9c4,stroke:#fbc02d
    style P3 fill:#ffecb3,stroke:#ffa000,stroke-dasharray: 5 5

Обнаружение сервисов

graph TD
    %% Уровень Discovery
    subgraph Discovery ["Уровень обнаружения (XEP-0030)"]
        SD["<b>Service Discovery</b><br/>Запрос возможностей (info/items)"]
    end

    %% Уровень представления
    subgraph UI ["Метаданные"]
        SIMS["<b>SIMS</b><br/>(XEP-0385)"]
    end

    %% Уровень управления и Приоритеты
    subgraph Logic ["Логика и Приоритеты"]
        P1["<b>Приоритет 1 (Server-side)</b><br/>HTTP Upload (XEP-0363)"]
        P2["<b>Приоритет 2 (P2P Fast)</b><br/>Jingle S5B (XEP-0260)"]
        P3["<b>Приоритет 3 (P2P Fallback)</b><br/>Jingle IBB (XEP-0261)"]
    end

    %% Связи Discovery
    SD -- "Ищет серверную фичу" --> P1
    SD -- "Ищет клиентскую фичу" --> P2
    SD -- "Если S5B недоступен" --> P3

    %% Связи метаданных
    SIMS -.->|описывает результат| P1
    SIMS -.->|может описывать| P2

    %% Транспорт
    P1 --- T1[Web / HTTP]
    P2 --- T2[SOCKS5 / XEP-0065]
    P3 --- T3[IBB / XEP-0047]

    %% Стилизация
    style SD fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    style P1 fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
    style P2 fill:#fff9c4,stroke:#fbc02d
    style P3 fill:#ffe0b2,stroke:#f57c00,stroke-dasharray: 5 5

--Rain (обсуждение) 23:11, 7 марта 2026 (UTC)