Integrace distribuované laboratoře počítačových sítí se simulátorem PacketTracer
Z VirtlabWiki
(Rozdíly mezi verzemi)
| Verze z 19:45, 26. 4. 2009 Gry72 (Diskuse | příspěvky) ← Předchozí porovnání |
Verze z 13:48, 27. 4. 2009 Kna054 (Diskuse | příspěvky) (→Nezodpovězené) Následující porovnání → |
||
| Řádka 4: | Řádka 4: | ||
| * Musí být PacketTracer Bridge stavový (kvůli spárovávání dotazů a odpovědí) ? | * Musí být PacketTracer Bridge stavový (kvůli spárovávání dotazů a odpovědí) ? | ||
| - | * Potřebujeme v předávaných datových strukturách reprezentujících simulovaný provoz i jméno obláčku, nebo stačí jméno prvku a jméno rozhraní ? | ||
| * Funkce PT bridge na WAN portech (generování/čtení rámců HDLC, PPP, FrameRelay, ...) | * Funkce PT bridge na WAN portech (generování/čtení rámců HDLC, PPP, FrameRelay, ...) | ||
Verze z 13:48, 27. 4. 2009
Obsah |
Otázky
Nezodpovězené
- Musí být PacketTracer Bridge stavový (kvůli spárovávání dotazů a odpovědí) ?
- Funkce PT bridge na WAN portech (generování/čtení rámců HDLC, PPP, FrameRelay, ...)
Zodpovězené
- Existuje nějaká možnost automatizovaného předání parametrů do PacketTraceru (parametry spojení na PT server, které se má navázat) ? Možná aspoň možnost specifikace parametrů při spouštění PT ?
- Zatím jsem takovou možnost neobjevil.
- Pokud chci mezi dvojicí PT klient - PT server vést více simulovaných spojení mezi různými prvky topologií simulovaných na serveru a na klientu, všechny budou sdílet jedno společné TCP spojení ? V předávaných datových strukturách reprezentujících simulovaný provoz je vždy určeno rozhraní prvku ze kterého rámec letí a do kterého letí ? V textové formě zahrnující vždy jméno obláčku, jméno prvku a jméno rozhraní ?
- Ano pokud bude více simulovaných spojení jdoucí přes jeden MU (Multiuser) obláček, tak vše chodí přes jedno reálné TCP spojení. To rozhraní je podle mě ve zprávách předáváno, ale nikoliv textově. Na začátku si poví jaké linky mají a jakým prvkům náleží. Pak už se nejspíše odkazují jen na číslo linky na kterou to má přijít. Půjde nejspíše o číslo. Toto ověřím ještě později, prohlédnutím hlavičkových souborů dostupného frameworku.
Základní filosofie návrhu
Ke zvážení
- Mělo by smysl udělat PTB běžící lokálně spolu s PT na vzdáleném stroji každého uživatele ?
- Reálný provoz by enkapsuloval do UDP a posílal přímo TS (buďto přímo na lokalitu, kam vede příslušný spoj, nebo na TS domovské lokality, který by dále forwardoval provoz do cizích lokalit)
- Distribuovala by se spotřeba výpočetního výkonu
- Portabilní implementace v Javě nebo zvláštní binárka pro Linux/Win
- K tomu asi i lokální proxy PTS (ten by se napojoval na PTS domovské lokality)
