gat3way

Packet loss в 802.11 май няма, т.е има естествено де поради гореизброените причини, ама ack/retransmit му беше заложено още на data link ниво, не като при етернетя да се грижи за тва некой протокол отгоре, т.е дори да е UDP, шансовете са да се преизпрати и да не се загуби все пак пакета заради тва, естествено покрай тая работа и съответния джитър и преебана латентност си идва.

Са тва дали сработва като има много трафик да лети там у ефира, нямам идея, сигурно тея пакети дето трябва да се преизпращат стоят в некъв буфер дето не е безкрайно голям и кога е такава ситуацията, вече си има "истинска" загуба на пакети, поне звучи логично да е така, ама как е наистина ба ли му майката.

На ниско ниво пробва да re-transmit-не неколко пъти и се отказва.

След това ако протоколът на по-горно ниво е TCP, тогава TCP забелязва липсващите пакети и ги re-transmit-тва то.

Това обяснява защо тубата и фейс-а работят (те използват HTTP, което стой вурху TCP). Аповете използват и background app refresh, който буферира на заден фон.

Вероятно софтуерът на жена му използва некой custom protocol върху UDP.

А може и да е друго. Сещам се преди години имахме подобен проблем с една мобилна апликация. Викам на мобилния dev “Па дигни timeout-a на http client-a” и проблемът се реши.

Реба, пробва ли да скенираш на кви канали са wifi мрежите на комшиите и да сложиш твойта мрежа на некой свободен channel?