Прежде всего, я попробую посмотреть, возможно ли сделать соединение более стабильным. Помимо передачи файлов, я не думаю, что полезно работать с соединением, которое прерывается каждые 90 секунд.
Простой USB WiFi-адаптер может творить чудеса (во-первых, выяснить, какое устройство на самом деле вызывает отключение: хост 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 * требуются права доступа в любом случае):
#!/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
