Передача файлов через прокси. Обрыв передачи у получателя.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. На сервере включена возможность передачи 
через прокси по порту 7777
2. Клиенты находятся в разных сетях и 
напрямую не доступны, настройки на 
клиентах одинаковые
3. Клиент1 и сервер находятся в одной сети и 
видят друг-друга напрямую (скорость 
передачи данных между клиентом и сервером 
~100 МБит/с)
4. Клиент2 - удаленный клиент и подключается 
к серверу через NAT (скорость передачи 
данных между клиентом и сервером ~80 КБайт/с)
5. В настройках Vacuum-"Потоки данных"-"SOCKS5 
поток данных" стоит:
"Таймаут подключения": 10 сек
"Прокси подключения"-"Использовать 
настройки прокси из аккаунта" вкл.
"Запретитьт прямые подключения" вкл.
"Прокси потока"-"Использовать прокси на 
сервере аккаунта" вкл.
6. В настройках Vacuum-"Передача файлов" стоит:
"Поток данных по умолчанию" - SOCKS5
"Разрешенные потоки" - SOCKS5-включен; 
внутриканальный-отключен.
"Автоматически принимать файлы от 
контактов в ростере" вкл.
7. Клиент1 инициирует передачу файла 
Клиенту2
8. Клиент1 полностью отправляет файл на 
сервер и в окне передачи написано что 
передача успешно завершена.
9. В тот момент когда Клиент1 уже закончил 
передачу, Клиент2 еще продолжает загружать 
файл некоторое время, а затем выходит 
сообщение о том, что отправитель отменил 
передачу файла

What is the expected output? What do you see instead?
Либо клиент1 должен получить сообщение об 
ошибке что клиент2 не получил файл, либо 
клиент2 должен получить файл.

What version of the product are you using? On what operating system?
Сервер: Openfire 3.7.1
Клиент1: Windows XP SP3, Vacuum-IM 1.2.0.1859
Клиент2: Windows Server 2003, Vacuum-IM 1.2.0.1859

Please provide any additional information below.
Эксперимент проводился с разными файлами 
размером от 500Кб до 2Мб.
Причем если выполнить отправку наоборот от 
клиента2 к клиенту1 передача и прием 
выполняются успешно.
Есть подозрение, что в тот момент как 
клиент1 отправляет до конца файл, он 
посылает серверу команду об успешной 
передачи файла, и сервер удаляет файл не 
дождавшись когда закончится приём этого 
файла клиентом2.

Original issue reported on code.google.com by koledas...@gmail.com on 17 Nov 2012 at 5:42

[GoogleCodeExporter]

А фактически файл передавался полностью 
или нет? Раньше была ошибка, из-за которой 
файл передавался успешно, но выводилось 
сообщение об отмене передаче, но она была 
исправлена в версии 1.2. Если файл 
передается не полностью, то рекомендую 
проверить на другом прокси, например, 
proxy.jabbim.cz, а еще лучше посмотреть wareshark-ом по 
чьей инициативе обрывается подключение.

Original comment by potapov.s.a on 17 Nov 2012 at 9:17

• Changed state: Checking
• Added labels: Type-Defect
• Removed labels: Type-Unknown

[GoogleCodeExporter]

От клиента1 к клиенту2 файл передается не 
полностью (передавал архив, при открытии на 
клиенте2 пишет, что архив поврежден, хотя на 
клиенте1 архив целый).
Причем при повторной передаче, при 
включении докачки, процент загрузки 
увеличивается с каждым разом, но всё равно 
обрывается. Делал 4 попытки, сначала 94%, 
потом 96%, потом 98%, и в четвертый раз 99%. 
Дальше не стал мучатся. 
От клиента2 к клиенту1 файл передается 
полностью с первого раза (но тут и ошибок не 
возникает).
Как именно wareshark-ом проверить? Ни разу им не 
пользовался. В чём суть, и как я пойму кто 
косячит?

Original comment by koledas...@gmail.com on 17 Nov 2012 at 9:27

[GoogleCodeExporter]

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

Original comment by potapov.s.a on 17 Nov 2012 at 9:47

[GoogleCodeExporter]

Для начала можно попробовать другой 
прокси, а затем уже смотреть wareshark-ом.

Original comment by potapov.s.a on 17 Nov 2012 at 9:48

[GoogleCodeExporter]

Ок, спасибо за ответ, в понедельник 
попробую и отпишусь по результатам.

Original comment by koledas...@gmail.com on 17 Nov 2012 at 9:52

[GoogleCodeExporter]

Правильно ли я понимаю что r2003 должно 
решить мою проблему?
Сторонний прокси (proxy.jabbim.cz) проверить не 
удается. Добавил его в "Прокси потока",  
галку "Использовать прокси на сервере 
аккаунта" убрал. То ли фаервол не пускает, 
то ли прокси, но на отправителе пишется "Не 
удалось создать хост". Еще повожусь с 
доступом, пока просто не пойму что не 
получается, то ли имя proxy.jabbim.cz не 
резолвится то ли порты какие прекрыты...
Поясните пожалуйста стоит ли попробовать 
r2003?

Original comment by koledas...@gmail.com on 19 Nov 2012 at 3:29

[GoogleCodeExporter]

Опробовал r2003 - передать файл получилось, 
причем через наш внутренний прокси! 
Единственный нюанс: на отправителе 
остается висеть статус "Передача данных", 
прогресс 100%, хотя на получателе в статусе 
написано "Передача данных завершена", 
прогресс 100%.

Еще один вопрос. На сколько нестабильна 
версия 1.3.0.2003-alpha? можем ли мы её 
использовать вместо 1.2.0.1859? Просто народу 300 
человек и как-то не очень хочется 
экспериментировать.

Original comment by koledas...@gmail.com on 19 Nov 2012 at 4:16

[GoogleCodeExporter]

Да r2003 я решил поэкспериментировать и 
сделал так, чтобы подключение завершалось 
принимающей стороной, но в этом случае 
возможно подвисание передачи, если 
принимающая сторона ожидает завершения 
подключения со стороны передающей, по 
этому возможно придется отменить это 
изменение, если будут проблемы с передачей 
на другие клиенты. Почему продолжает 
висеть "Передача данных" после отключения 
принимающей стороны пока не понятно. А к 
вашему серверу есть доступ из инета?

Original comment by potapov.s.a on 19 Nov 2012 at 6:00

[GoogleCodeExporter]

Широко использовать 1.3 я бы не 
рекомендовал, хотя она и вполне стабильна, 
если это исправление будет нормально 
работать, то я его перенесу в ветку 1.2 и 
сделаю сборку.

Original comment by potapov.s.a on 19 Nov 2012 at 6:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

К нашему серваку из Интернета, к сожалению, 
не подцепиться, он у нас используется в 
защищенной сети VipNET. Но могу активно 
содействовать в экспериментах :)
Тогда пока не будем обновляться. А вообще, 
что касается сервака то стоит Openfire 3.7.1. В 
серваке ничего особенного. Особенность 
только в том, что отправитель имеет более 
высокую скорость соединения с сервером, 
чем получатель.

Original comment by koledas...@gmail.com on 19 Nov 2012 at 8:17

[GoogleCodeExporter]

> Но могу активно содействовать в 
экспериментах
Ок, тогда посмотри после завершения 
передачи файла на стороне передающего, 
когда висит "Передача данных", разорвано 
или нет соединение с прокси-сервером?

Original comment by potapov.s.a on 19 Nov 2012 at 8:20

[GoogleCodeExporter]

Проверил wareshark-ом. В качестве фильтра задал 
строку:
tcp.dstport == 7777
Вот что получилось на отправителе, когда 
висит "Передача данных":
https://dl.dropbox.com/u/56927680/vacuum.pcapng
Я из этого не понял разорвано или нет 
соединение. Но мне кажется что не 
разорвано, т.к. если нажать на отправителе 
"Прервать" (после того как получатель 
получил файл), то в wareshark появляются еще 2 
строки.

Original comment by koledas...@gmail.com on 19 Nov 2012 at 9:12

[GoogleCodeExporter]

А можешь в текстовом виде выложить, а то мне 
нечем посмотреть.

Original comment by potapov.s.a on 19 Nov 2012 at 9:14

[GoogleCodeExporter]

Заголовки: https://dl.dropbox.com/u/56927680/vacuum_title.txt
Подробная инфа: https://dl.dropbox.com/u/56927680/vacuum_detail.txt
Последние 2 строки появляются если нажать 
на отправителе "Прервать"

Original comment by koledas...@gmail.com on 19 Nov 2012 at 9:25

[GoogleCodeExporter]

Ну вот, прокси не закрывает подключение к 
передающему, если отключился принимающий, 
и при этом обрывает соединение с 
принимающей стороной, не передав все 
данный от передающей в случае отключения 
последней. Это явно косячит прокси, когда я 
пробовал прокси от ejabberd, то передающий 
заканчивал передачу отключался и я даже 
выгружал клиент, а прокси все продолжал 
передавать данные принимающему. Надо будет 
протестировать передачу файлов на другие 
клиенты и если с ними будет все ОК, то я 
оставлю изменения из r2003, а несли нет, то 
придется их убрать.

Original comment by potapov.s.a on 19 Nov 2012 at 9:34

[GoogleCodeExporter]

Всё понятно, погуглю про Openfire. Может кто с 
такой проблемой сталкивался, хотя уже 
обшарил всё...

Original comment by koledas...@gmail.com on 19 Nov 2012 at 9:56

[GoogleCodeExporter]

Еще как вариант попробую завтра передать 
файл через psi. Просто странно, что никто с 
такой проблемой не сталкивался, сервак-то 
популярный...

Original comment by koledas...@gmail.com on 19 Nov 2012 at 10:02

[GoogleCodeExporter]

Мда, через PSI вообще передачу файлов не 
получилось поднять... Интернет про openfire 
тоже ничего не говорит.
Попробовал опять поэкспериментировать с 
версией 1.2.0.1859.
Интересно, что при отключении отправителя, 
получатель продолжает долгое время качать 
файл с сервера. И обрыв происходит тогда, 
когда остается 20-40 КБайт.
Т.е. прокся не сразу откидывает получателя. 
Попробовал на серваке увеличить кэш - не 
помогло.

Original comment by koledas...@gmail.com on 20 Nov 2012 at 3:44

[GoogleCodeExporter]

Я вчера экспериментировал на локальном 
сервере Openfire 3.7.1 и у меня передача 
происходила синхронно, т.е. скорость у 
передающего всегда была равна скорости 
принимающего, хотя последний был подключен 
через Wi-Fi и я пускал другие загрузки для 
уменьшения скорости. У меня сложилось 
впечатление, что у прокси Openfire в отличие от 
ejabberd нет внутреннего буфера. Передача 
всегда завершалась успешно на сборках до 
r2003, а на сборках после r2003 передающий не 
отключался от прокси и зависал на передаче 
данных. В итоге я склоняюсь к тому, чтобы 
отменить изменения из r2003.

Original comment by potapov.s.a on 20 Nov 2012 at 4:39

[GoogleCodeExporter]

Да, думаю r2003 лучше отменить, явно заморочки 
прокси. У меня тоже скорость передачи была 
равна на обоих клиентах, но прогресс на 
отправителе всегда шел впереди прогресса 
получателя. Скорее всего у тебя не 
получилось получить ошибку из-за того что 
скорость была велика. У меня у получателя 
скорость ~80 КБайт/с соответственно и 
передающий почему-то передает примерно с 
такой же скоростью (хотя скорость между 
передающим и сервером ~10 МБайт/с). И 
недокачивает почему-то не больше 100Кбайт. 
Ща попробую наоборот уменьшить кэш. Может 
так он будет синхроннее качать...

Original comment by koledas...@gmail.com on 20 Nov 2012 at 6:04

[GoogleCodeExporter]

Попробовал поставить кэш равный 5КБ. 
Ребутнул сервер. Не изменилось абсолютно 
ничего. Всё, я сдаюсь, идеи кончались.

Original comment by koledas...@gmail.com on 20 Nov 2012 at 10:07

[GoogleCodeExporter]

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

Original comment by potapov.s.a on 20 Nov 2012 at 10:09

[GoogleCodeExporter]

Попробую, большое спасибо за потраченное 
время!
Еще один момент, может кто знает, как 
развернуть этот самый прокси на отдельном 
серваке??? Это вообще возможно или этот 
прокси какой-то особенный и есть только в 
openfire и в ejabberd?

Original comment by koledas...@gmail.com on 20 Nov 2012 at 10:24

[GoogleCodeExporter]

Можно вообще взять отдельную реализацию, 
он подключается как обычный jabber сервис или 
транспорт.

Original comment by potapov.s.a on 20 Nov 2012 at 10:30

[GoogleCodeExporter]

Можно поподробнее, или скажи где почитать. 
Уже 2 дня ищу...

Original comment by koledas...@gmail.com on 20 Nov 2012 at 10:33

[GoogleCodeExporter]

Вот, например, есть реализация 
http://code.google.com/p/proxy65/

Original comment by potapov.s.a on 20 Nov 2012 at 10:39

[GoogleCodeExporter]

Ага, теперь разобрался. Большое спасибо! Он 
и раньше мне попадался, но прочитав не 
внимательно я подумал, что это плагин для 
Jabberd'а. Теперь я понял как его прикрутить к 
Openfire. Завтра буду ставить.

Original comment by koledas...@gmail.com on 20 Nov 2012 at 12:35

[GoogleCodeExporter]

Сегодня развернул новый прокси (proxy65). 
Предварительно отключив старый. После 
всего этого ребутнул сервак. И настроил 
клиентов.
Вы будете смеяться, но на новом проксе тоже 
самое :)
Видимо где-то реально заморочки с сетью... 
будем дальше разбираться.

Original comment by koledas...@gmail.com on 21 Nov 2012 at 6:12

[GoogleCodeExporter]

Вобщем разобрались. Проблема была 
действительно в сети. А именно в настройках 
сети VipNET. Дико извиняюсь за потраченное 
время. Теперь Vacuum-IM 1.2.0.1859 работает 
прекрасно со стандартным прокси openfire.
Вопрос закрыт.

Original comment by koledas...@gmail.com on 23 Nov 2012 at 3:43

[GoogleCodeExporter]

Original comment by potapov.s.a on 24 Nov 2012 at 6:56

• Changed state: Invalid