Обсуждение:Передача файлов: различия между версиями
Yagiza (обсуждение | вклад) |
Rain (обсуждение | вклад) (ответ) |
||
Строка 4: | Строка 4: | ||
:Да и вообще, статью следует полностью переписать, т. к. она во-первых устарела и не отражает современных реалий, а во-вторых, какой-то вандал не залогинившись ещё и дополнительно испоганил её некоторое время назад. | :Да и вообще, статью следует полностью переписать, т. к. она во-первых устарела и не отражает современных реалий, а во-вторых, какой-то вандал не залогинившись ещё и дополнительно испоганил её некоторое время назад. | ||
:Если [[Участник:Rain|Rain]] не против, я могу написать новую статью.--[[Участник:Yagiza|Yagiza]] ([[Обсуждение участника:Yagiza|обсуждение]]) 09:46, 25 февраля 2018 (UTC) | :Если [[Участник:Rain|Rain]] не против, я могу написать новую статью.--[[Участник:Yagiza|Yagiza]] ([[Обсуждение участника:Yagiza|обсуждение]]) 09:46, 25 февраля 2018 (UTC) | ||
:: Страница менялась только сегодня, так что изменения не такие старые. Без проблем, можно переписать, если она станет лучше и актуальнее. --[[Участник:Rain|Rain]] ([[Обсуждение участника:Rain|обсуждение]]) 14:15, 25 февраля 2018 (UTC) | |||
В продолжение [[Обсуждение:Настройка передачи файлов в 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) | В продолжение [[Обсуждение:Настройка передачи файлов в 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) |
Версия 14:15, 25 февраля 2018
Убить все способы кроме httpUpload. Нет httpUpload - Нет передачи файлов!
- Что это за горячечный бред был? Для начала, разберитесь хотя бы, что такое XEP-0363: HTTP File Upload, чтобы понять, что он никак не может быть способом передачи файлов. Этот XEP создан для совершенно других целей и при передаче файлов может быть использован только как вспомогательный для заливки файла на сервер и получения ссылки на него, при использовании в качестве транспорта XEP-0066: Out of Band Data.--Yagiza (обсуждение) 09:38, 25 февраля 2018 (UTC)
- Да и вообще, статью следует полностью переписать, т. к. она во-первых устарела и не отражает современных реалий, а во-вторых, какой-то вандал не залогинившись ещё и дополнительно испоганил её некоторое время назад.
- Если Rain не против, я могу написать новую статью.--Yagiza (обсуждение) 09:46, 25 февраля 2018 (UTC)
- Страница менялась только сегодня, так что изменения не такие старые. Без проблем, можно переписать, если она станет лучше и актуальнее. --Rain (обсуждение) 14:15, 25 февраля 2018 (UTC)
В продолжение темы про настройку файлопередачи - я наконец-то поставил отдельную систему, дал ей внешний динамический 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'а текст, встречающийсяв его описании...--Yagiza 03:26, 30 ноября 2010 (UTC)
- Так что без паники, это тоже OOB, только не Data, а Bytestreams. --Rain 15:52, 27 ноября 2010 (UTC)
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)
- Не обязательно. Если принимающий за NATом, а передающий без него, то можно без прокси.
- Ну, это уже варианты... Самое простое и доступное, что надо описывать - вариант с внешним и без внешнего адреса, соответственно, без и с прокси. Кстати, а смысл в твоем варианте не использовать прокси? Как я уже писал, ты можешь вписать его, но если ты и другой человек находятся в одной сети, то передача пойдет напрямую (я уже приводил пример между моим десктопом и ноутом, когда оба были за НАТом, но в одной сети и скорость была около 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)
- Не думаю, что сильно влияет. Либо прямое соединение возможно, либо нет. А всякие штуковины типа NAT Traversal я только в имплементациях Jingle видел. Разве что зависит от того, правильный ли адрес сообщит передающая сторона. Как раз для этого клиент и нужно настраивать. H31 22:58, 26 ноября 2010 (UTC)
- Если хотя бы одна из сторон находится за NATом, то PROXY прописать необходимо. Естественно, если обе машины не сидят в одной сети. Т. е. если пинг от одной машины до другой проходит, то ничего прописывать не надо - файлы можно передавать напрямую. А что тут понимается под внешними/внутренними адресами вообще, не понятно? Адрес проксика в Jabber? Или IP-адрес?--Yagiza 15:15, 26 ноября 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)
- Т.е. оно от NAT'а с практической стороны не отличается? В любом случае, при сканировании портов оно не ответит - так что всё нормально :-) H31 15:53, 10 июля 2009 (UTC)
- Не обязательно статический, просто внешний, но на стороне провайдера что-то типа