Прежде всего, я попробую посмотреть, можно ли сделать соединение более стабильным. Помимо передачи файлов, я не думаю, что полезно работать с соединением, которое прерывается каждые 90 секунд.
Простой USB USB-ключ может творить чудеса (во-первых, выяснить, какое устройство на самом деле вызывает отключение: хост A, хост B или точка доступа?
Возможно, Linux не имеет ничего общего с потерей сигнала, но это скорее вопрос WiFi нестабильности таковому . Попробуйте заблокировать точку доступа на более низкой скорости. Даже мизерная скорость 11 Мбит / с, если она надежна, превзойдет слабое соединение со скоростью 54 Мбит / с. И очень часто карты будут пытаться увеличить скорость, даже если, учитывая ситуацию, они не смогут доставить .
Если вы застряли с соединением, которое прерывается и пересматривается каждые 90 секунд, лучше всего подойдет rsyncили разбить файлы на достаточно маленькие кусочки для фильтрации между повторными переговорами:
split -b 10000000 file.mp4
будет разделить этот файл на N куски (скажу) 10 МиБа каждый, называется xaa, xab, xac... После завершения копирования, вы можете собрать куски с другой стороны , используя cat.
Другая возможность может состоять в том, чтобы вообще отказаться от TCP и использовать протокол на основе UDP, например UDT или UFTP .
Наконец, вы можете установить простой веб-сервер на одном компьютере и использовать wgetили любой HTTP-клиент, поддерживающий целостность поиска, диапазон байтов и автоматическую повторную попытку, чтобы загрузить весь набор файлов (что, если их еще нет, было бы лучше сжать).
Это дольше для установки, но затем оно должно продолжаться автоматически и использует доступное и проверенное и проверенное программное обеспечение (apache, wget).
Приходите снова - ушли снова - Финнеган
Предполагая, что вам необходимо убедиться, что сценарии синхронизированы, или вы потратите много времени на соединение, вы, вероятно, можете поиграть с одним из них iwconfig или ifup/ifdownзаставить его работать так:
while true; do ifdown wlan0; ifup wlan0; sleep 90; done
или если вы хотите запустить его в виде скрипта (для запуска команд if * все равно потребуется root-доступ):
#!/bin/sh
while true; do
echo "Going down..."
ifdown wlan0
echo "Coming up..."
ifup wlan0
echo "Ready"
sleep 90
done
(Надеюсь) лучший способ
Проблема со сном 90 секунд заключается в том, что, если что-то действительно странно не работает в маршрутизаторе, время его работы не будет точно равным 90 секундам. Таким образом, мы тратим много времени на то, чтобы оставаться на ногах, когда оператор Wi-Fi не работает, или на спаде, когда оператор Wi-Fi мог оставаться на связи.
Итак, допустим, что маршрутизатор имеет IP 192.168.0.1, на обоих хостах Linux мы запускаем
#!/bin/sh
IP=192.168.0.1
while true; do
if ( ping -f -c 3 -w 1 $IP | grep "0 received" > /dev/null ); then
ifdown wlan0
ifup wlan0
# Extra time: we MUST be sure the network is up!
sleep 5
fi
sleep 2
done
Этот сценарий будет снимать три пакета в направлении маршрутизатора. Пакеты довольно малы и не сильно влияют на пропускную способность. Один отброшенный пакет может быть случайным, два совпадением - три отброшенных пакета запускают цикл питания WLAN. Надеемся, что это должно тратить не более двух секунд на цикл (вместо 90 секунд) и никогда не запускать цикл питания, если в этом нет необходимости.
Само собой разумеется, что функциональность PING должна быть проверена на маршрутизаторе - если маршрутизатор не отвечает на запросы ping или отбрасывает ICMP, когда находится под нагрузкой TCP / UDP (например, из-за приоритетов протокола), тогда вторая версия сценария может выполнить гораздо больше вреда, чем пользы.
Но теперь, когда я думаю об этом, вы пытались поиграться с iwconfigпараметрами? Например порог чувствительности:
Sens Установите порог чувствительности. Это определяет, насколько чувствительна карта к плохим условиям работы (низкий уровень сигнала, помехи). Положительные значения предполагаются как необработанные значения, используемые аппаратными средствами, или в процентах, отрицательные значения принимаются как дБм.
В зависимости от аппаратной реализации этот параметр может управлять различными функциями.
На современных картах этот параметр обычно контролирует порог хэндовера / роуминга, самый низкий уровень сигнала, для которого аппаратное обеспечение остается связанным с текущей точкой доступа. Когда уровень сигнала становится ниже этого порога, карта начинает искать новую / лучшую точку доступа. Некоторые карты могут использовать количество пропущенных маяков, чтобы вызвать это. Для высокой плотности точек доступа более высокий порог гарантирует, что карта всегда ассоциируется с лучшей точкой доступа, а для низкой плотности точек доступа более низкий порог минимизирует количество неудачных передач обслуживания. На более старых картах этот параметр обычно управляет порогом отсрочки, самым низким уровнем сигнала, для которого аппаратное обеспечение считает канал занятым. Уровни сигналов выше этого порога заставляют аппаратное обеспечение блокировать его собственную передачу, тогда как слабые сигналы игнорируются, и аппаратное обеспечение может свободно передавать. Обычно это тесно связано с порогом приема, самым низким уровнем сигнала, для которого аппаратное обеспечение пытается принять пакет. Правильная установка этих пороговых значений не дает карте тратить время на фоновый шум, в то же время получая слабые передачи. Современный дизайн, кажется, контролирует эти пороги автоматически.
Пример :
iwconfig eth0 sens -80
iwconfig eth0 sens 2