Všechno možné

-------------------------------------------------- BEZDRÁTOVÉ SÍTĚ -----------------------------------------------------------------------------

-zbytečné natahování kabelů

-v místech kde se natahování nevyplatí (není možné)

-důležité zkoumat jak a zda prochází překážky (infračervené ne)

-možnosti připojování okruhů/paketů

-rozděluje se licenční a bezlicenční pásmo (placené = garantované, proti rušení)

-podle typu sítě předpoklad že uživatel je na jednom místě / hýbe se

-EDGE byla u nás spuštěna v předchozím roce

-GSM primárně pro přenos hlasu, EDGE je na ní postaveno > nevýhoda, navíc ho ted nepodporují všechny telefony




























--------------- DATABÁZE ----------------------------
-databáze jako služba počítačové sítě
-mechanismu přístupu k datům
-nejpoužívanější model klient-server
-jednoduché ukládání a získávání dat

-možnost vlastního zápisu z app. na disku, bez DB > rychlé, ale implementačně složité, nepoužívá sítě, jedině se sítovým soub. systémem (zamykání db)
-jinak app volá pod sebou db stroj (knihovní fce) , nevýhoda:

-klasický model klient-server: v souč. db systémech vždy, aplikace je klient
-nepužíváme sítěvý FS, ale sítěový protokol (tcp-ip) (ne v distrib. db, tam jsou jiné; ani ethernet není dobrý)

-z internetu mohu přistupovat k db odkudkoliv
-u firem:intranetový přístup, aplikační logika je v datovém centru a mám ho pod kontrolou, snadnější opravy chyb atd.
-tlustý klient když se připojí do db, tak je oproti tenkému vyžaduje složitější správu než u třírstvé archit.

-z pohledu db je klient aplikace i když neběží na stroji kde je uživatel


-transakční systém (db) je klíčová vlastnost:
-v relačních db sys. modelujeme data pomocí tabulek a řádků v tabulkách, není to objektový přístup, je na systému jak mi zobrazí data
-transakce: posloupnost operací (čtení,zápis,vložnení,úprava)
atomická: provede se celá nebo vůbec
konzistence: když přistoupí víc klientů, db se tváří že jako ji má každý pro sebe celou; oprace se prodlužují
izolovanost:
trvanlivost: např. když data zapíšu, řeknu že byla zapsána, pak dojde k pádu systému, po obnovení , db zajistí obnovení dat; respektive nesmět obnovit data když nebyla transakce provedena


-principy spojení klienta s DB
-app (.c) > interface pro přístup k db(.jar) > za ním je driver (.jar)(implementace pro konkr. db) > klient (typicky knihovna distribuovaná s databází, komunikuje s OS) (.o, .dll)
knihovnu volá ovladač po upozornění interface, převádí volání do protokolu, implementuje aplikační vrstvu spojení, většinou proprietární, spojí se s db serverem
na db serveru běži proces který poslouchá na nějakém tcp portu, s ním se navazuje spojení. po spojení nastartuje proces (server proces), který se pomocí nějaké sítové knihovny (.o, dll) spojuje a komunikuje s klientem (předch. spojení se zahodí
na rozdíl od http je tato komunikace stavová (session: jakou znakovou sadu tato app používá a další parametry)
server je proces který sdílí sdílenou pamět a přistupuje k db

>> přenos dat mezi databázemi (víceméně:-)


APLIKACE
OVLADAČ
>
PROCESY DB SERVERU A NAALOKOVANÁ PAMĚT -INSTANCE
>
DATABÁZE
- Nevýhoda je při přísupu klienta xerveru: nastartování serveru, uzavření spojení, generovat session, }velká režie
- na složitých webových systémech takové požadavky odstinujeme na app úrovni permanentně spojený s db serverem (typ. obj.přísutp) nebo jak nabízí oracle : množina tzv. sdílenych serverů co běží vždy

-bufferování: pracuje se v paměti, čas od času se to zapíše na disk



DISTRIBUOVANÉ DBS
-db clustery: když spadne nějaký proces spadne celý systém > vedle něj běží jiný systém přebírající požadavky při problémech
-sdílené procesy (viz výše): může se stát že stroj je zatížený a chci poskytovat služby, můžu zlepšit hardware nebo použit distr. db
-rozdělování db serverů: databáze a k ní dva nezávislé počítače :
buď napojení db na oba dva servery: share-nothing cluster; když běží prim. instance, neběží sekundární(přednastartovaná) (lezly by na stejný data: velká režie)
když primární spadne, provoz se přemostí na ni.
nebo polovina db je na jednom, jedna na druhém, ovšem má nedostaky (půlka spadne>mám jen půlku db; musí se rozhodnout která část je kde > app musí být rozdělitelná)
je to taky share-nothing
db nesdílím, pokud se mi podaří dát ji celou do paměti. mechanizmus promítá změny v pamětech v různých částech (pokusy v mysql)

nebo share-all (share disk) db: mám dva stroje připojené k disk. poli na kterém je db, oba můžou přistupovat ke všem datům, zajistím žeto obě instance budou dělat konzistentně
(když jedna db načte kus dat do paměti, druhá ví že se k ní nedostane), není to až tak rychlé proto se implementjí mechanizmy aby se kus dat přehodil po síti efektivněji než ethernet
(proud udp paketů) -Real aplication clusters (od Oracle ) (nebo taky grid, ale v širším prostředí)

tabulky lze dělit na části, logicky je to jedna, ale jinak je to několik nezáv. celků
















































SITOVA INSTALACE SYSTEMU
-ruční
-na jeden stroj, image se rozkopíruje na jiné (SysPrep, RIPrep,Unattedned, Kickstart, Jumpstart)
-autom. instalace: každá stanice nabootuje po síti (minimální systém) který je schopný obsloužit celý instalátor


AKTUALIZACE SYSTÉMU
-každý stroj sám:
pokud je každý jiný
kdy není snadné určit co se z toho systémového disku má všechno synchronizovat(např. když nemá strukturované konf.soubory)
nutná služba pro aktualizaci, vzdálená správa softwarových balíků

-systém synchronizovaný s image
image se ze serveru rozkopíruje na stroje
nemá nároky na stroje, stačí když mají službu která jim umožní zkopírovat systém k sobě
využití rsync (co všechno mám stáhnout)



AUTOMATICKÁ KONFIGURACE SÍTĚ

-Bootstrap protocol (bootp)
původně pro bezdiskové stanice
aby věděla odkud přes tftp stáhnout systém
podpora bývá součástí firmwaru
bootp request: chci adresu, odpověď je už adresa
obvykle server na udp 67, klient přijímá na portu 68

DHCP
-dynamic host configuration protocol
staví na bootp a je s ním zpětně kompatibilní
poskytuje klientovi konfiguraci sítě, jaké je její nastavení (router, ns, maska)
může dynamicky alokovat ip pro klienta z nějakého rozsahu, který je vymezen na určitý čas
právo rezervovat ip adresu a pak ji vrátit klientovi, co ji předtím vlastnil
-více typů zpráv
klient pošle po síti dhcp discover
dhcp server nabídne ip adresu (offer)
potvrdím že ji chci (request
server potvrdí že mu ji opravdu přiřadil (acknowledge)
při odpojení ze sítě klient posílá dhcp release

POKROČILÉ ZPŮSOBY
Zero conf (doména open source
poskytuje prostor ke komunikaci v internetu aniž by byl potřebný dhcp server
poskytuje bez name serveru překlad adres
zjištování dostupnosti služeb v síti (dns service discovery)
klient dostává multicastovou adresu
v systémech Mac OS X (vlastní specifikace Bonjour)



KERBEROS PRINCIPAL
identifikace služby, stroje, uživatele
















------------------------------------------------- HTML ------------------------------------------------------------------------------------

---- CSS ----------------------------
-objekt.třída {vlastnost:hodnota;}
-barva jako anglický ekvivalent, #hexadecimálně (každé dva znaky jsou R, G, B)
(color: backgound-color)

-align:left, right, centrer, justify
-font-style: normal, italic, oblique
-font-weight: lighter, normal, bold, bolder
-font-size: pt
-border: 1px solid #000000
-margin - volné místo kolem bloku: top, right, bottom, left
-width - pro div: px nebo %
-cursor: arrow, normal, hand


---- XML ----------------------------
Extensible Markup Language
(rozšiřitelný)

-SGML - všeob. značkovací jazyk, složitý na implementaci
-HTML neumožnuje strukturovatelnost informací
-možnost definování vlastních značek pro popis jednotlivých částí textu
-omezená množina značek
-zaměřuje se na obsah(striktně)
-formát pro výměnu dat
-možnost nadefinovat jaké elementy jsou v dokumentu přípustné (snadná validace), slouží k tomu DTD
-formáty pomocí CSS (práce skoro jako v html dokumentech, nejsou úplně podporovány IE,omezené možnosti)
XSLT (Extended stylesheet transformation, definovat jak bude obsah prezentován, text můžeme přetransformovat podle představ)
-první řádek hlavička: verze, kodování
-další jsou už xml dokument: vždy hlavní značka (povinný kořenový element), pod ním vložené další
-elementy mají atributy
-není benevolentní jako html: značka a

-DTD
-většinou v externím souboru


-elementy v DTD:



-dál ho neelementujeme
-definujeme i atributy pro ten který element ve stejném souboru:

-v uvozovkách defaultní hodnota CDATA je jako PCDATA u elementu

-XSLT umožnují definovat cokoliv týkající se vzhledu
na začátku hlavička
při definici vzhledu se používají tzv šablony aplikované na různé elementy


----- XHTML -----------------------------
-aplikace samotného xml
-jasně definovaná pravidla a standardy, veřejný DTD
(html se dále nevyvíjí)
-ukončovat všechny značky popř. ve zkrácené podobě nebo
-místo checkec se musí checked=checked
-v hlavičce definováno DTD jaké je použito





------------------------------------------------------ DYNAMICKÉ STRÁNKY ---------------------------------------------------------------
-na straně klienta nebo serveru


--- JAVASCRIPT ---------------------
-of firmy Netscape
-script dáváme do komentáře, ale js se interpretuje i v komentáři
-do hlavičky i do těla, párová značka
-nemůže pracovat s databázemi ani txt soubory (nemá přístup na disk)
-vhodný pro práci co by zatěžovala server (formuláře, okna - popup)



--- PHP -----------------------------
-kod vyhodnocen na straně serveru
-stránky se musí volat přes webový server
-umožňuje práci se soubory, databázemi, zpracovávání formulářů