Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoszak|RendszerIntVizsgaKerdesek2008}} A hivatkozott anyagok lelőhelye: http://www.iit.bme.hu/~szebi/rinteg.html ==X400 - funkcionális és arch…”

2012-10-22T09:43:00Z

Új oldal, tartalma: „{{GlobalTemplate|Infoszak|RendszerIntVizsgaKerdesek2008}} A hivatkozott anyagok lelőhelye: http://www.iit.bme.hu/~szebi/rinteg.html ==X400 - funkcionális és arch…”

Új lap

{{GlobalTemplate|Infoszak|RendszerIntVizsgaKerdesek2008}}

A hivatkozott anyagok lelőhelye: http://www.iit.bme.hu/~szebi/rinteg.html

==X400 - funkcionális és architekturális modell. Naming és addressing. ASN.1 szerep és jelentõsége. ==
* x400.ppt
* Message Transfer System: Message Transfer Agents
* Message Handling System: User Agents + MTS; Message Store, Access Unit
* DirectoryService
* Abstract Syntax Notation: precise, formal notation that describes data structures for representing, encoding, transmitting, and decoding data

==X400 - IPM és EDI. Felhasználási területek. X400/IPM és SMTP összehasonlítása. ==
* x400.ppt
* InterPersonal Messaging: between User Agents
* Electronic Data Interchange: computer-computer communication over Value Added Network
* Simple Mail Transfer Protocol: multiple clients, one server, textual (HELO/MAIL FROM/RCPT TO/DATA/QUIT)

==MIME - kialakítása. Típusok és kódolások. MIME és X400 kódolás összehasonlítása. Ékezet az email "Tárgy" mezõben. ==
* mime.ppt

==CGI - HTTP protokoll elemek. A cgi-scriptek mûködése. Scriptek felépítése. Lehetséges-e állapotprogramozás? ==
* cgiservlet.ppt

==servlet - lényege, életciklusa, kialakítása. doXXX metódusok és szerepük. ==
* cgiservlet.ppt

==servlet - MVC tervezési minta. JSP lényege. Formai kialakítása. Taglib. Mi a JSTL? ==
* cgiservlet.ppt

==servlet - Beanek. Bean használata, kialakítása. Beanek hatósugara. A "session" változó. Állapotprogramozás. ==
* cgiservlet.ppt

==Servlet-framework lényege, használati módjaik. Ismertebb framework-ök. ==
* spring_introduction.pdf
* You can create a servlet framework by assigning responsibilities to various system components
* reflection
* Spring

==CSS - alapelvek. Szabályok szerkesztése. Öröklõdés. Kaszkádolás. DIV és SPAN szerepe. CSS szerepe az XML-ben. ==
* css.ppt

==XML - szintaxis. Hogyan alakult ki az XML, melyek a legfontosabb jellemzõi? Elemek és jellemzõk. DTD szerepe, kialakítása. Bonyolultabb szerkezetek a DTD-ben. DOM és SAX. ==
* xml1.ppt

==Hogyan lehet az XML-t alkalmazni rendszerek közötti átvitelre (XML-API)? Milyen az XML belsõ szerkezete? Mi az XPath és hogyan használható? ==
* xml1.ppt, soap.ppt

==XSL - szerepe, formai kialakítása. Mire jó az XSL? Milyen egy XSL belsõ szerkezete? A feldolgozás alapötlete. Fõ nyelvi elemek. XSLT. ==
* xml2.ppt

==XML security. Hogyan lehet aláírni? Hogyan és mit lehet titkosítani? Miért kell kanonizálni? ==
* xml3.ppt

==Adatbázis - JDBC és kialakítása. Hogyan tud kapcsolódni egy alkalmazásszerver az adatbázisokhoz? Hogyan kell servlet/MVC esetében használni a JDBC-t? ==
* adatbazis.ppt

==Alkalmazásszerver - lényege, konténerek. Melyek az alkalmazásszerver feladatai? Konténerek bekapcsolása. J2EE tanúsítvány jelentõsége. ==
* alkszerver.ppt

==TCP/IP - routing. Alapelvek, routing fajták, routing protokollok ==
* útválasztás
* IP-cím alapján állapítja meg, hogy melyik LAN-ba kell küldeni a csomagot
* de hogyan válassza meg az utat, ha több létezik?
* routing table oszlopai: N, IF, metric
* a router mint fizikai eszköz tartalmazhat gateway funkciót
* sebesség: packets per second
* routing table alapján, hogyan töltsük ki?
** statikus routing: kézzel töltjük ki
** dinamikus routing: egy algoritmus tartja karban
* protokollokat (EGP, IGP, BGP, RIP) átnézni

==TCP/IP - a Domain Name System. Felépítés, mûködés. Magasszintû protokollok: ftp, telnet, smtp ==
* domain név -> IP leképezés: kezdetben /etc/hosts
* Jonathan Postel ötlete
* fordított fastruktúra
* elosztott adatbázis
* resolver algoritmus: fastruktúrán föl megfelelő szintig, majd le
* NS-ek UDP-t használnak
* NS-ek resource rekordjainak típusai:
** Address (gépnév – IP-cím)
** NameServer (zónanév – IP-cím)
** MailXchange (kukac utáni zónanév – lekezelő gépnév)
** CNAME (gépnév – gépnév alias)
** TXT (megjegyzés)
** LOCation (gép földrajzi koordinátája)

==TCP/IP - Az IPv6 protokoll. Fejléc, címzés, IPv6-IPv4 különbségek ==
* network layer for packet-switched internetworks, the successor of Ipv4
* conservative extension: Most transport- and application-layer protocols need little or no change, but applications protocols need much larger address space: addresses in IPv6 are 128 bits long versus 32 bits in Ipv4; makes subnetting easier
* Stateless address autoconfiguration using ICMPv6 router discovery messages
* IPv6 addresses are typically composed of two logical parts: a 64-bit (sub-)network prefix, and a 64-bit host part
* IPv6 addresses are divided into 3 types:
** Unicast Addresses
** Multicast Addresses
** Anycast Addresses
* The IPv6 packet is composed of two main parts: the header and the payload.
* The header is in the first 40 octets (320 bits) of the packet and contains:
** Version - version 6 (4-bit IP version).
** Traffic class - packet priority (8-bits). Priority values are divided into ranges: traffic where the source provides congestion control and non-congestion control traffic.
** Flow label - QoS management (20 bits). Originally created for giving real-time applications special service, but currently unused.
** Payload length - payload length in bytes (16 bits). When cleared to zero, the option is a "Jumbo payload" (hop-by-hop).
** Next header - Specifies the next encapsulated protocol. The values are compatible with those specified for the IPv4 protocol field (8 bits).
** Hop limit - replaces the time to live field of IPv4 (8 bits).
** Source and destination addresses - 128 bits each.

==Hálózat biztonság. A Kerberos rendszer mûködése. Alapfogalmak, üzenetek. ==
A kerberos hitelesítő protokoll segítségével egy nem biztonsgáos hálózat felett biztonságosan meggyőződhetnek a felek egymás identitásáról. Az MIT -n dolgozták ki. A Kerberos a Needham-Schroeder protokollt használja. Egy megbízható harmadik felet, un. KDC -t, Key Distribution Centert használ. A KDC logikailag két részre bomlik, AS (Authentication Server), illetve TGS (Ticket Granting Server). A Kerberos tikettekkel dolgozik. A KDC a kulcsokról egy adatbázist tart nyilván, minden a hálózaton résztvető elem, akár szerver, akár kliens birtokol egy titkos kulcsot, melyet rajta kívül csak a KDC ismer. Hogy két fél kommunikáljon, a KDC egy un. session kulcsot készít, melynek segítségével a felek kommunikálni tudnak biztonságosan. A Protokoll biztonsága nagyban függ a résztvevő felek szinkronizált óráitól, és a rövid idejű, hitelességet feltételező kerberos tikettektől.
A komponensek:
* AS = Authentication Server
* TGS = Ticket Granting Server
* SS = Service Server
* TGT = Ticket Granting Ticket
A protokoll rövid leírása:
* A kliens hitelesíti magát az Authentication Server felé egy hosszúéletű közös titok segítségével.
* A kliens az AS -től egy tikettet kap
* Később a kliens a kapott tikettel újabb tiketteket kaphat az SS -hez, anélkül, hogy a közös titkot használná.
* A kért tikettek hitelesítik az SS számára a klienst.
A protokoll részletes leírása:
* Felhasználó belép a kliens gépre:
** '''Béla''' beüti a jelszavát
** '''BélaKliens''' egyirányú hesselést csinál a bepüfölt jelszavon, ez lesz a kliens titkos kulcsa.
* Kliens hitelesítési lépések:
** A kliens egy cleartext szöveget küld az AS -nek, hogy a user nevében szolgáltatásokat kérjen. Ebben az üzenetben semmiféle titkos kulcs, ill jelszó nem kerül elküldésre. Egy ilyen minta üzenet: Béla szeretne majd szolgáltatásokat kérni. (Tehát itt még nem tudja, mit, valamit)
** Az '''AS''' leellenőrzi, Béla benne van e az adatbázisában, ha igen, akkor visszanyomja a kliensnek a következő információkat:
*** _MESSAGE A_: '''BélaKliens/TGS session kulcs''', a közös titokkal bekódolva.
*** _MESSAGE B_: '''Ticket Granting Ticket''' (benne van a kliens azonosító, kliens címe, tikett érvényességi periódusa, és a *BélaKliens/TGS session kulcs*), ez az üzenet a TGS kulcsával van bekódolva.
** A kliens megkapja a fennti üzeneteket, a ''MESSAGE A'' -t dekódolja, hiszen az a közös titokkal van bekódolva, ebből kinyeri a '''BélaKliens/TGS session kulcs''' -ot. Ezen kulcs segítségével fog a továbbiakban a '''TGS''' -el kommunikálni. (Megjegyzés: A ''MESSAGE B'' -t nem tudja Béla gépe kikódolni, mert az a '''TGS''' kulcsával van bekódolva.
* Kliens Szolgáltatáshitelesítési lépései:
** Amikor szolgáltatásra van szükség, a kliens a következő üzeneteket küldi el a '''TGS''' -nek:
*** _MESSAGE C_: ez az üzenet a ''MESSAGE B'' -ből, és a szolgáltatás ID -jából áll.
*** _MESSAGE D_: Hitelesítő infó (Kliens ID, és időbélyeg), bekódolva a '''BélaKliens/TGS session kulcs''' csal.
** Na, ezt megkapja a TGS, a ''MESSAGE C'' -ből kiszedi a ''MESSAGE B'' -t, és a ''MESSAGE B'' -t kikódolja a saját kulcsával. A kikódolásból megkapja a '''BélaKliens/TGS session kulcs''' -ot. Na, ezzel már dekódolja a ''MESSAGE D'' -t, és elküldi a következőket:
*** _MESSAGE E_: '''BélaKliens-Nyomtatószerver tikett''' (Kliens ID, kliens hálózati cím, érvényesség, *BélaKliens-Nyomtatószerver kulcs*), mindez bekódolva a szerver (nyomtatószerver) titkos kulcsával.
*** _MESSAGE F_: '''BélaKliens-Nyomtatószerver tikett''' bekódolva a '''BélaKliens/TGS szerver kulccsal'''
* Kliens szolgáltatást kér:
** Na, Béla gépének már megvan a ''MESSAGE E'', és a ''MESSAGE F'', ez már elég, hogy bebizonyítsa magát az '''SS''' felé, és nyomtasson végre. Hozzácsatlakozik a szerverhez, és elküldi a következőket:
*** az előző aktusból származó ''MESSAGE E''
*** _MESSAGE G_: egy új Hitelesítő infó (Kliens ID, időbillog) bekódolva '''BélaKliens/Nyomtatószerver session kulcs''' al.
** Az '''SS''' az első üzenetet dekódolja (_MESSAGE E_), ellenőrzi, jó e a timestamp. Ha minden rendben, akkor visszaküldi, hogy mennyire szeretne nyomtatni a Bélának:
*** _MESSAGE H_: A ''MESSAGE G'' -ben talált hitelesítő infó + 1, bekódolva a '''BélaKliens/Nyomtatószerver session kulcs''' al.
** Na, Béla Kliense kicsomagolja az üzenetet, és ellenőrzi, vajon tényleg jól hozzáadott e 1 -et a nyomtatószerver az időbélyeghez. Ha igen, akkor lehet nyomtatni.
** Béla nyomtat

* Kerberos builds on symmetric key cryptography and requires a trusted third party.
* Needham-Schroeder protocol
* key distribution center (KDC): two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server (TGS)
* protocol:
** C: key = hash(password)
** C->AS: authentication request
** AS->C: TGS session key encrypted with key, ticket-granting ticket encrypted with key of TGS
** C: decrypt(TGS session key)
** C->TGS: TGT+service ID, client ID+timestamp encrypted with TGS session key
** TGS->C: client-to-server ticket encrypted with service key, server session key encrypted with TGS session key
** C->SS: client-to-server ticket encrypted with service key, client ID+timestamp encrypted with server session key
** SS->C: timestamp+1 encrypted with server session key
** C: decrypt and check timestamp+1

==Web technológiák: web architektúra. A HTTP1.0 és HTTP1.1 protokollok. ==
* webtechnology.ppt

==Web technológiák: a Secure Socket Layer (SSL) mûködése. ==
* Application layer
* prevent eavesdropping, tampering, and message forgery
* server-only or mutual authentication
* basic phases:
** 1.Peer negotiation for algorithm support
** 2.Key exchange and authentication
** 3.Symmetric cipher encryption and message authentication
* typical algorithms:
** For key exchange
** For authentication
** Symmetric ciphers
** For cryptographic hash function
* handshake

==Melyek a SOAP fõ jellemzõi? Mi a webservice, hol és hogyan lehet alkalmazni? ==
* soap.ppt

==Mutassa be az "Inversion of Control" konténereket általában. Milyen tervezési mintákat használhatunk a komponensek létrehozásakor? Spring keretrendszer esetén hogyan írjuk le a komponenseket és hogyan hivatkozunk rájuk? ==
* spring_introduction.pdf
* IoC: the desired responses are registered to particular events ("don't call us, we will call you")

==Vázolja a komponens alapú tervezés elõnyeit. Milyen problémák jelentkeznek a komponensek összekapcsolásakor. A Spring keretrendszer hogyan oldja meg ezeket? Milyen lehetõségek vannak a függõségek és paraméterek beállítására? ==
* decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components
* a higher level of abstraction than objects and as such they do not share state and communicate by exchanging messages
* Multiple-use
* Non-context-specific
* Composable with other components
* Encapsulated i.e., non-investigable through its interfaces
* A unit of independent deployment and versioning

==Milyen problémákat old meg az object-relational mapping (ORM)? Milyen jellemzõkkel bírnak az adatbázisban tárolt entitások? Milyen objektumokat használhatunk JPA esetén és milyen módon írjuk le a tárolás módját? Mire jók az annotációk általában, hogyan definiálhatjuk azokat? ==
* object_relational_mappin.pdf
* Java Persistence API

==Ismertesse az entitások tárolási módjának megadását JPA esetén. Hogyan adjuk meg az elsõdleges kulcsot és a mezõk jellemzõit? Milyen reláció típusok vannak és hogyan adjuk meg azokat, hogyan képzõdnek le ezek Java nyelvi elemekre? ==
* EJB3_advanced_concepts.pdf
* A persistence entity is a lightweight Java class that typically represents a table in a relational database.

==Vázolja a többrétegû architektúrát és elemeit. Melyek a tranzakciók jellemzõi? Mit jelent deklaratív tranzakció kezelés?==
* EJB3_advanced_concepts.pdf
* a frequent client-server architecture
* Presentation Tier
* Application Tier (Business Logic/Logic Tier)
* Data Tier

==Vázolja az entitások életciklusát! Milyen metódusok állnak rendelkezésre az életciklus kezelésére? Hogyan lehet lekérdezéseket leírni JPA esetén? ==
* EJB3_advanced_concepts.pdf
* Relations between objects can be traversed using Java-like syntax
* the from clause of a query includes not only instances of the specific entity class to which it refers, but all subclasses of that class as well parameterized queries

==Intelligens háttértár rendszerek. A SAN fogalma, mûködése, elõnyei. ==
Kis történeti áttekintés:
Kezdetben volt a DAS (Direct attached storage). Ez gyakorlatilag egy szerver, telepakolva mindenféle winchesterrel, RAID vezérlővel. Az alkalmazások közvetlenül a winchestert címzik SCSI buszon, vagy SAS-on, vagy IDE-n. Hátránya, hogy amennyiben növekszik a cég háttértár igénye, újabb tárolókapacitást kell beletenni a szerverbe. Ennek korlátot szab a szerverben lévő helyek száma. Új tárhelyhez új szerver kell. Egy idő után jó sok szerver lesz, mindet külön karban kell tartani, megnőnek az üzemeltetési költségek. Ugyancsak hátrány, hogy a szerver más feladatokat is ellát, így a rendszer szűk keresztmettszetévé válik. Egy nagy sávszélesség igényű alkalmazás lelassítja a fájl elérést a szerveren keresztül. Ha egy alkalmazás karbantartása miatt újraindítás kell, a fájlszolgáltatás is megszűnik.

A NAS (Network Attached Storage) jön képbe ezután. A lényege, hogy van egy dedikált eszköz, vagy szerver, mely fájl szintű adathozzáférést biztosít. Lehet kapni dobozos eszközöket, vagy bárki építhet egy NAS -t egy Linux boxból, és egy NFS /CIFS szerverből. Itt a háttértárat ugyanúgy a rendszer hálózaton keresztül lehet elérni (IP). Gyakorlatilag annyi a különbség a DAS -hoz képest, hogy itt a szervert kizárólagosan fájlmegosztásra használjuk.

A SAN (Storage Area Network) egy dedikált, gyors hálózat, blokk szintű tármegosztással. A SAN infrastruktúrában a háttértárak legtöbbször Fibre Channel technológiával vannak összekötve. A Fibre Channel az SCSI minden előnyét élvezi, mindamellett, tekintve hogy nem egy párhuzamos busz, nagy távolságokban is használható. A SAN ereje a nagy blokkok mozgatásában rejlik. Hátránya a drágaság, a Fibre Channel eszközök nagyon költségesek, és elterjedését hátráltatta a szabvány lassú kifejlődése.

Intelligencia:
A SAN eszközökkel kapcsolatos fogalom a Storage Virtualization. Ennek segítségével a logikai tárolás elválasztható a konkrét fizikai tárolástól. A fizikai eszközökből egy pool látszik, mely pool -on lehet definiálni logikai meghajtót.
Egy cikket találtam [http://www.techworld.com/storage/features/index.cfm?featureid=127 Data Storage Interviews August 20, 03 The route to the intelligent SAN], melyben a SAN -ok intelligenciája alatt a következőket értették: A SAN routerekbe beépíthető, felprogramozható, adaptálódó funkciók. Gyakorlatilag egy nagyobb SAN hálózatban a felhasználás helyéhez közelebb mozgatja az adatot a SAN hálózat, ezáltal nagyobb sebességet elérve. A SAN intelligencia a hálózatba van beépítve. Programozható intelligens switchek, központi vezérlő motorral. A switchet pl. felprogramozzák, pl. hogy tükrözzön minden adatot egy másik eszközre. Ezzel a feature -el nem kell minden adatmozgatásnak keresztül mennie a szerveren.

SAN előnyök:
* Nagyon gyors, blokk szintű tárhely megosztás
* Nagy távolságok is áthidalhatóak vele
* Redundáns rendszer, 24x7 -es rendelkezésreállás
* Bővíthető rendszer

SAN hátrányok:
* Drága
* Gyártónként egyedi management felület

Régi cuccos:
* Storage Area Network
* an architecture to attach remote computer storage devices to servers in such a way that the devices appear as locally attached
* needs SAN file systems
* topology: switched fabric
* simplifies storage administration
* the ability to allow servers to boot from the SAN itself
* more effective disaster recovery processes (storage replication)

==A Fibre Channel (FC) technológia. Jellemzõk, topológiák, protokoll. ==
Kis történeti betekintés:
Nő a számítógépek sebessége, és a hagyományos párhuzamos SCSI technológia hátrányai kidomborodnak. Nagy átvitel kell a nagy sebességű processzoroknak. A merevlemezek megfelelnek a kihívásoknak, de az interfészük már nem. A probléma megoldására az új driveok FC interfésszel rendelkeznek, mely 100 Megabájt per szek sebességű, és növelés tervezett. A technológia nyújtja a teljesítménybeli megoldást, és a jövőbeli igényeknek is jobban megfelel. Azáltal, hogy a SCSI parancsokat becsomagolják az FC fizikai interfészbe, a migráció könnyedebbé válik.

Az FC eszközök kapcsolatát két kábel adja, egyik a bemenő, a másik a kimenő adat.

A Fibre Channel technológia egy nagysebességű hálózati technológia. A SAN -ok kialakítására használatos. Fizikai rétege lehet kettős axiális kábel, vagy üvegszál. a Fibre Channel Protokoll FCP egy átviteli protokoll, mely nagyrészt SCSI parancsokat szállít a FC hálózaton.
* Topológiák:
** Point-to-Point: két eszköz összekötve, a legyegyszerűbb topológia
** Arbitrated loop: Az eszközök egy gyűrűt alkotnak. Áj eszköz hozzáadásakor, vagy kivételekor a teljes hálózat megbénul. Egy eszköz megsérülésekor szintén megbénul a hálózat. FC hubokkal összekötve az eszközöket a hibás portok kikerülhetőek.
** Switched fabric (FC-SW): Fibre Channel switch -ekkel összekötött eszközök, vagy loop -ok, a switchek biztosítják az optimális összeköttetést.
* protocol stack:
** FC0 The physical layer, which includes cables, fiber optics, connectors, pinouts etc.
** FC1 The data link layer, which implements the 8b/10b encoding and decoding of signals.
** FC2 The network layer, defined by the FC-PI-2 standard, consists of the core of Fibre Channel, and defines the main protocols.
** FC3 The common services layer, a thin layer that could eventually implement functions like encryption or RAID.
** FC4 The Protocol Mapping layer. Layer in which other protocols, such as SCSI, are encapsulated into an information unit for delivery to FC2.

==Belsõ hálózatok védelme: fizikai, algoritmikus, adminisztratív védelem, biztonsági politika. ==
* Threats: email, IM, physical, FTP, VPN, new hires

==Tûzfalak alapvetõ típusai, csomagszûrõ és proxy tûzfal. ==
* a device or set of devices configured to permit, deny, encrypt, or proxy all computer traffic between different security domains
* packet filter: at network layer
* stateful p. f.: against exploiting existing conneciton, DoS attacks
* application layer
* A proxy device may act as a firewall by responding to input packets in the manner of an application, whilst blocking other packets.
* NAT (network address translation)

==POSIX célkitûzése. POSIX.1 alapjául szolgáló rendszerek. Szabvány által megfogalmazott követelmények szintjei. A szabványosság szintjei. ==
===POSIX célkitűzése:===
80 -as évek végére thető. Cél: létrehozni egy egységes operációs rendszer programozási felületet. Azért szükséges, mert így az alkalmazások hordozhatóak lesznek. Ekkor már kiforrottak voltak a különféle UNIX rendszerek. POSIX (Portable Operating System Interface).
===POSIX.1 alapjául szolgáló rendszerek:===
A POSIX.1 a rendszerinterfész C nyelven. Alapjául szolgálnak:
* System V
* BSD
A POSIX.1 nem szabja meg, mely függvények legyenek rendszerhívások, és melyek nem.
===A szabvány által megfogalmazott követelmények szintjei:===
A szabvány követelményeket támaszt egyrészt az Operációs rendszerrel szemben, másrészt az alkalmazásokkal szemben. A támasztott követelményeket a következőképpen lehet osztályozni:
* _Implementáció által definiált_: A szabvány nem köti meg, miként működjön, vagy mennyi legyen az értéke, de megköveteli, hogy le kell dokumentálni a pontos értéket. Pl.: filenév minimum 15 karakter legyen, ezt köti meg a szabvány. Hogy a konkrét operációs rendszeren van e felső limitje a fájlnév hossznak, és mennyi az, azt le kell dokumentálni.
* _Nem specifikált_: Az adott működést, vagy értéket nem specifikálja a szabvány. Pl.: Ha egyszerre érkeznek a signal -ok, akkor mi legyen a viselkedés.
* _Nem definiált_: Olyan működés, vagy funkció, mellyel szemben hibátlan program nem támaszthat követelményt.
* _Kell_: Pontosan előírja a szabvány, miként kell működjön az adott funkció, mennyi legyen a változó értéke.
* _Kellene_: Javaslatot ír elő, hogyan működjön, vagy mennyi legyen az értéke, de az implementáció eltérhet ettől.
* _Lehet_: Egy opciót jelöl, amit nem kötelező megvalósítani.

===A szabványosság szintjei:===
Ez szabja meg, egy alkalmazás mennyire szabványos. Itt négy szintet határoz meg:
* _Szigorúan megfelelő_: Olyan alkalmazás, amely csak POSIX szabványra épül, és hibátlanul működik a ''Nem specifikált'', és ''Implementáció által definiált'' követelmények összes értékével.
* _ISO/IEC megfelelő_: A POSIX mellett felhasznál még nemzetközi szabványokat is. (ISO/IEC)
* _Nemzeti szabványokat is felhasználó_: Az alkalmazás nemzeti szabványokat is felhasznál
* _Egyéb, nem szabványos kiterjesztéseket használó alkalmazás_: Olyan POSIX alkalmazás, mely felhasznál nem szabványos kiterjesztéseket is.

==POSIX.1 fontosabb témakörei, megvalósítás filozófiája. Rendszerfüggés problémái, a megoldás módszerei. ==
===A POSIX.1 fontosabb témakörei:===
* Processz kezelés
* Állománykezelés
* Szignálkezelés
* Terminálkezelés

===Processz kezelés===
A POSIX környezetben a processzek konkurensen futnak, processzt létrehozni a '''fork()''' rendszerhívással lehet. A processzkezelésnél alapvetően a System V rendszerekben alkalmazott megoldások köszönnek vissza.
A BSD rendszerekből átvett fogalmak: kiegészítő csoportazonosítók, szignál maszk.
====Kiegészítő csoportazonosítók====
Minden processz tagja egy szekciónak, és egy processzcsoportnak is. Egy szekcióhoz több processzcsoport is tartozhat. Ez a BSD job koncepciónak felel meg.
====Szignál maszk====
lásd később, a szignáloknál.
====A processzek legfőbb tulajdonságai:====
* PID - Process Identifier, egyedi azonosítószám
* PPID - Parent PID, a szülő processz azonosítója
* PGID - Process Group ID, a processz csoportazonosító
* Login név
* UID - valós felhasználói azonosító
* Effektív UID - ez a setuid bittel rendelkező processzeknél eltérhet a valós UID -tól
* GID - valós felhasználói azonosító
* Effektív GID - ez is a set-uid bites alkalmazásoknál játszik.
* Kiegészítő csoportazonosítók
* Munkakatalógus
* UMASK - állományok létrehozási maszkja, egy bitmaszk, mely minden, a processz által létrehozott állomány védelmi attribútumainak kialakításában részt vesz.
* Szignál maszk
* Terminál azonosító
* szekció azonosító
* Futási idők.
A processzkezeléshez használatos függvények:
'''abort(),exit(),execl(),execle(),execlp(),execv(),execve(),execvp(),wait(),waitpid()'''

===Állománykezelés===
* Az állományok neveit egy nem tisztán fa struktúrájú hierarchiában képzeljük el.
* Öt féle állománytipust különböztet meg a szabvány:
** normál állomány (regular file),
** katalógus (directory),
** FIFO
** blokkos elérésű eszköz,
** karakteres elérésű eszköz.
* Javasolja, hogy az állományok nevei hordozható állománynevek legyenek, azaz:
** angol abc kis és nagy betűi
** egyéb karakterek: '''. _ -''' (pont,aláhúzás,kötőjel)
* Az állománynevek a */* karakterrel legyenek elválasztva, egymás után több ilyen jel azt jelenti, hogy csak egy van. Útnév elején nem lehet több /.
* Az állományok legfontosabb tulajdonságai:
** Állomány tipusa
** Hozzáférés védelmi kódja: Védelmi kód terén legalább a UNIX 3x3 as védelme, ha annál jobb, akkor:
*** állományonként be/kikapcsolható legyen
*** az alkalmazói szempontból ugyanúgy kell megjelennie, mint az eredeti 3x3 as, tehát létezzék a tulaj, csoport, bárki fogalmak mindegyike.
*** Ha engedélyezve van, akkor a korábbi védelmet felülírva jelenik meg a rendszerhívásoknál (*stat,fstat*)
** Egyedi azonosítószám (i-node)
** hivatkozás számláló
** tulajdonos UID, GID
** állomány hossza bájtban
** utolsó módosítási idő
** utolsó hozzáférési idő
** utolsó státusz módosítási idő, amikor a struktúra módosítva lett, gyakorlatban az i-node módosítási ideje
* Nem használható az '''mknod()''' hívás, helyette, a speciális fájlokhoz: '''mkdir(), mkfifo()'''
* Katalógusok kezelésére külön interfész: '''mkdir(), rmdir(), opendir(), readdir(), rwinddir(), closedir()'''
* katalógusoknál átnevezéshez nem használható a '''link() unlink()''', hanem bevezeti a '''rename()''' rendszerhívást.
* Az állományok megnyitásánál nem lehet használni az '''O_SYNC''' flag -et, ls a '''sync()''' rendszerhívást, helyette '''fsync()''' rendszerhívás
* '''dup()''' egy megynitott fájl leírót lehet lemásolni, a másolaton keresztül is ezt érem el
* '''dup2()''' ezzel meg lehet mondani, hogy a megnyitott fájlok struktúrájában hol keressen szabad helyet.
* el lehet '''seek()''' eltetni a fájlt, lehet benne luk. definíció szerint a lukból olvasva 0 -át kapunk.

===Szignálkezelés===
Ezen a téren a POSIX szakított mind a BSD, mind a System V filozófiával. A probléma, ami miatt ez következett be a következő:
Mi van, ha egy szignál érvényre jut, majd elindul a kezelő rutin, és közben bejön újra ugyanaz a szignál?
* System V: a szignál érvényrejutásakor visszaáll alapértékre. Ha ez az alkalmazásnak nem felel meg, akkor a kezelőrutinban újra át kell venni, különben az alapértelmezett tevékenységet hajtja végre a rendszer, ami a legtöbb esetben programmegállás. Amennyiben a program nem tudja elég hamar visszavenni a szignált, ki fog lépni, és ez előfordulhat.
* BSD: nem áll vissza alaphelyzetbe. Feltételezi, hogy a kezelő rutin újrabelépő, ez nem mindig megvalósítható.
* *POSIX*: Hardveres szemlélet, minden szignálkezelő rutin mellé adunk egy maszkot is. Ez a maszk mondja meg, mely szignálok '''nem''' juthatnak érvényre.
hívások tehát: '''sigaction()''' A processz szignál maszkja a '''sigprocmask()''' függvénnyel állítható, szignálkezelő rutin esetén az érvényes maszk a processz szignál maszkja, unio a szignálkezelő maszk, unió az aktuális szignál.

===Terminálkezelés===
* speciális vezérlőkarakterek maradtak, megmaradt a kanonikus, és a nem kanonikus mód. megszűnt az '''ioctl()''', tál sokoldalú volt, helyette:
* '''tcsetattr(),tcgetattr()'''
* Fontos a struktúrált, átlátható terminálkezelés, és minden programnak biztosítania kell, hogy visszaállítja az elállított terminál paramétereket.

OLD STUFF:
* posix.ps
* Process Creation and Control
* Signals
* Floating Point Exceptions
* Segmentation Violations
* Illegal Instructions
* Bus Errors
* Timers
* File and Directory Operations
* Pipes
* C Library (Standard C)
* I/O Port Interface and Control

==POSIX.1 alapjául szolgáló rendszerek. Fôbb tématerületek a POSIX.1-ben. File rendszer filozófiája. Fontosabb rendszerhívások file, és terminálkezelés területén. ==
* posix.ps
* UNIX

==Hordozható adatformátumok. Felmerülô problémák, elvi megoldások. ==
A POSIX meghatároz egy egységes operációs rendszer API -t, így a programozó szemszögéből minden rendszer hasonlít. Meg kell még oldani, hogy az egyes architektúrán érvényes korlátozások is beépüljenek a programba, hordozható legyen a forráskód, esetleg maga a bináris állomány is, valamint a konfigurációs fájlok. Az install scriptekről nem is beszélve.
Hogy az alkalmazás rugalmasan tudjon alkalmazkodni a konkrét architektúrához, két lehetőség kínálkozik:
* Fordítási időben: feltételese fordítási opciók és konstansok használatával. Ezt a C nyelv az '''unistd.h''' állomány konstansaival biztosítja.
* Futási időben: '''sysconf(),pathconf(),fpathconf()''' függvények
A POSIX maszatol a többi részlettel kapcsolatosan, miként lehet átvinni az adatokat, programokat. A hordozható adatformátumokról a POSIX.2 nyilatkozik a hordozandó alkalmazásról:
* Kell az alkalmazás forráskódja:
** A kódkészlet problémája merül fel. A POSIX az ISO 646 kódkészletre épül. Ezen kódkészletben sajnálatosan nincsenek benne olyan karakterek, amik viszont fellelhetőek a C forráskódban. Ennek kiküszöbölésére a javaslat, hogy un. trigraph karakterekkel "eszképeljék" ki ezen karaktereket. Ezek gyakorlatilag 3 karakteres betűsorozatok.
* A bináris hordozása:
** A POSIX.1 utal arra, hogy létezik egy ABI, Application Binary Interface, amivel megoldható a probléma kezelése. A másik megoldás az ANDF (Architecture Neutral Distribution Format), amely egy közbülső kódot definiál, amelynek alapján a végleges kód legenerálható
* Az alkalmazás adatai, és a dokumentáció
** Itt a számábrázolások a fontosak, mert ha mondjuk 32 bites rendszeren kiírok egy integert, majd beolvasom egy 64 bitesen, nem fog stimmelni. A problémát áthidalhatjuk szöveges átvitellel.
* install scriptek:
** POSIX.2 ezt részletesen taglalja

Figyelmet kell szentelni annak, hogy az állománynevek ne tartalmazzanak abszolút hivatkozást. A csomag előállításához régen a tar, ill cpio álltak rendelkezésre. A tar nem viszi át a device állományokat, a cpio meg a linkeket nem visz át. A mostani gnu tar mindent tud.

* XML?
* karakterkódolás?
* Little/Big Endian?

==Elosztott párhuzamos rendszerek, alapelvek, eszközök. Grid koncepció. ==
* rinteg_eloszt.pdf

-- [[HarmathDenes|thSoft]] - 2008.06.07.

[[Category:Infoszak]]

Rendszerintegráció vizsgakérdések 2008 tavasz - Laptörténet

Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoszak|RendszerIntVizsgaKerdesek2008}} A hivatkozott anyagok lelőhelye: http://www.iit.bme.hu/~szebi/rinteg.html ==X400 - funkcionális és arch…”