Chcete umoznit na AP sve site roaming pro cizi uzivatele?
You do not have permission to vote on this poll.
Ne
18
26.47%
Ano, nemuzeme menit essid, bojime se o stabilitu/propustnost nasich AP
6
8.82%
Ano, nemuzeme menit essid.
5
7.35%
Ano, muzeme vytvorit virtualni AP s specifickym essid, ale bojime se o stabilitu/propustnost nasich AP
6
8.82%
Ano, muzeme vytvorit virtualni AP s specifickym essid bez problemu, nebo nasadime specialne AP jen pro tento roaming
17
25.00%
Ano, muzeme vytvorit virtualni AP s specifickym essid bez problemu a mame zajem o rozsireni projektu i na domaci AP clenu sve site, nebo nasadime specialne AP jen pro tento roaming
11
16.18%
Ano, kombinace ktera neni uvedena (napiste do fora)
Ja si myslim, ze jako vetsina jinych projektu ktere jsem delal (a spoustu jich podelal podcenenim slozitosti) by bylo vhodne udelat stupnovanou specifikaci - neco jak jsem psal - a zacit implementaci te nejjednodussi, budou se objevovat omezeni RADIUSu, ziskame zkusenosti, nejaci lide vykrystalizuji (1-2) kteri budou schopni si hrat s konfiguraci. Pak by po nejake dobe upresnovani specifikace bylo vhodne udelat draft RFC a zohlednit potreby jak cestujicich uzivatelu, tak siti. Co se tyce problemu s cerpanim prilis mnoho prostredku (uzivatel zacne pripojeni vyuzivat jako rezidencni) pak by bylo vhodne, aby na zaklade smlouvy mezi sdruzenimi (ted pomijim jesli 1:1 nebo 1:N) si sdruzeni vyuctovaly co ten clovek spotreboval. Muze jit o dobu 2 mesice kdy je na prazdninach a nekde chce fungovat, cilem je zjednodusit administrativu pri pripojeni k cizi siti (kolikrat ted ani nejde roamovat mezi ruznymi AP).
Uvedu priklad, na prazdiny vyrazim na Lipno a budu surfovat, nebo jachtit a v pristavu bude par AP a v jinem pristavu AP jineho sdruzeni, pak bych chtel abych se mohl nahodne pripojit tam, kde potrebuju zjistit predpoved pocasi, a pritom zaplatit hostujicic siti za pripojeni kdyz tam zkysnu mesic. V soucasne situaci s roztristenymi ISP/sdruzenimi bych musel zadat o clenstvi, pripojit se na konkretni AP a tam zustat s pevnou adresou (pripadne pridelenou DHCP - to lepsi reseni).
System pridelovani a odebirani prav ktery se tu diskutuje v ramci velkych sdruzeni je neco, co jde mimo nahodnych cestujicich kteri maji sve domovske sdruzeni, nezastavaji zadnou spravcovskou roli, ale chteli by, aby jim jejich sdruzeni umoznilo roamovat v cizich sitich. Ja si myslim ze to je dalsi "pridana hodnota" clenstvi ve sdruzeni. Od rezedencniho pripojeni wifi (coz je ceska specialita) bychom postupne mohli prechazet i na mobilni pripojeni. GSM operatori tohle maji, tusim ze CTU jim stanovuje peeringove a cenove podminky za pocty provolanych minut. V tomto prostredi s hodne GSM operatory je to nutne, protoze nechat jim to na vlastnim rozhodnuti tak se nedohodnou. My nejsme komercni operatori (vetsinou) tak to muzeme mit jednodussi. Ale nejaka zakladni kolektivni smlouva o zakladnim pristupu by mohla byt vhodna, pocet sdruzeni ktere budou chtit to nejjednodussi bude nejvetsi, s vzrustajici slozitosti bude pocet participujicich sdruzeni klesat, takze pro slozitejsi peering muze byt smlouva 1:1.
__________________
------------------------------------------
"WARNING: Do not look into laser with remaining eye"
Co se tyce jednotnosti essid, navrhoval jsem 2 nebo 3 varianty proto, ze budou vznikat problemy, sice by bylo krasne mit jednotne essid pro vsechno, ale v okamziku kdy ne vsichni budou mit moznost implementovat vsechy ficury vyvinuteho roamingoveho systemu si bude chtit uzivatel rozhodnout nepripojit se k nektere siti o ktere zjistit ze neumi to co on chce. Pouziti nekolika essid muze umoznit projekt rozjet po etapach, zvolit essid pro nejaky stupen a uzivatel pak bude ocekavat to co uvidi v essid. Opravdu si myslim stejne jako danny ze vybrat si essid ze seznamu scanu siti neni takovy problem, opruz by to byl kdyby bylo nutne pri kazdem prechodu na jine AP stejne organizace (tyka se skoro vyhradne pokryti v budovach, nebo parcich) znovu iniciovat spojeni.
S virtualnimi essid neni problem k jedne funkcnosti spojene s tim essid pridat dalsi, s dalsim a rozsirenou funkcnosti. Proto bych navrhoval rozvest tu debatu o formatu essid aby to umoznovalo projekt skalovat, a zaroven umoznilo uzivateli vybrat si AP ktere chce (ma nejlepsi pripojeni v pripade mizerne funkcnosti). Kolikrat se wifi rozhodne pripojit jinam nez kde je nejlepsi SNR.
Muze byt i neco jako czfroam jako jednotne essid, czfroam-nazevsdruzeni pro roamovani jen v ramci AP jednoho sdruzeni, czfroam-nazevsdruzeni-AP1_ulice pro moznost pripojeni jen ke konkretnimu AP.
Moje role tady v tomto projektu je vicemene v roli nezavisleho pozorovatele, sam zadnou sit nemam, ale par lidem obcas radim. To jsou moje navrhy z hlediska potreb uzivatele, zkuste to nejak rozsirit/upravit aby to sedelo i potrebam provozovatele. Vychazim z toho, ze i nekolik essid APcko nezatizi, jmeno site se broadcastuje 100x za vterinu, tak nevidim problem mit tam +3 essid navic. pouziti tedchto variant by bylo zcela dobrovolne, pak by se nikdo s nikym nehadal, jsem pro maximalni svobodu v nasazeni a tvorbe specifikace tak, aby tuto svobodu umoznovala.
__________________
------------------------------------------
"WARNING: Do not look into laser with remaining eye"
Však tahle debata to naplňje, ne?
Nebudu reagovat na jednotlivé části, protože u některých už ujíždíme jinam.
ad síť:
ano a jsme zase u toho, co jsem říkal na začátku - síť je pro členy, takže je potřeba ošetřit to, aby na tu síť mohl i někdo jiný, tj. tedy dohoda o spolupráci s jiným sdružením atd.
To se týká peeringu, roamingu, defacto naprosto všeho.
ad roaming:
nějak moc uvažujete o tom, že jsou ápéčka jedno vedle druhého, že se překrývají atd.
Jenže pokud odmyslíme Prahu a pár dalších větších aglomerací, tak máš pak ápéčka od sebe desítky či stovky kilometrů, takže veškeré snahy o úplnou jednotnost názvu jsou k ničemu, protože po cestě stejnak nebude signál ani od jednoho z nich. Takže ti to stejnak vypadne.
Viděl bych to spíš na udržování seznamu ssid, které jsou ve sdruženích vázaných smlouvou určena/vhodná právě pro tyto "návštěvníky". Holt kdo si to před cestou nezaktualizuje, tak si to bude muset zkoušet ručně.
Jak píšeš a jak jsem psal i já, těch "obyčejných" AP je mraky, takže se to nemůže vázat na jednotné ssid.
Čistě teoreticky, u nás by virtuální SSID možná umožnila max. dvě AP Orinoca, z toho na jedno nikoho nepustíme a to druhé na nádraží sice vidí, ale pochybuju, že by ses na něj připojil z vlaku notebookem ...
16.09.2009 v 21:54
