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

'''Убить все способы кроме httpUpload. Нет httpUpload -  Нет передачи файлов!'''
: Что это за горячечный бред был? Для начала, разберитесь хотя бы, что такое [https://xmpp.org/extensions/xep-0363.html XEP-0363: HTTP File Upload], чтобы понять, что он никак не может быть способом передачи файлов. Этот XEP создан для совершенно других целей и при передаче файлов может быть использован только как вспомогательный для заливки файла на сервер и получения ссылки на него, при использовании в качестве транспорта [http://xmpp.org/extensions/xep-0066.html XEP-0066: Out of Band Data].--[[Участник:Yagiza|Yagiza]] ([[Обсуждение участника:Yagiza|обсуждение]]) 09:38, 25 февраля 2018 (UTC)
::[[Участник:Yagiza|Yagiza]] Вы отстали от жизни. Для начала разберитесь конверсатионс, дино, гажим, омемо. httpUpload уже основной способ передачи файлов на мобильных. Другие ХЕПЫ будут постепенно отключать

:Да и вообще, статью следует полностью переписать, т. к. она во-первых устарела и не отражает современных реалий, а во-вторых, какой-то вандал не залогинившись ещё и дополнительно испоганил её некоторое время назад.
:Если [[Участник:Rain|Rain]] не против, я могу написать новую статью.--[[Участник:Yagiza|Yagiza]] ([[Обсуждение участника:Yagiza|обсуждение]]) 09:46, 25 февраля 2018 (UTC)
:: Страница менялась только сегодня, так что изменения не такие старые. Без проблем, можно переписать, если она станет лучше и актуальнее.--[[Участник:Rain|Rain]] ([[Обсуждение участника:Rain|обсуждение]]) 14:15, 25 февраля 2018 (UTC)
:::Ok. Займусь.--[[Участник:Yagiza|Yagiza]] ([[Обсуждение участника: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|Yagiza]] ([[Обсуждение участника:Yagiza|обсуждение]]) 09:32, 4 марта 2018 (UTC)
::::: Всем глубоко по-фиг кто Вы и откуда. Мы здесь пишем страницу, а не меримся авторитетами.Если ваш мессенджер не поддерживает http upload пишите поддержку, а не вводите людей в заблуждении.   Всем по-фиг что написано в XEP. '''Де-факто http Upload основной способ передачи файлов в новой версии Gajim, Dino, XMPP мессенджер, Conversations и десятках других мобильных клиентов'''. Не дополнительный, '''а основной'''
В продолжение [[Обсуждение:Настройка передачи файлов в Miranda|темы]] про настройку файлопередачи - я наконец-то поставил отдельную систему, дал ей внешний динамический IP и попробовал перегонять файлы на различных клиентах - Miranda, Psi+ и QIP Infium. Как я и говорил, настройки в этом случае не требуется никакой, если у компьютера внешний адрес и один шлюз в интернет - то все работает из коробки. Пруфскрины - [http://rain.linuxoid.in/fileupload/screenshots/miranda_filetransfer.png], [http://rain.linuxoid.in/fileupload/screenshots/psi_filetransfer.png], [http://rain.linuxoid.in/fileupload/screenshots/psi_filetransfer2.png], [http://rain.linuxoid.in/fileupload/screenshots/qip_realip.png]. Для всех остальных случаев, когда до машины нельзя достучаться "снаружи" (NAT) - используем прокси. В результате настройку просто описывать, принципы просты для понимания пользователю и статьи сводятся к "Jabber-клиент $CLIENTNAME поддерживает $TYPES типы передачи файлов. //* Допустим, там был out of bound и OOB через прокси *// Если у Вашего компьютера внешний IP-адрес, то можно использовать первый способ, настройка при этом обычно не требуется, если же нет - то необходимо использовать прокси-сервер на Вашем сервере либо выбрать [[Список публичных транспортов proxy|один из публичных из списка]]. Для того, чтобы использовать прокси, bla-bla-bla..." и дальше последовательность нажатий на прилагающихся скриншотах. Для Gajim'a (и подобных предварительно настроенных клиентов) корректировать текст в стиле "Gajim изначально настроен на использование второго способа с использованием прокси. Если же Ваш компьютер имеет внешний адрес в интернет и Вы хотите исключить прокси при передаче файлов либо просто хотите изменить стандартные значения на другие - то bla-bla-bla..." и далее по скриншотам в "Расширенные настройки". --[[Участник:Rain|rain]] 15:50, 9 марта 2009 (UTC)
: Не! Ну нельзя же такой сумбур в терминологию вносить!
: OOB не имеет никакого отношения ко второму способу передачи файлов, описанному в статье.
: На самом деле, [http://xmpp.org/extensions/xep-0066.html XEP-0066: Out of Band Data] это вот что: файл размещается в интернете (как он туда попадает XEP не оговоривает), и передающая сторона передаёт принимающей стороне ссылку на него. Принимающая сторона должна скачать файл и уведомить об этом передающую сторону ответным запросом. Либо, сообщить об ошибке, если файл скачать не удалось, либо пользователь просто отказался скачивать файл.
: А вот способ, описанный в статье, на самом деле [http://xmpp.org/extensions/xep-0065.html XEP-0065: SOCKS5 Bytestreams].--[[Участник:Yagiza|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|Rain]] 15:52, 27 ноября 2010 (UTC)
::: Ты - хозяин сайта, тебе виднее, что и как писать. Я лишь предлагаю чтобы не вносить сумбура, называть расширения так, как они называются официально, а не использовать в качестве названия XEP'а текст, встречающийсяв его описании...--[[Участник:Yagiza|Yagiza]] 03:26, 30 ноября 2010 (UTC)
:::: Он не просто в описании, это один из вариантов передачи данных для корневого метода - SI (XEP-0095; XEP-0096). Рассматривай структуру описания от корня к веткам ([[JRD:File_transfer/Tkabber_wiki#SI|как тут, например]]) и все будет понятнее:
 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 (как, например, [[JRD:File_transfer|тут]]). Да и продвинутому конечному пользователю понять разницу между "в канале" и "вне канала" проще, чем между "в канале" и непонятно откуда взявшемуся "sock5...." --[[Участник:Rain|Rain]] 11:32, 30 ноября 2010 (UTC)
: Раз такое дело пошло...А что происходит, если у обоих сторон не настраивать прокси, а прописать внутренний IP и при этом обе стороны находятся за НАТом? P.S. Похоже я понял, зачем нужно указывать внешний адрес - это для тех, кто вообще полностью подключается через прокси. [[Участник:H31|H31]] 18:47, 9 марта 2009 (UTC)
:: Если хотя бы одна из сторон находится за NATом, то PROXY прописать необходимо. Естественно, если обе машины не сидят в одной сети. Т. е. если пинг от одной машины до другой проходит, то ничего прописывать не надо - файлы можно передавать напрямую. А что тут понимается под внешними/внутренними адресами вообще, не понятно? Адрес проксика в Jabber? Или IP-адрес?--[[Участник:Yagiza|Yagiza]] 15:15, 26 ноября 2010 (UTC)
::: Не обязательно. Если принимающий за NATом, а передающий без него, то можно без прокси.
:::: Ах, да...Об этом я как-то не подумал.--[[Участник:Yagiza|Yagiza]] 03:26, 30 ноября 2010 (UTC)
::: Внутренний адрес - это тот, который можно посмотреть в ifconfig/ipconfig и который назначается для сетевого интерфейса. Внешний - это адрес самого последнего NATа (если их несколько), т.е. тот, от которого идут данные по Интернету. [[Участник:H31|H31]] 22:58, 26 ноября 2010 (UTC)
:::: Ясно. Т. е. имеются в виду всё же айпишнеги? Тогда где же ты собрался их прописывать?--[[Участник:Yagiza|Yagiza]] 03:26, 30 ноября 2010 (UTC)
:: Ну, это уже варианты... Самое простое и доступное, что надо описывать - вариант с внешним и без внешнего адреса, соответственно, без и с прокси. Кстати, а смысл в твоем варианте не использовать прокси? Как я уже писал, ты можешь вписать его, но если ты и другой человек находятся в одной сети, то передача пойдет напрямую (я уже приводил пример между моим десктопом и ноутом, когда оба были за НАТом, но в одной сети и скорость была около 20 Мб/сек). Хотя могу попробовать этот вариант дома. --[[Участник:Rain|rain]] 21:02, 9 марта 2009 (UTC)
::: Кстати, передача напрямую может пойти, а может и не пойти. Всё зависит от клиента с передающей стороны. Он может предложить прямое соединение, но не обязан этого делать. А в наиболее продвинутых клиентах это опционально.
::: И ещё. Правильный клиент должен уметь прежде всего поискать прокси на родном сервере. Такой клиент будет работать безо всяких дополнительных настроек, если пользователь оказался достаточно умным и зарегистрировался на сервере с проксиком(ами).--[[Участник:Yagiza|Yagiza]] 15:15, 26 ноября 2010 (UTC)
:::: Не думаю, что сильно влияет. Либо прямое соединение возможно, либо нет. А всякие штуковины типа NAT Traversal я только в имплементациях Jingle видел. Разве что зависит от того, правильный ли адрес сообщит передающая сторона. Как раз для этого клиент и нужно настраивать. [[Участник:H31|H31]] 22:58, 26 ноября 2010 (UTC)
::::: Это вообще, о чём было? Ни строчки не понял. Что на что не сильно влияет? Как ты собрался учить передающую сторону адреса сообщать? Пойми: проксик(и), который(е) ты прописываешь - вовсе не тот(те) адрес(а), который(е) клиент потом сообщит! Механизм определения адресов не такой примитивный.--[[Участник:Yagiza|Yagiza]] 03:26, 30 ноября 2010 (UTC)
: Кстати, у Psi+ интересный глюк был при обмене файлами с [xmpp:gs1@jabber.ru ботом] - пытаешься обмениваться файлами - ругается на НАТ (которого нет), закрываешь появившуюся табличку, снова жмешь "Отправить" - все отлично отправляется :). --[[Участник:Rain|rain]] 10:02, 10 марта 2009 (UTC)
OMG... Действительно "Band"... Вот что бывает, когда невнимательно правки проверяешь - теперь оно по всей вики разошлось >_<. --[[Участник:Rain|Rain]] 08:47, 19 июня 2009 (UTC)
Тут еще такой момент: адрес может быть внешним, но у провайдера перекрыты входящие подключения (попадалось такое), в таком случае тоже нужен прокси (соединение устанавливается со стороны клиента). --[[Участник:Rain|Rain]] 14:18, 10 июля 2009 (UTC)
: Т.е. внешний адрес статический, но стоит NAT? [[Участник:H31|H31]] 15:02, 10 июля 2009 (UTC)
:: Не обязательно статический, просто внешний, но на стороне провайдера что-то типа <code>-A INPUT -j DENY</code>. Иначе говоря, ты не можешь предоставлять никаких сервисов для сети. --[[Участник:Rain|Rain]] 15:15, 10 июля 2009 (UTC)
::: Т.е. оно от NAT'а с практической стороны не отличается? В любом случае, при сканировании портов оно не ответит - так что всё нормально :-) [[Участник:H31|H31]] 15:53, 10 июля 2009 (UTC)
:::: Ну, оно не НАТ, но да, прокси в этом случае должен помочь. Просто юзеры могут путаться - IP вроде как и внешний, а приходится юзать прокси. --[[Участник:Rain|Rain]] 16:57, 10 июля 2009 (UTC)