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

Убить все способы кроме 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)