LINUX.ORG.RU

Устойчивость к упоротым каналам связи?

 , ,


0

2

Имеем энное количество автономных штуковин с 3G, разбросанных в том числе в далёких дырах с очень слабым интернетом; штуковины временами выходят на связь и передают пакет с накопленными данными, ориентировочно - килобайт 10.

В некоторых особо глубоких дырах по какой-то причине сеть работает странно: заходишь по SSH - всё летает, пинг 300 мс, можно свободно делать всякое, но при попытке вывести сразу несколько строк - например, дёрнуть df - начинаются дикие тормоза, выхлоп печатается секунд 30, и часто соединение рвётся напрочь. С MTU играть пробовал, разницы строго ноль; всё это напоминает очень злой шейпинг. Логично, что протолкнуть 10 Кб полезной нагрузки через такое соединение не удаётся.

Вопросов, собственно, два:
- существуют ли более-менее стандартные протоколы, автоматически подстраивающие скорость передачи под подобные больные условия?
- не пахнет ли описанная ситуация какой-то детской ошибкой?

mosh хорошо переносит внезапные многосекундные задержки, больно узкий канал, и даже потерю соединения. Он не то, что бы стандартен, но в репах присутствует. Особо упоротое решение для передачи файлов - гонять X/Y/Zmodem поверх mosh.

token_polyak ★★★★
()
Последнее исправление: token_polyak (всего исправлений: 1)

Плюсую mosh. Использовал его при работе из поезда.

aquadon ★★★★★
()
Ответ на: комментарий от token_polyak

Тут даже не в удобстве доступа проблема - фиг с ним, я как-нибудь перебьюсь - а в том, что автоматика циклически пытается отправить данные, и её циклически от сети отрубает.

izzholtik ★★★
() автор топика

не пахнет ли описанная ситуация какой-то детской ошибкой?

за интернет не оплачено

anonymous
()

Тут всё просто - если связи нет, её нет :) Я бы плюсанул анона в том плане, что вдруг и правда канал не оплачен, больно уж похоже поведение.

В противном случае разве что увеличивать keep alive и уменьшать mtu (но до пределов, что бы любой служебный tcp пакет помещался разумеется).

pon4ik ★★★★★
()

Если задача чисто файл послать, возможно стоит ещё рассмотреть протоколы на основе UDP. Например что-то в духе UDP расширений bit-torrent.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Когда оплаты нет, у некоторых провайдеров до сервера коннект доходит и сразу после открытия сокета рвётся, никакие данные не идут. Ну, какие-то определённо идут, но дамп на предмет возможности злоупотребить не изучал)
У меня же через некоторое время после начала передачи тупо отваливается SSH + сервер говорит

org.apache.http.TruncatedChunkException: Truncated chunk ( expected size: 8750; actual size: 6512)

izzholtik ★★★
() автор топика
Последнее исправление: izzholtik (всего исправлений: 1)

Необходимо тестировать софт на эмуляторах плохого канала, где пакеты режутся дропаются, переставляются местами

Не верю в шейпинг, пусть эти 10 килобайт хоть на 30 частей разобьют, но доставить обязаны

Можно в самом деле применить чисто свой протокол поверх TCP, разбивая пакет на много маленьких - самостоятельно

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)

если только файло гонять, то syncthing/resilio sync.
как максимум активного файлообмена - две папки на каждое соединение. одна - отправить, другая - принять.
и похеръ до скорости, обрывов, пъяных серверов и всего остального, ибо все оборванное докачается, а переданное, после записи на диск, подтвердится хешами.

pfg ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Кстати, 2 скора этому господину, есть tc netem где подобные ситуации можно воспроизводить пробовать.

pon4ik ★★★★★
()
Ответ на: комментарий от izzholtik

Ну тогда UDP, обмазаться сжатием, FEC, молиться, поститься, и слушать радио Радонеж.

token_polyak ★★★★
()
Последнее исправление: token_polyak (всего исправлений: 1)

[code]#/bin/sh

{ seq 1 $1 | tr -dc \n | tr \n «A»; echo; }[/code]

запускай с разным аргументом(число байт) и смотри на сколько байтах всрётся канал.

salozar
()
Ответ на: комментарий от salozar

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

salozar
()
Ответ на: комментарий от salozar

ах да. wireshark у себя запусти чтоб видеть как именно будут задерживаться лагающие пакеты.

salozar
()

Когда модем далеко, то он даже чтобы достучаться до вышки несколько раз сигналы шлет. Не такая уж и жопа чтобы жаловаться. Тот же UDP создавали для того, чтобя соединение не держать, а просто слать. Вот оно соединение пытается выпрямить, а ему сигнал слабый приходит. Конечно он безбожно тупит.

anonymous
()

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

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

Интересно, спасибо.

У меня 4.4, и именно bbr недоступен, но вектор поиска понятен.

izzholtik ★★★
() автор топика

всё это напоминает очень злой шейпинг. Логично, что протолкнуть 10 Кб полезной нагрузки через такое соединение не удаётся.

Вообще, да. А тариф хотя бы ноутбучно-роутерный???

Shadow ★★★★★
()

«автономных штуковин с 3G» что за штуковины?
какой уровень сигнала 3G на штуковине? SINR и т.д. ? усилитель, антенна есть?
зарежьте скорость на отправку нужных данных типа шейпером - снизьте burst
Может эта штуковина генерить мусор, который забивает и без того нестабильную связь с 3G вышкой?
Теоретизирую - у TCP протокола есть окно, попробуйте окно сделать = 1 (т.е. подтверждать прием каждого пакета с данными), это должно снизить burst трафика, тем самым снизится нагрузка на 3G канал, учитывая задержки по 300мс. https://networkguru.ru/kakie-parametri-vliyaut-na-proizvoditelnost-prilozheniy/
попробуйте потестить канал iperf, сервер на удаленной стороне - где 3G, инициатор тестов у Вас под рукой, иначе потеряете точку

Vlad-76 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.