sfstudio

Ещё раз и внимательно читаем, люди сами делают и отлаживают эти контроллеры. Нет тут ни вариантов ни микротиков.   Вообще то, что есть уже в теме описано, фантазировать тут не требуется.

1) много там на 100МГц напередаёшь? =) Динамическую регулировку надо 2) при этом умотаем SNR линка до уровня чуть в эфире сирануло и умерло 3) вы для меня прям глаза раскрыли, я в курсе что они SKU table в рожу вытащили

Я ХЗ,что он хотел сказать, но дан конкретный совет без уточнений, а вообще там хоть на одном линке низкие канальные скорости юзаются или нет? Ну это одна из разновидностей синдрома лифтёра... Сегодня он видимо в ударе, ибо вот прям как пришёл, как блин ответил ответил, и тут и вот тут https://forum.nag.ru/index.php?/topic/146152-podskazhite-po-wi-fi-oborudovaniyu-v-ceh-na-100-klientov/&tab=comments#comment-1523035 =))) Полный трэш. Не читай - отвечай. Не задавай вопросы - рекомендуй. P.S. Может кто его переплюнул по числу постов и терь нагоняет? =)) Пусть не переживает, он тут один такой. =) Уникальный. =)

Микротики неосилили cpufreq динамически? Бяда. Уменьшение на 100МГц частоты проца это мягко сказать ниочём. Это как? =) Ну т.е. data rate в полке сверху, уменьшаем мощность на низких рэйтах (причём только для data) которые не используются вообще и получаем выигрыш по потреблению? Даааа, круть. =))

Ещё один эксперт вида не читай - сразу пиши. =))))))))) Контроллеры самодельные. Извращения с "каждому станку" по микротику тут нахрен не нужны. Как и "удобство управления сетью" ибо не будет гипердурной сети в виде микротиков. Сеть должна просто работать будучи настроенная один раз. Что не так с вашими микротиками, что ими нужно постоянно "управлять" я хрен знает. Но после таких высказываний я бы точно не стал бы их даже думать брать. Железка требующая постоянного внимания это хрень, а не оборудование. Это говорит микротиковод? =))) Нука расскажие что такого ваш микротик относительно рекомендуемых AP1/AP2 умет полезного и нужного в этой сети? Давно я не слышал столь редкой ахинеи. Лучше сразу ехать и бить морду саабу, особенно когда вместо решения из 4х АП, предлагается нагородить идиотизм из 80+ микротиков. =))

Когда технарь произносит слово плохо это уже звоночек. Что бы не работало плохо, у технаря должны быть голова, руки и знания. Можно закупить золотое железо и работать не будет вообще. Неумение подобрать железо под задачу, и часто даже разобраться в вопросе поголовная проблема современных офисных админов за которую в итоге платит хозяин предприятия. Причём независимо от выбора вендора железяк. Вот вообще. Ну и если технарь вообще задаётся вопросом кто будет по шапке получать, то это сразу чёткий признак слабоватой технической грамотности. Отсюда выбор осуществляется "на сколько бабла хватило", это по разумению такого технаря как-то коррелирует с получать по шапке и чем дороже и больше понтов тем типа вероятность что ткну от балды и оно заработает и будет работать как положено выше. На самом деле, в случае низкой компетенции решающим фактором оказывается рулетка, либо заработало и работает пока не выгнали, либо не работает (работает абы как это тоже не работает). Всё тупо и просто. Видал я таких технарей. 2АП + контроллер. =))) И ещё раз причём тут wifi? Это технический форум. И если сказано, что мотор это лёгкая интеграция с логистической системой, то внезапно вам задают вопрос, в каком месте и каким боком и чем оно легче любого другого вендора и где там эта самая интеграция? Не напрягайтесь, правильный ответ тут ничем, никак и нигде. P.S. Кстати, вы действительно считаете что производитель ваших терминалов и прочего тестил в них wifi кроме как с тем что попалось по другу и может хоть что-то рекомендовать? =) Вот тут вы тоже не угадали. Они тупо прайс откроют и назовут десяток приглянувшихся позиций от 3-4х вендоров и в зависимости от ценника расскажут, что лучше вот это, а дешевле вот это. Причём HP отметут, а Aruba посоветуют, и похрену что HP арубу купил уже лет как 5ть и просто в прайсе бардак. =) И всё. Они ровно так же мыслят. А что там кто и с чем тестил по факту вообще никто выяснять не будет, ибо разработчик уже или умер или вообще где-то непонятно кто он и из какого китайского подвала вылез, да и тестил с тем что висело в офисе/стояло дома. Это тоже поголовно и почти без вариантов.

Простые слова и простые буквы. Я спрашивают как оно с логистикой интегрируется, как выбор wifi оборудования влияет на вашу интеграцию с логистикой? Это весы и сканеры интегрятся, а не wifi оборудование, которое трафик гоняет. Отсюда фраза с точки зрения технаря не имеет смысла от слова вообще и попахивает диким муркетингом. Ибо нет тут никакой разницы какое железо будет организовывать wifi, не влияет это на интеграцию с логистикой. WiFi ничего о логистике не знает вообще ибо это тупо транспорт. Весы, сканеры блин. Мух-то от котлет нужно отделять.

Если бы вы бы чутка повнимательнее бы почитали, то увидели бы, что контроллеры тут вообще самоделка. WiFi интегрированный с логистикой это как? Максимум что придумывается так это какой-нить indoor location service, и то не очень ясно напуркуа.

Ааа. Оно при кратковременных отвалах срабатывает? Ну да, забавно.

Не вкурил про визиты домой. Но охранка на wifi это весело да. =))) Вообще наблюдается тотальная шиза по впихиванию невпихуемого и натягиванию ненатягиваемого. Но в случае с охранкой ССЗБ только сам клиент, ибо трафика там хрен да маленько и не постоянно и никому он не мешает. Трахается так сказать самостоятельно. Ну а что до таких контор

Опять началось. Есть там и OKC и PMK cache, а 802.11R как и OCK и PMK cache в сетях без WPA вообще не работают и не могут. Ибо нет места куда их применить, ключей-то нет внезапно, нечего кэшировать и ускорять. 802.11r это не хэндовер по сути, а костыль для сокращения процедуры аутентификации, причём только в сетях с WPA. В открытых сетях оного нет от слова совсем. PMK Cache вообще часть базовой логики всей подсистемы WPA и если её выкусить то никаких WPA работать не будет. Это архитектурно так, что у QCA что у MTK, что у RTL. И даже реализация на уровне hostapd не позволяет оторвать pmk cache не сломав вообще WPA к чертям. А с недавних пор и отключить его полностью, можно лишь время флуша кэша до 1с уменьшить и всё. Всё что есть в 802.11r от хэндовера это MDIE. Всё остальное касается исключительно ускорения фазы аутентификации. Вот тут вы мне можете не лить в уши. Я чуть ли не наизусть уже знаю всю эту процедуру в подробностях и куда она вкорячена у того или иного чипмэйкера в логике. И ваш камбиум не исключение. Как и убик. Вот микротик ХЗ чего тормозит. =)) Насчёт релизов или бет, нет щас под рукой убика. Но скорее всего тоже из разряда "в уши лью". Исключения https://help.ubnt.com/hc/en-us/articles/115004662107-UniFi-Fast-Roaming#fast roaming with unifi тут указаны У меня нет поводов доверять вам больше чем официальной инфе. Описание от альянса по поводу K/R чёткое и понятное без фантазий: На этом собсно и всё. Так что ещё раз повторюсь, занимайтесь лохотроном где-нить в другом месте. Да да, я ж такой провокатор. Перестаните пи?(*(ть - никто не сможет и спровоцировать.

Я вам давно предложил самоликвидироваться в раздел кабмии и закончить все оффтопы в профильных разделах конкурентов ваших возлюбленных. Но вы всё ещё тут. =))) И продолжаете пороть чушь. Прекращайте, ей больно. Кто бы куда не ходил не отменяет никак абсолютно, что если речь идёт о wifi то это 802.11a/b и дальше. Если речь о чём-то другом то это не wifi и что там было одному богу известно что нагорожено. Поэтому ещё раз говорю, что нехрен подменять понятия, wifi это вполне конкретная штука, а не то что там было до. А что вы там в 1999м подключали в 2018г это тема для разговора за пивом в дружеской компании, а не на техническом форуме. Ну или для мемуаров. Внезапно, люди имеют свойство ошибаться в циферях, называется зарапортовался. =)))) Зато пукнуть уже успели. Буд-то я бы выше говоря о наличии свободных реализациях Rate ALG для 802.11 мог бы заявить о появлении wifi только в 2009м. =) Голову то включайте.

Да да, я вижу. =)))) Брысь уже. =))))

Тьфу 1999го. =)

Я не придираюсь к словам. А конкретизирую ибо не готов разговаривать непойми о чём. WiFi называется 802.11, а не любое наколенное творчество. Т.е. 802.11a/b (конец 2009). Так что нехер тут возбухать. Мы на техническом форуме, а не за пивом где можно рассказывать о нестандартном wifi. Ау... Могз проснись. Грю каким боком выбор канала к обсуждаемой теме. Ну проводиться там оценка BER/PER и что? Я говорил что везде где проводиться оценка PER это RateALG ? =)) Вот вроде нет, я грю что любой RateALG так или иначе как последний критерий для подстройки использует PER. Не надо передёргивать. И ваша смена канала по BER/PER вообще близко не в тему. И скорее из разряда, когда аргументы кончились притяни за уши какую-нить херню и попробуй представить,ч то оппонент заявлял что-то по теме этой херни.=) Тоже не редкая у вас привычка. Завязывайте уже. В очередной раз повторяю. =))) Вот это бомбануло. Ну работа на перфокартах да, это говорит о многих очень полезных навыках. Грю работали вы там на перфокартах или крестиком вышивали, и кандидат каких наук, а может и вообще амазонка-гермафродит с нибиру тут никому не интересно. Более того, вас никто ничему не учит, поздно уже, да и не нужно.

Либо с wifi либо с нестандартным. =)) Не нужно всё что CSMA юзает называть wifi. Ну т.е. выше опять солгамши. Отлично. И правильно сделали. Это вообще сюда каким боком? =))   Мне это должно о чём сказать-то? =) И почему меня должно беспокоить в какой стране мира находятся их программисты или главный офис. Есть контора, есть контакты. Может они там все заделались коренными тайцами, а с Украины набирают себе коллцентр. Вот мне какое дело до этого?

Для сравнения minstrel: 1) базовая часть 700 2) Legacy режимы 650 3) HT режимы 1070 4) VHT ещё столько же Итого 3,5к строк кода полная реализация minstrel для всех ныне поддерживаемых режимов кроме AX.

Как страшно жить. Остальное поскипано ибо годиться для рассказа за пивом и только. Чего? Скажете не вы врали тут недавно бегая с R/OKC у убиков, при этом свято же сами верили видимо. =))) Эта самая мат модель в итоге и реализуется в виде кода, т.е. выливается в конкретный алгоритм для железяки, не редко попутно с доп изысканиями и оптимизациями. И это нормально и это у всех так. Сначала модель и анализ поведения на основе её на бумаге, затем реализация в коде, затем отладка на кошечках, затем серия с доработкой по фидбэкам с юзверей. По другому нифига не выйдет. Десятками тысяч описывается моделька, тот же используемый нами rate autogroup alg это 54914 строк кода, если выкинуть обвязку, коментарии и прочие останется около 10к строк функциональных. Так что не надо перевирать. И это достаточно сложная штука заточенная для P2MP. А вот вынос регулировки агрессивности для решения конкретной проблемы черезчур оптимистичной оценки это обычно действительно 10ток строчек кода в дровине и столько же в юзерспэйсе.

Сразу грю, то что выше никак не спасёт от криво работаюшего ремапа нанда. Он там полусофтовый (у амлоджик). Ещё свежо в памяти с какими матами я это всё чинил на планшетах для Digma на амлоджике. И вот почти уверен, что как минимум в 50% случаев помирание прошивки связано не с питанием, а именно с корявым ремапом.

За враньё за ваше зацепились и за вездесрущесть, а так же неподобающее поведение, и агрессивный муркетинг камбиума в специализированных разделах другого вендора. Вашего мнения о говне не говне я не вижу что бы спрашивали. Вопрос задан конкретно и ответ ожидался от людей у кого такой вариант развёрнут в реальной эксплуатации. Измышления на тему LA и проичие прелести с наездами на окружающих (которые вы и стартанули) к топику вообще не относятся. Как и многократные переобувания и демонстрация регалий на которые всем положить. Вам ровно о том и говорят, что уже просто настолько вездесрущи, что специально обходя стороной ваш раздел куда не плюнь везде вы со своим ынтырпрайзным камбиум, по поводу и без. Был бы раздел о секс игрушках, чую и там бы отметились бы. Завязывайте ибо реально за*())ли. Уж простите, но это единственное правильное слово.

Что вы там делали и что вы знаете вопрос отдельный. В 90х не было не проприретарных реализаций RateALG в wifi вообще. Первая реализация открытого Rate ALG для 802.11 это где-то середина нулевых. Я уже молчу о не подходят. =) Вы современную реализацию видели вообще, или застряли в 90х? =) Да да. Куда ж мне до вас. =))) Как я блин жил до того как вы мне это сказали. Пойду утоплюсь чтоль. Такие как вы арХитехТоры склонны к подобному. Т.е. делать из банальной проблемы ошибку в ДНК, только поздно доходит, что ДНК эта ваша, а ошибка приводит к раку. =) Вы обо мне ничего не знаете, как впрочем и о алгоримах убиков, исключительно ориентируетесь на собственные фантазии и великие достижения на лоне видимо научного кандидатства. =) Не все кандидаты одинаково полезны. Вон Елена Ермакова тоже вполне себе кандидат, однако это не мешает ей нести ахинею о амазонках-гермофродитах, небиру, страшном ГМО и т.д. Тоже видимо видит системную, глубинную проблему. =) А предложение более чем нормальное. Если купленная железка работает не так как ожидалось - есть обратная связь с вендором. Она внезапно для этого и существует. Ну что бы там, у вендора, с архитехторами-кандидатами связь иметь. =) И раз ваш любимый камбиум осилил, то нет никаких причин не осилить остальным. Ну если только камбиум не поработил пришельца, но это уже не ко мне, а к кандидатам.

Да да. =))) Вот вам точно о моём уровне мышления, квалификации и прочего знать не откуда от слова совсем. Как и для того что бы понять почему конкретный алгоритм ведёт себя коряво в конкретных условиях нужно быть как раз не архитектором витающим в облаках рассуждающем о высоких материях. Нужно уметь здесь и сейчас интерпретировать полученные данные, желательно получив их вот прямо тут прям с железки и придумать что с этим всем делать и как исправить ситуацию. Архитекторы уже своё на архитектировали, так что на выходе имеем, что имеем. Тут уже время программиста пытаться хоть как-то это заставить работать правильно.   Ещё раз на пальцах. Измеренный вами CINR может служить лишь критерием для выбора стартовых значений рэйта + лимитов. Всё остальное так и сяк корректируется исходя из накопленной статистики PER. Более высокую адекватность алгоритма текущим условиям даёт получить именно грамотный подход к построению алгоритма принятия решений коррекции рэйта по PER, а не наоборот.

Ну и не вижу противоречия. Расчётный рэйт и реальный рэйт скорректированный по PER как только пошли данные это разные сущности. Собсно и отработал тот самый механизм подстройки. Как гриться вам шашечки или ехать? Опять таки репорт убикам и оценка может разом стать другой. Откуда дровишки в очередной раз? Измышления на уровне фантазий. Кода вы не видели. Более того, rate alg штатный даже с тех пор у Atherps/QCA поменялся. Да и не только у них. И в очередной раз поменялся с приходом Wave-2. И даже штатная реализация вполне себе способна не завышать ничего, а агрессивность оной вполне можно вынести в виде крутилки. Сложностей в этом 0. Пока из подтверждённого я вижу, что исключительно расчётная модуляция, т.е. то что используется как стартовое значение высчитанное из CINR завышена по словам хабарова. Но вот на это можно смело забить. Это влияет лишь на тот самый короткий момент когда передачи не было и вдруг полились данные. ООкла спидтест это такой измеритель, что лучше бы его не было. =) Хотя новая их версия стала хоть в каком-то адеквате что-то мерять. И я бы на основе показометров оных вообще бы выводов никаких бы не делал, ни по проводу, ни по радио. А писать да, снимать статистику в т.ч. по ошибкам в динамике и т.д. и т.п. предлагать пустить на конкретный линк дабы могли сами всё увидеть и снять нужные данные, а так же опробовать изменения. Чай они не тупее меня, и не менее заинтересованы в том, что бы у юзверя было всё хорошо. Разбираться с неадекватным поведением rate alg удалённо мне лично приходилось, и более чем успешно. Только его заваливало в обратную сторону из-за ошибки которая проявляла себя только в конкретных условиях. Опять таки нет ничего сверхсложного. Но вот с ооклами послал бы сразу в сад не задумываясь.

Артём. Нет никакого мультикаста после роутера по радио, независимо от источника. Вот вообще нет. Там M2U работает иначе фиг бы ты чего вообще бы посмотрел. Вставай по утрам и повторяй: "возможность просмотра ТВ поставляемого мультикастом оператором по радиоканалу обеспечивается его предварительной конвертацией в unicast посредством M2U на уровне моста куда включен радиоинтерфейс или драйвера радиоинтерфейса". =) И это не решение каждого оператора. Это по другому называется. PLC не гадит всем и вокруг. К чему тут какие-то узки лучи и прочие фантазии я ХЗ. Но если хочется гонять ТВ по радио - нужно использовать тот спектр где щанс наименьший насрать кому-либо. В 5ГГц всё что выше 64го канала не может быть использовано большинством серийных мобильных клиентов, однако разрешено в РФ. Если так хочется радио то могу предложить tri band устройства с выделенным модулем под ТВ в этом диапазоне предложить сделать. Т.е. фиксировать к чёртовой матери частоту 3го модуля по central freq одного из верхних поддиапазонов в 5ГГц. Да, дорого, но уж простите, либо тяните кабель, либо PLC либо платите за "удовольствие". И вот тогда проблемы не будет т.к. засёр в полосах общего движения постоянный не появиться, да и соседи с обычными клиентами мешать не будут. А т.к. всё же у примерно 30% людей есть моСК (по данным ВЦИОМ =))) то всё это будет доолго и успешно работать, т.к. вероятность получить 2х 70% ещё и с баблом на игрушки с радио вместо кабеля сильно ниже чем если засовывать всё в одну кучу. Но ещё раз, проще, надёжнее и т.д. PLC. P.S. Ты надеюсь в новых приставках модули не от AMPAK аля 6225 заюзал? А то тебя ожидают ещё те приключения. =) PP.S. Ну и развлечение с сетевыми фильтрами это локально у ищущего жизнь без проводов, а с радио это развлечение всем соседям. Чуешь разницу? Мне вот пофигу кто с ками филтьтрами развлекается, а вот эфир в кашу из-за кретинов, это уже становиться моей проблемой. Ну дык, что бы не было холивара, следует воздерживаться от таких изысков. Ибо я "зная планету"... =)))) Те кто сделал ремонт не проложив ни одного кабеля юзают плинтуса с кабельканалом, PLC, отвёртку "по монтажной пене" и т.д. Вариантов миллион. А уж кретинизм с размещением роутера в Ж (в корридоре) с попытками через всю квартиру по радио гонять приводит к тому, то и скорость никакая, а эфир под завязку утилизирован. Так что в любом случае решение заведомо ущербное и нужно тянуть кабель. Думать нужно хотя бы на шаг вперёд, а с ТВ по wifi это вида - ну пока работает, а потом авось. P.S. Слетающие прошивки при скачках питания у всех это сильно. Во времена ext2 чтоль вернулись? Дарю решение. --- kernel.orig/fs/file.c 2017-06-27 14:49:32.000000000 +0500 +++ kernel/fs/file.c 2018-10-16 18:54:35.702580563 +0500 @@ -601,6 +601,15 @@ rcu_assign_pointer(fdt->fd[fd], NULL); __clear_close_on_exec(fd, fdt); __put_unused_fd(files, fd); + + if (file->f_mode == (FMODE_WRITE | FMODE_LSEEK | FMODE_PREAD)) + sys_sync(); + spin_unlock(&files->file_lock); return filp_close(file, files); И всё, вероятность слётов резко уменьшиться в сотни раз без существенного падения производительности. Суть проста, после закрытия дескриптора (close_fd) сбрасываем кэши принудительно. Т.е. по окончанию записи гарантируем что ничего в файловом кэше не зависло, что может привести к развалу FS. Пользуйся.

Абсолютно не обязательно. Никто не мешает использовать открытые и свободные реализации аля minstrel и иже с ними. Что не редко и делают. Дык вы же сами родили "стандартаная или слегка модифицированная" =)) Опять переобулись? =) =)))) Я не вижу массовых репортов от юзверей. Пока только у вас он неадекватен применению. Нет, это значит что в конкретных условиях убик слишком оптимистично оценил канал и юзверям нужно репортить вендору. Пусть выясняет по каким причинам это происходит и что в его алгоритме не так. Но не вижу ни массовых стонов, ни исправлений. А т.к. ни исправлений ни крутилки нет форум их не забит под завязку и продажи не умерли, то опять возвращаемся к тому самому мальчику и тем же самым сусликам. Это не сверхзадача никакая. Реализация RateALG это максимум несколько тысяч строк кода. Ладно десяток. =) Вполне подъёмно для отладки в т.ч. удалённо и корректировки алгоритма, в т.ч. выноса крутилок или даже рождения отдельного под задачу алгоритма за вполне обозримое время. Я не верю, что убики за десяток лет неосилили банальшину. Ну и у вас нет автомобиля, и у вас автомобиль сломан это мягко сказать не одно и тоже. Не находите? =)) Откуда дровишки? Вот нет у вас данных использует или нет и это только догадки. Более того, раз вещаете о потерях то не нужно даже CINR смотреть, достаточно просто посчитать PER по TxRetry и TxRetryError в т.ч. c one sec таймеров MCU и принять решение о снижении рэйта. Это штатно во всех буквально rate alg, как в свободных так и в проприретарных. Это их основа. Если этого не происходит - репортим вендору. И опять см выше. Не вижу что бы кто-то кроме вас жаловался. Я то как раз владею ровно теми терминами которые определены чипмэйкерами той самой логики которую использует в т.ч. камбиум. То что вы там пытаетесь натянуть сову на глобус это не мои проблемы. Не я пытаюсь из WiMax/LTE сделать WiFi. =) Так что терминология ровно та, что должна быть. И нет, мы говорим о разных вещах. Вы гадаете по фотографии чего у кого есть и насколько адекватное и как работает. Я подобным не страдаю, именно потому что изнутри знаю и вижу как работают механизмы подстройки рэйта и какие данные есть на входе, какие подходы существуют и какие применимы исходя из конкретных возможностей той или иной логики. Вы основываетесь только на каких-то внешних наблюдениях непонятно в каких условиях и вообще без подтверждения чего либо и как либо. Только слова причём они у вас на ходу самомодифицируются. =))))) Ну и существенная разница между нами, я не готов фантазировать не видя кода, что там используется, а что нет по факту. А вот вы запросто гадаете по фотографии. Есть дофигищи причин почему Rate ALG может как страдать оптимизмом, так и пессимизмом и чаще всего это будет связано с неверно посчитанными порогами rate up/down относительно PER. CINR/SNR это прекрасно, но задача стоит удерживать контроллируемое число перепосылов и по возможности избегать потерь,а значит основные для нас данные это те самые TxRetryCount/TxRetryErrorCount и т.д. и т.п. По CINR можно примерно прикинуть какой стартовый рэйт задать от которого потом плясать будем корректируя вверх или вниз исходя из данных по числу повторов и т.д... Т.е. уточнять какой рэйт юзать на передачу что бы снизить потери будет один фиг по вышеозначенным счётчикам ретрансмитов и иже с ними. Можно из CINR ещё и лимит для rate_up посчитать и задать, но собсно на этом и всё. Даже более того, и без этого лимита алгоритм должен корректно отрабатывать не пытаясь улететь вверх до упора, или свалиться в низ при любом чихе. И если это не так - то где-то ошибка. И даже если CINR совсем не учитывается, то это всё равно ошибка. И ошибка вполне исправимая. И я не могу сказать что в убиках совсем критиноиды работают, что не способны выправить этот момент. Так что даже гадая по фотографии (даже если допустить, что проблема есть), по такому поведению я бы таки грешил не на неиспользование CINR или ещё чего, а именно смотрел бы в самую основу, по которой в конечном итоге будет уточняться оптимальный рэйт. Это если не вдаваясь в подробности, от слова совсем. P.S. Кому интересно в общих чертах может почитать тут (на примере нескольких свободных алгоритмов) http://pages.cs.wisc.edu/~pb/infocom11a_final.pdf собсно цели всегда один и те же, получить макс пропускную способность с минимумом ретрансмитов и по возможности избежать потерь. И хоть в WiFi хоть где-то ещё. Подходов к решению этой задачи море, но все подходы в конечном счёте заканчиваются контролем повторов/ошибок передачи.