-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.91.230.58.69!n
ot-for-mail
From: viktorius <v...@i...pl>
Newsgroups: pl.misc.elektronika
Subject: Re: "roaming" wifi
Date: Mon, 14 Oct 2019 15:16:32 +0200
Organization: news.chmurka.net
Message-ID: <qo1sff$39a$1$viktoriu@news.chmurka.net>
References: <a...@n...neostrada.pl>
<qo1esd$2p1jf$1@portraits.wsisiz.edu.pl>
<a...@n...neostrada.pl>
<qo1k5q$v4a$1$viktoriu@news.chmurka.net>
<qo1m0c$9h$1$Adam@news.chmurka.net>
NNTP-Posting-Host: 91.230.58.69
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 14 Oct 2019 13:16:31 +0000 (UTC)
Injection-Info: news.chmurka.net; posting-account="viktoriu";
posting-host="91.230.58.69"; logging-data="3370";
mail-complaints-to="abuse-news.(at).chmurka.net"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
Thunderbird/60.9.0
In-Reply-To: <qo1m0c$9h$1$Adam@news.chmurka.net>
Content-Language: pl
Xref: news-archive.icm.edu.pl pl.misc.elektronika:747152
[ ukryj nagłówki ]W dniu 2019-10-14 o 13:26, Adam pisze:
> W dniu 2019-10-14 o 12:54, viktorius pisze:
>> W dniu 2019-10-14 o 11:54, Marek pisze:
>>> On Mon, 14 Oct 2019 11:19:00 +0200, sirapacz <n...@s...pl> wrote:
>>>> Poszukaj informacji o wifi mesh
>>>
>>> O ile wiem mesh dot. sytuacji w których AP nie mają dostępu do sieci
>>> i ramki przekazują między sobą. To inna sytuacja, tutaj AP mają
>>> dostęp do tego samego segmentu sieci. Adresy IP przydziela jeden
>>> serwer dhcpd a nie AP.
>>
>> Mesh może być w topologii bezprzewodowej, jak i kablowej. To nie
>> powinno mieć znaczenia.
>>
>>> Mi chodzi o uzyskanie efektu wyboru silniejszego AP i żeby
>>> przelaczenie nie wpływało na aktywne sesje tcpip (stąd centralny
>>> dhcpd). To działa z tym że zauważyłem, że klient często męczy się
>>> przyłączony do słabego AP gdy w przeglądaniu sieci widać inny
>>> silniejszy. Mam wrażenie że to przełączanie jest po utracie zasięgu a
>>> nie przed.
>>>
>>
>> To również ma robić mesh. To już nie twoja sieciówka w telefonie
>> decyduje o przełączeniu miedzy APkami, tylko cały mesh monitoruje siec
>> i nakazuje twojej sieciówce przełączenie "póki nie jest za późno".
>> Dzięki temu poziom sygnału ma być optymalny, a samo przełączenie ma
>> się tak zrobić, żebyś nie stracił za dużo pakietów. Skype, Youtube czy
>> inne streamy mają się nie zaciąć, nie stracić klatki.
>>
>> Sęk w tym, że mesh pomimo, ze jest zdefiniowany w IEEE 802.11s, to
>> jest implementowany przez producentów zawsze troche "po swojemu".
>> Teraz jest tak, jak w poczatkach 802.11g. Jak trzymasz się jednego
>> producenta to jakoś tam chodzi, ale osiwiejesz zanim uda ci się zgrać
>> w meshu urządzenia różnych producentów.
>>
>
> Ciekawe z tym mesh.
>
> Jakoś tak od 802.11b instalowałem sieci w dużych halach (Auchan, Ikea,
> itp) oraz w zakładach na dużym terenie (kilkanaście budynków, parkingi i
> ścieżki dla widlaków).
> Wszędzie było to samo SSID. Ramki nie mogły się gubić, bo aplikacje na
> terminalach (wtedy) dość szybko zgłaszały błąd. Podobnie, kilka
> zgubionych ramek mogło powodować brak wydruku na drukarce mobilnej
> etykiet. Terminale były na WinCE Core lub WinCE Mobile.
>
Ale to był mesh, czy sieć niezaleznie działających APków z tym samym
SSIDem? Jakie było szyfrowanie (jeśli było w ogóle)?
Jak dla mnie to hosty przełączały się samoczynnie. Pakiety się traciły,
ale tylko dzięki retransmisji na poziomie warstwy 1 miałeś połączenie.
Taki pakiet TCP nie zdążył wypaść (a to pewnie monitorowały terminale),
ale pod spodem pewnie było kilkanaście prób retransmisji.
W meshu klient jest sterowany. Przy jednakowej sile sygnału ma się
połączyć z APkiem, który zapewnia np. mniej hopów, albo jest w danym
momencie mniej obciążony transferem (a niekoniecznie jest najsilniejszy
sygnałem). W efekcie taki klient dostanie się do lekko słabszego
sygnałem APka, ale w danej chwili dającego większą przepustowość.
> Co się popsuło, aktualnie jest problem z urządzeniami różnych producentów?
>
Bo oprócz wspieranie wprost standardu, producenci dodają swoje
"optymalizacje" i w efekcie mesh najlepiej działa "swój ze swoim", a nie
"swój z obcym" gdzie ograniczamy się tylko do komunikatów określonych w IEEE
--
viktorius
Następne wpisy z tego wątku
- 14.10.19 20:12 Adam
- 15.10.19 23:21 yabba
- 16.10.19 10:38 Marek
- 16.10.19 11:22 Adam
- 17.10.19 02:11 yabba
- 14.01.21 08:46 Piotrek
- 14.01.21 11:48 Cezar
- 14.01.21 15:24 Piotrek
- 14.01.21 17:41 Mateusz Bogusz
- 14.01.21 18:47 Marek
- 14.01.21 18:57 Marek
- 14.01.21 20:15 Piotrek
- 14.01.21 20:33 Piotrek
- 14.01.21 21:19 yabba
- 15.01.21 08:04 Jacek Radzikowski
Najnowsze wątki z tej grupy
- Koszyk okrągły, walec 3x AA, na duże paluszki R6
- Brak bolca ochronnego ładowarki oznacza pożar
- AMS spalony szybkim zasilaczem USB
- stalowe bezpieczniki
- Wyświtlacz ramki cyfrowej
- bateria na żądanie
- pradnica krokowa
- Nieustający podziw...
- Coś dusi.
- akumulator napięcie 12.0v
- Podłączenie DMA 8257 do 8085
- pozew za naprawę sprzętu na youtube
- gasik
- Zbieranie danych przez www
- reverse engineering i dodawanie elementów do istniejących zamkniętych produktów- legalne?
Najnowsze wątki
- 2025-01-27 Bydgoszcz => Specjalista ds. Sprzedaży (transport drogowy) <=
- 2025-01-27 Warszawa => Java Developer <=
- 2025-01-27 Warszawa => Data Engineer (Tech Lead) <=
- 2025-01-27 Warszawa => Programista Full Stack (.Net Core) <=
- 2025-01-27 Kto ma PRAWNĄ rację? poseł KO mec. R. Giertych v. mec. B. Lewandowski
- 2025-01-27 Gliwice => IT Expert (Network Systems area) <=
- 2025-01-27 Koszyk okrągły, walec 3x AA, na duże paluszki R6
- 2025-01-27 Warszawa => QA Engineer <=
- 2025-01-27 Warszawa => Analityk Biznesowo-Systemowy <=
- 2025-01-27 Mińsk Mazowiecki => Area Sales Manager OZE <=
- 2025-01-27 Bieruń => Team Lead / Tribe Lead FrontEnd <=
- 2025-01-27 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2025-01-27 Kraków => User Experience Designer <=
- 2025-01-27 Kraków => iOS Developer (Swift experience) <=
- 2025-01-26 Trump-2 JUŻ bardzo łaskawy [1_500 ułaskawień skazanych za Bidena za "Kawkę na Kapitolu"]