Poslední příspěvky

1

Sítě / Re:Připojení ke SmartTV přes síť (ne bezdrátový displej)

« Poslední příspěvek od Ge Bu kdy Dnes v 20:14:26 »

Někde to takto máme, dokonce s uchycenou zásuvkou (neleží volně) např. v liště. Žel to také spolehlivé není. Notebooky mají zřejmě různé výkony signálu a každý spoj navíc se projeví. Zvlášť, když se tak často používá. Po určité době se ochodí female podle typu notebooku to postupně přestává fungovat.

Asi jsem staromodni, ale ja bych do TV pripojil HDMI prodluzku, kabel v liste privedl az nekam ke katedre ci u ceho sedi ucitel, tam do prodluzky zapojil klasicky male-male HDMI kabel a ten vyvedl v dostatecne delce na stul.

Konektor v televizi bude porad pripojeny, nic ho neohrozi a kdyz je ten male-male HDMI kabel ochodi, za par korun se vymeni.

Podstatne spolehlivejsi nez jakeholiv sitovani nebo dokonce wifi, nehlede na nulovou potrebu cokoliv instalovat na ucitelske pocitace.

2

Sítě / Re:Připojení ke SmartTV přes síť (ne bezdrátový displej)

« Poslední příspěvek od Tomáš Rollo kdy Dnes v 19:53:21 »

Asi jsem staromodni, ale ja bych do TV pripojil HDMI prodluzku, kabel v liste privedl az nekam ke katedre ci u ceho sedi ucitel, tam do prodluzky zapojil klasicky male-male HDMI kabel a ten vyvedl v dostatecne delce na stul.

Konektor v televizi bude porad pripojeny, nic ho neohrozi a kdyz je ten male-male HDMI kabel ochodi, za par korun se vymeni.

Podstatne spolehlivejsi nez jakeholiv sitovani nebo dokonce wifi, nehlede na nulovou potrebu cokoliv instalovat na ucitelske pocitace.

3

Sítě / Re:jaktože wlan extender má svůj dns záznam

« Poslední příspěvek od František Ryšánek kdy Dnes v 19:13:10 »

Ohledně DNS záhady:
1) výrobci těchto krabiček (extenderů) mají vcelku svobodu, co si kdo naprasí do firmwaru
2) možná se zkuste mrknout, co dělá Bonjour / ZeroConf / uPnP a hlavně mDNS. Něco z toho se Vás může týkat.
Hint: APčka tohle často umí.
Na straně klienta: v operačním systému je knihovna, která zkouší přeložit jména pomocí mDNS. Tahle knihovna či plugin se zavěsí do "systémového všeobecného jmenného resolveru" vedle standardního DNS, lokálních překladů z /etc/hosts apod. Ten client-side zastřešující resolver se v Linuxu tuším jmenuje libnss.

Ohledně wifi extenderu v tříadresním režimu díky za zajímavé téma. Dost hlavolam. Něco jako Mikrotik station pseudo-bridge s překladem MAC adres, akorát v režimu vzduch-vzduch. Nebo by extender musel sledovat, který klient je schopen odpovědět sám za sebe, a pokud od něj nevidí ack, tak forwardnout/zopakovat původní "dotaz" od AP, a pokud jemu už klient odpoví, tak forwardnout zpátky APčku se src rádiovou MAC adresou klienta... nebo tak nějak, divočina.

Čtyřadresní backhaul je oproti tomu relativně jasnej (jako po kabelu) - ale to zas musí podporovat taky hlavní APčko, na které se ten extender pověsí, ten čtyřadresní spoj by musel asi jet jiným ESSIDem, než který slouží tříadresním čistým klientům... není to jenom otázka "zapnu extender a jedu, a je jedno, jestli o mně AP ví že jsem extender".

Klíčová slova: WDS a 802.11s

4

Nová témata / Re:Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od RDa kdy Dnes v 18:50:37 »

Ta dvoji by sla takto:

Kód: [Vybrat]

# vconfig add lan 15
Added VLAN with VID == 15 to IF -:lan:-
# vconfig add lan 90
Added VLAN with VID == 90 to IF -:lan:-
# ifconfig lan mtu 9000
# ifconfig lan.15 mtu 1500
# ifconfig lan.90 mtu 9000
# ifconfig lan.15 up
# ifconfig lan.90 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
lan.15: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lan.90: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000


5

Sítě / Re:souběžný posílání souboru na všechny ethernetové porty multicastem

« Poslední příspěvek od František Ryšánek kdy Dnes v 18:49:15 »

Mně to taky připadá jako téma na hezké programování v C(++) a BSD sockets API.
Kladu si otázku: co řešíte za specifický problém?

Potřebujete distribuovat nějaké soubory, a těch dat je příliš mnoho, než aby to 1Gb linka na straně serveru zvládla přenést všem klientům, ale pokud se to bude multicastovat, tak se to vejde/stihne?
Klienti potřebují vždy všichni tentýž soubor ve stejném čase? Je v tom případě potřeba, aby si o něj sami říkali? Nemůže mít server informaci, který soubor budou klienti potřebovat, a prostě ho "odvysílá" o své vůli? Musí server čekat, až budou všichni klienti připraveni, a tedy čekat až všichni projeví zájem?

Našel jsem jednu aplikaci, kde něco velmi podobného funguje. Cílový business model je "digital signage" = zobrazování reklamy na obrazovkách v síti, kde u každé obrazovky je malý lokální počítač s vlastní úložnou kapacitou. A říkají k tomu, že se jedná o "push delivery" souborů na klientské stroje (přehrávače).

Pokud by měl server dělat retransmise, pokud byť jediný klient signalizuje, že data nedostal, může se snadno smazat úspora, která z multicastingu plyne. Pokud se počet retransmisí neomezí, může to dopadnout volně v intencích toho co lze vidět na CANbusu při nějaké poruše fyzické vrstvy: jeden uzel stále dokola vysílá tutéž zprávu, ale všechny ostatní datové toky se zastaví :-) Princip toho jevu je podstatně odlišný, ale to deja-vu je silné :-)

Když mluvíte o multicastingu, plánujete "přihlašování k odběru" pomocí IGMP ? (Pokude ne, bavíme se efektivně o broadcastingu...)

Vypadá to na zábavné téma k analýze, ale chtělo by to trochu víc vstupních informací, aby stálo za to nad tím dumat :-)

6

Nová témata / Re:Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od RDa kdy Dnes v 18:48:34 »

nastaveni MTU 9000 na eth0 projde?

Ano, projde to timto stylem i separatne:

Kód: [Vybrat]

# vconfig add lan 123
# ifconfig lan mtu 9000
# ifconfig lan.123 mtu 1500
# ifconfig lan.123 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
lan.123: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Ale na kyzeny opacny stav (vlan s vyssi MTU) ne:

Kód: [Vybrat]

# vconfig add lan 123
# ifconfig lan mtu 9000
# ifconfig lan.123 mtu 9000
# ifconfig lan mtu 1500
# ifconfig lan.123 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lan.123: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Ta VLAN ma omezeny MTU na hodnotu ktera je aplikovana na nativni rozhrani.

Mozna tedy je sance, ze by zarizeni v dvoji siti meli pouze tagovane vlany, tj. obe dve nad fyzickym rozhranim, ktere by se pak uz dale nepouzivalo - a pak by tohle vyzadovalo bud manazovany switch nebo router s nastavenim te 1500 vlany jako dalsiho lan segmentu + nutnost mezi tim routovat. Pochybuji ze by byl dobry napad spojovat do bridge sit, ktera je fyzicke rozhrani a jedna tagovana vlan z nej, na tom routru.

Pridavam dalsi pozadavky/predstavy:
 - v 1500 siti se musi dorozumet vsichni se vsema a maj pristup na internet, jede tam dhcp
 - v 9000 siti neni pristup ven na internet, jen mezi specifickyma zarizenimi (a muzou mit staticke ip)

7

Nová témata / Re:Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od czipis kdy Dnes v 18:33:51 »

nastaveni MTU 9000 na eth0 projde?

8

Sítě / Re:souběžný posílání souboru na všechny ethernetové porty multicastem

« Poslední příspěvek od RDa kdy Dnes v 18:21:33 »

Tak si neco takoveho napis, ze to bude distribuovat obsah v plovoucim okne a dokud vsichni prijemci nepotvrdi dokad ten obsah maji, tak se okno nebude posouvat a bude to delat retransmise.

Alternativne muzes pouzit namisto multicastu daisy-chain, ze kazdy klient vyjma posledniho bude jakoby proxy. To by slo zhackovat snad velice rychle skrze nejaky http proxy s lokalni cache... na 1..N-1 nastavis proxy, a na N-tem udelas wget

Rychlostne by to melo mit stejne parametry jako multicast, jen to bude mit vyssi spotrebu (protoze kazdy port ve switchi naplno vyuzije oba smery, vyjma prvniho a posledniho).

9

Nová témata / Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od RDa kdy Dnes v 17:51:42 »

Snažím se (zatím v linuxu) nastavit sdílenou síťovku skrze VLAN do dvou sítí na různé MTU a nejde to.

Představa cílového stavu je:
eth0 s MTU 1500, subnet hlavni
eth0.10 s MTU 9000, subnet jiny

Při nastavení MTU pro rozhraní s VLAN (eth0.10) se vrací s jakoukoliv hodnotou:

Kód: [Vybrat]

SIOCSIFMTU: Numerical result out of range
Při nastavení MTU pro netagovanou síť (eth0) se tato hodnota projevuje o obou rozhraní (eth0, eth0.10)

Existuje nějaké řešení ?

Lze omezit na linuxu a macu MTU na vrstvě IP podsítě ?

Situace je: klasická domácí síť s hromadou různorodých zařízení má několik zařízení, mezi kterými chci provozovat ty jumbo frames (řekněme několik pracovních stanice a NAS), bez toho, abych musel tahat duplicitní kabeláž. Představa byla nasadit tagovanou VLAN, kde může tento jumbo provoz probíhat. A ejhle.. nejde to. WTF.

10

Sítě / souběžný posílání souboru na všechny ethernetové porty multicastem

« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy Dnes v 17:41:26 »

Tuhle otázku si asi nějací lidí kladli,  tak bych se divil, kdyby neexistovalo řešení. Možná tak funguje bittorenent, nebo windows update cache v lokální síti.

Mám do switche (1Gbps x5) připojeno 1 zařízení, ze kterého chci z zařízení UNO rychlostí 1Gbps přemístit soubor do zbylých čtyřech zařízení, a každé bude příjmat souběžně čtyřykrát 1Gbps.    .. problém co :
(luxus jako 10Gbit switch  by sice šlo, ale je to řešení na sílu a to jsem neprozradil, že zdrojový seeder má taky 1Gbps)

Dá se tohle nějak zařídit.? Asi bude nevyhnutelný linkový/síťový multicast a speciální konfigurace stacku zdrojového zařízení a asi to bude diktovat volbu vhodného transportního démona+ protokolu (samba, rsync, ftp, torrent ,, webdav ,wtf) A aso

A ideálně, aby na cílových počítačích mohl být libovolný OS, ale pochopitelně s tím speciálním klientem.

přestavuju si to tak, že na cílových počítačích dám: něco jako  : superftp > connect 239.239.239.250 :21 ; get  file.zip
jakmile to dopišu na prvním druhém třetím , klienti začnou čekat. Až to napíšu na posledním čtvrtém, tak na serveru dám  příkaz start a ono to začne posílat

Jde to nějak? (nevidím problém v směru od serveru k klientům (hromadně), ale jak klienti budou handlovat (zvlášť) ack, pokud bych uvažoval TCP, je to vůbec možné, takovýhle TCP kočkopes) nebo se bude muset spolehnout na bezACKový protokol? čili jak řešit zpětnou komunikaci a obejde se to bez ní?