Pázmány Péter Katolikus Egyetem

Pázmány Péter Katolikus Egyetem

HTTP szerver megvalósítása Texas Instruments Stellaris LM3S6965 mikrokontrolleren

Diplomaterv

Szerző: Göndöcz Mátyás Témavezető: Tihanyi Attila

Információs Technológiai Kar 2012. május 21.

-0-

-1-

NYILATKOZAT Alulírott Göndöcz Mátyás, a Pázmány Péter Katolikus Egyetem Információs Technológiai Karának hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomamunkában csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Ezt a Diplomamunkát más szakon még nem nyújtottam be.

Göndöcz Mátyás

-2-

Kivonat Napjainkban az internet elterjedése következtében a hálózati kommunikáció az élet minden területén jelen van. Az adatátvitel többnyire HTTP kapcsolaton keresztül zajlik, az alkalmazások gyakran kliens-szerver architektúrán alapulnak. Feladatom egy mikrokontrolleres környezetben futó HTTP szerver megvalósítása volt. A fejlesztés hosszútávú célja az, hogy a program a CooCox CoOS beágyazott operációs rendszer által futtatható, önálló modul legyen. A program így alkalmas lesz arra, hogy beágyazott eszközök hálózaton keresztül történő elérését biztosítsa. Munkám eredményeképpen elkészült egy jól működő, egyszerű HTTP szerver, amely a Stellaris LM3S6965 mikrokontrolleren tesztelésre is került. A megvalósítás során kész szoftverkomponenseket használtam fel, ezek együttes működését kellett megoldanom. A dolgozatban ismertetem a szempontokat, amelyeket figyelembe kell venni a megvalósítás során, valamint alapvető elméleti áttekintést adok a kapcsolódó fogalmakról. Bemutatom az elkészített program fő elemeit, valamint a mikrokontrollert, amelyen a HTTP szerver program fut. Vázolom a tervezés során meghozott döntéseket és rövid leírást adok a program használatához, végül összegzem a tesztelés során kapott eredményeket.

-3-

Abstract Due to the level of penetration of the internet, communication via networks is present in all areas of our lives. Data transmission usually gets done via HTTP connection, and generally the software applications are based on a client-server architecture. My task was to implement a HTTP server which runs within a MCU environment. Long-term goal is to develop this program as a separate module, which is runnable by CooCox CoOS embedded operating system. This will allow managing embedded devices via access network. As the outcome of my work, a simple and working HTTP server has been completed. It also has been tested on the Stellaris LM3S6965 Evaluation Board. During its implementation I used COTS software components and my job was to make them work together nicely. In my thesis I review the necessary aspects to be considered during implementation, and provide an overview of concepts regarding this task. I show the main components of the completed program and introduce the LM3S6965 microcontroller unit, which provides the background environment for it. I cover the decisions made during planning and provide a brief description of using the program, finally I sum the test results.

-4-

Tartalomjegyzék Tartalomjegyzék ............................................................................................................... 5 1

2

Bevezetés .................................................................................................................. 8 1.1

A megvalósítás követelményei......................................................................... 8

1.2

A dolgozat felépítése ...................................................................................... 10

Fogalmak bevezetése, áttekintés ............................................................................. 11 2.1

A hardver: Texas Instruments Stellaris LM3S6965 ....................................... 11

2.1.1

Az ARM Cortex architektúráról ............................................................ 12

2.1.2

Az LM3S6965 mikrokontroller ............................................................. 13

2.1.3

Az alaplap .............................................................................................. 13

2.1.4

Ethernet interfész ................................................................................... 14

2.1.5

SD/MMC csatlakozó ............................................................................. 15

2.2

A rendszer szoftver elemeinek áttekintése ..................................................... 15

2.2.1

LwIP ...................................................................................................... 16

2.2.1.1

3

4

TCP/IP protokollcsalád ...................................................................... 17

2.2.1.1.1

IP-címek tartományainak jelölési módjai.................................... 18

2.2.1.1.2

Példa az IP-cím és netmask kapcsolatára.................................... 19

2.2.1.1.3

Speciális IP-címek....................................................................... 20

2.2.1.2

HTTP protokoll .................................................................................. 21

2.2.1.3

A HTML jelölőnyelv felhasználása.................................................... 21

2.2.2

FatFs fájlrendszerkezelő ........................................................................ 21

2.2.3

CooCox CoOS operációs rendszer ........................................................ 22

Beágyazott rendszerek felépítése ............................................................................ 23 3.1

Operációs rendszer nélküli programok........................................................... 24

3.2

Operációs rendszerekkel kapcsolatos fogalmak ............................................. 24

3.2.1

Időosztásos operációs rendszer.............................................................. 24

3.2.2

A LM3S6965 időzítése .......................................................................... 25

3.2.3

Interruptok ............................................................................................. 26

Beágyazott rendszerek kommunikációja interneten................................................ 28 4.1

HTTP protokoll .............................................................................................. 28

4.1.1

A HTTP helye a hálózati kommunikációs modell rétegeiben ............... 28

4.1.2

HTTP üzenetek felépítése...................................................................... 30

4.1.2.1

Egy HTTP kérés felépítése................................................................. 30

4.1.2.1.1

HTTP metódusok ........................................................................ 31

4.1.2.1.2

Biztonságos metódusok............................................................... 31

-5-

4.1.2.1.3 4.1.2.2

5

6

7

9

HTTP válaszüzenet státuszkódjai....................................................... 32

4.2

A HTML dinamikus kiterjesztése .................................................................. 33

4.3

Az LM3S6965 hálózati kommunikációja....................................................... 33

Tervezés .................................................................................................................. 34 5.1

Igény egy operációs rendszerre ...................................................................... 34

5.2

A CooCox CoOS operációs rendszer kiválasztása ......................................... 35

5.3

A CooCox CoOS tulajdonságai...................................................................... 36

5.4

A CooCox CoIDE fejlesztőkörnyezet ............................................................ 37

5.4.1

Kapcsolat a hardverrel ........................................................................... 37

5.4.2

A CoIDE v1.4.1-ben felhasznált modulok............................................. 38

5.4.2.1

COMMON könyvtár .......................................................................... 39

5.4.2.2

BOOT könyvtár.................................................................................. 40

5.4.2.3

PERIPHERAL.LUMINARY könyvtár .............................................. 40

Implementáció végrehajtása.................................................................................... 41 6.1

Enet_lwip használata HTTP szerver megvalósítására.................................... 41

6.2

Interruptok kezelése ....................................................................................... 45

6.2.1

SysTick interrupt ................................................................................... 45

6.2.2

Ethernet interrupt ................................................................................... 45

6.3

A PLL és az alapidőzítés beállítása a programban ......................................... 46

6.4

Az SSI kiterjesztés használata a programban ................................................. 47

6.5

A program használata..................................................................................... 49

Tesztelés.................................................................................................................. 50 7.1

8

Idempotens metódusok ............................................................... 32

ARP ................................................................................................................ 51

7.1.1

ARP közös alhálózat esetén................................................................... 52

7.1.2

ARP eltérő alhálózat esetén ................................................................... 54

7.2

IP .................................................................................................................... 57

7.3

TCP................................................................................................................. 57

7.4

HTTP.............................................................................................................. 59

7.5

Dinamikus tartalom megjelenítése ................................................................. 60

Összefoglalás .......................................................................................................... 62 8.1

Eredmények.................................................................................................... 62

8.2

További fejlesztési lehetőségek...................................................................... 63

Köszönetnyilvánítás ................................................................................................ 65

10

Fogalmak jegyzéke ............................................................................................. 66

11

Rövidítések jegyzéke .......................................................................................... 67

12

Ábrák jegyzéke ................................................................................................... 69 -6-

13

Táblázatok jegyzéke ........................................................................................... 70

14

Irodalomjegyzék ................................................................................................. 71

15

Mellékletek ......................................................................................................... 78

-7-

1 Bevezetés Napjainkban az internet és a hálózati kommunikáció az élet minden területén jelen van. Rengeteg alkalmazás alapul HTTP-kapcsolatra, a kliensek és szerverek közötti adatforgalom pedig egyre nagyobb méreteket ölt, különösen a közösségi kommunikáció jelentős mértékű térhódítása óta. Az egyre intelligensebb orvosi beavatkozó- és mérőeszközök elterjedésével az egészségügyben is megjelent az igény arra, hogy ezeket akár távolról is lehessen vezérelni, az általuk begyűjtött adatokat leolvasni. A HTTP szerver megvalósítás hosszútávú célja, hogy egy beágyazott operációs rendszeren önálló modulként futtatható legyen. Az LM3S6965 mikrokontroller képességei lehetővé teszik, hogy emellett a modul mellett több más modult futtathasson az operációs rendszer, így az általam választott feladat befejezése nem eredményez szűk körű alkalmazási területet, és mód van további fejlesztésekre is. A rendszer moduláris jellege miatt adaptálható vezeték nélküli hálózati csatlakozóval rendelkező, ARM-alapú mikrokontrollerre. Ez lehetőséget teremtene az egyetemen Tihanyi Attila tanár úr és hallgatói által fejlesztett izomstimulátor adatainak leolvasására és távoli vezérlésére, valamint segítené a jövőbeni mikrokontrolleres témák oktatását, felhasználható eszközt nyújtva a hallgatók számára. (2011-ben az izomstimulátort bemutató TDK dolgozattal Nagy György és Fodor András hallgatótársaim a XXX. Jubileumi Országos Tudományos Diákköri Konferencián I. helyezést és különdíjat értek el Informatika Tudományi Szekcióban.[1]) Az én feladatom ennek előkészítése Ethernet-alapú hálózatos megvalósítással. Jelenleg van olyan hallgató, aki megkezdte a vezeték nélküli megoldás elkészítését. Személyes motivációm volt a feladat kiválasztásakor, hogy a hálózati kommunikáció témájával szívesen foglalkozom, szakmai gyakorlatomat is egy webes fejlesztéssel foglalkozó cégnél töltöttem.

1.1 A megvalósítás követelményei A szerver a hálózaton történő kommunikációhoz a feladatkiírásnak megfelelően a 4.1. fejezetben részletesebben ismertetett HTTP (Hypertext Transfer PRotocol) protokollt használja. Ez azt jelenti, hogy a hétrétegű OSI (Open Systems Interconnection) modell – illetve a négyrétegű TCP/IP protokollcsalád egymásra épülő rétegeiből a megfelelő protokollokat meg kell valósítania. A kiszolgáló sikeres kommunikációjának feltételei:

-8-




IP-címet kell, hogy kapjon, mert ezen lesz elérhető a hálózaton keresztül, valamint a többi eszközzel is tudnia kell kommunikálni. Ezért szükség van az IP (Internet Protocol) megvalósítására, valamint az IP alatti szintről az ARP (Address Resolution Protocol) kezelésére is.




Az IP-csomagokat a TCP (Transmission Control Protocol) protokoll [2] kezeli, (sorbarendezés, megérkezés visszaigazolása, szükség esetén újraküldés, stb.) ezért a megvalósításnak ezt is tartalmaznia kell.




Ezután a HTTP–protokollban alapértelmezett 80-as portot [3] kell figyelnie, itt érkeznek majd a jövőbeni HTTP–kérések IP adatcsomagjai.




A kiszolgáló képes kell, hogy legyen az esetleges hálózati hibák kezelésére, értelmeznie kell a legfontosabb HTTP–kéréseket (a HTTP/1.1 szabvány szerint minimálisan a GET és a HEAD metódust ([4] 5.1.1 fejezete) - de a mi esetünkben egyelőre a GET megvalósítása is elegendő), valamint szabvány szerinti válaszokat kell küldenie a kliensnek. Ezen válaszoknak tartalmazniuk kell a megfelelő státusz-kódot, fejlécet, és az esetleges üzenettestet. A kommunikáción túl szükség van arra, hogy a szerver képes legyen fájlok kezelésére,

hiszen a legtöbb kérés, amelyre számítani lehet a működés során, olyan erőforrások kezelését fogja szükségessé tenni, amelyek HTML-, CSS-, vagy képfájlként vannak reprezentálva. Ez a feladat célszerűen a hordozható eszközökön tipikusan alkalmazott és az elterjedt operációs rendszerek által is támogatott FAT fájlrendszerrel valósítható meg. A megfelelő tárhelykapacitás, valamint a tartalom könnyű módosítása érdekében életszerűtlen lenne, ha a program nem tudná kezelni az alaplapra integrált memóriakártya-foglalatot. A feladatkiírás része, hogy a kiszolgált tartalom legyen dinamikussá tehető speciális sztringek alkalmazásával, a CGI vagy az SSI szabványhoz hasonlóan. Az ilyen kiterjesztés lehetőséget ad arra, hogy az előre elkészített HTML fájlokba a fix tartalom mellett folyamatosan frissülő adatokat lehessen beágyazni. Így például nyomon követhető a szerver, valamint alaplap perifériáinak állapota. Mivel a program mikrokontrolleren működik, nem elvárás, hogy villámgyors fel-, és letöltési sebességgel, nagyméretű médiafájlokat szolgáljon ki, sem az, hogy egyszerre nagy számú kliens kapcsolódhasson hozzá. Nem igény a szerverrel szemben, hogy bármilyen gyorsítótárazást (cache) tartalmazzon. A felhasználási területnek megfelelő keretek között kell működnie. A feladatkiírásnak nem része, de hosszú távon fontos cél, hogy a HTTP szerver program a CooCox CoOS operációs rendszerben külön modulként futtatható legyen (lásd: 2.2.3. fejezet). Ezt figyelembe kell vennem a fejlesztés során.

-9-

1.2 A dolgozat felépítése A dolgozat a feladat értelmezésével és a követelmények meghatározásával kezdődik. A 2. fejezet két fő részre tagolódik, melyekben a megvalósítás során alkalmazott hardver és szoftver elemek ismertetése olvasható. A feladatkiírásban szereplő mikrokontrollert a 2.1. fejezetben mutatom be. A 3. fejezetben a beágyazott rendszerek felépítését taglalom. A dolgozat 4. fejezetében a hálózati kommunikációval foglalkozom, különös tekintettel a HTTP protokoll vonatkozó részeire, de itt tárgyalom a dinamikus kiegészítést is. Az 5. fejezetben ismertetem a tervezés folyamatát és bemutatom az indokokat, amelyek szükségessé tették egy beágyazott operációs rendszer kiválasztását. A döntés szempontjai után ismertetem a választott CooCox rendszer elemeit. Az implementációról a 6. fejezetben számolok be. A 7. fejezetben az elkészült munka tesztelését és értékelését végzem el, a munka eredményeinek összefoglalását pedig a 8. fejezetben végzem el. A diplomaterv dolgozatban építettem a korábban a diplomatervezést előkészítő tárgyak elvégzése során a témával kapcsolatban általam írt munkákra, és ahol nagyobb részletek átvételére került sor, ezt jelzem is. Jelen dolgozatban IP-cím alatt a 4-bájtos, IPv4 formátumú címzést értem. A TCP/IP rendszerbeli adatcsomagok elnevezése az egyes szinteken más és más. Pásztor Miklós előadása ([5] „Csomagok neve” szakasz) alapján Ethernet rétegbeli csomag esetén a frame kifejezést használom, IP szinten a datagram, TCP csomagnál pedig a szegmens jelölést alkalmazom.

- 10 -

2 Fogalmak bevezetése, áttekintés Ebben a fejezetben bemutatom a felhasznált hardvert és az elkészített szoftver alrendszereit. A tervezésről az 5. fejezetben írok, az implementációt a 6. fejezetben tárgyalom, ezért ezekről a kérdésekről ebben a fejezetben csak minimálisan ejtek szót. Az elkészült program tesztelésekor nagy hangsúlyt fektettem a hálózati kommunikáció vizsgálatára, erről a 7. fejezet szól.

2.1 A hardver: Texas Instruments Stellaris LM3S6965 A Stellaris LM3S6965 mikrokontrollert egy úgynevezett evaluation board-ra (körülbelül kiértékelő lapként lehetne fordítani, a továbbiakban alaplapként fogok hivatkozni rá) integrálták, ami megkönnyíti a használatot. A munkavégzéshez az egyetem biztosította számomra ezt a fejlesztéshez használt ARM-alapú eszközt. A 2.1. ábra az eszközt működés közben mutatja.

2.1. ábra: Stellaris LM3S6965 Ethernet Evaluation Board működés közben.

- 11 -

2.1.1 Az ARM Cortex architektúráról Az ARM (Advanced RISC Machines) félvezetőipari tervező cég, amely maga nem gyárt processzorokat, hanem a tervek licenceit adja el partnereknek [6], például a Texas Instrumentsnek is. 2004-ben jelentették be a Cortex processzorcsaládot, első tagjaként pedig a Cortex-M sorozatot [7]. Használnak ilyen processzorokat általános célú mikrokontrollerekben, videojátékok hardvereiben, okostelefonokban és sokféle hordozható eszközben. A Cortex processzorcsalád három ágra bomlik, ezeket stílszerűen A-, R-, és Msorozatnak nevezték el [8]. A Cortex-A sorozat nagyteljesítményű processzorokat foglal magába, melyeket felhasználói alkalmazásokhoz szánnak. A Cortex-R sorozatot valósidejű rendszerekhez fejlesztették ki, míg a Cortex-M sorozat tagjait mikrokontrollerekbe, beágyazott rendszerekbe szánják [9], és energiatakarékos működésre hegyezték ki. A 2.2. ábra szemlélteti az LM3S6965-ben alkalmazott Cortex-M3 architektúra felépítését.

2.2. ábra: Az ARM Cortex-M3 processzor blokkdiagramja. (Kép forrása: [10])

A Cortex-M Harvard architektúrára épül, és támogatja a Thumb, illetve Thumb2 utasításkészleteket [11]. Háromlépéses fetch-decode-execute pipeline-t is beleépítenek, valamint a fetch művelet során egyszerre két utasítást olvas be a processzor [12]. Nemcsak assembly-ben, hanem C nyelven is programozható.

- 12 -

2.1.2 Az LM3S6965 mikrokontroller A mikrokontroller tulajdonságai [13] közül a következőket emelném ki:

•

32-bites, RISC ARM® Cortex™-M3 v7M architektúra

•

50MHz működési frekvencia

•

System Timer (SysTick)

•

NVIC (Nested Vectored Interrupt Controller) interruptvezérlő

•

256kb Flash

•

64kb SRAM

•

Teljesen integrált Ethernet 10/100 (MAC+PHY) vezérlő [14]

•

Akár 42 GPIO (összesen 100 lába van)

•

-40°C – +85°C hőmérséklettartományban működik Talán ez túl erős hardvernek tűnik ahhoz, hogy csupán egy HTTP szerver fusson rajta.

Lehetne egy kisebb tudású mikrokontrollert alkalmazni a TCP/IP kezeléséhez egy kisebb tárhellyel társítva. Azonban a távlati cél az, hogy a HTTP kiszolgáló csak egy legyen az operációs rendszer által vezérelt feladatok közül, amelyek egymás mellett futnak.

2.1.3 Az alaplap Használata egyszerű: az USB-csatlakozón kapja az áramot, és ezen keresztül programozható is, valamint soros kommunikációra is lehetőséget ad [15]. Természetesen az alaplapra szerelték magát az LM3S6965 mikrokontrollert. Ezen kívül helyet kaptak rajta:


Ethernet csatlakozó




128x96 pixeles OLED kijelző, amely 16 színárnyalat megjelenítésére képes




Reset- és navigációs gombok




Mágneses PWM speaker




Programozható státusz LED




Jelölt kivezetések (a mikrokontrollerről az alaplapra)




MicroSD kártyafoglalat




JTAG csatlakozó




USB-csatlakozó

- 13 -

Az alaplapot nem kész terméknek, hanem fejlesztésekhez alkalmas eszköznek szánják, és sok C nyelvű példakód is elérhető hozzá [16]. Ezeket én is felhasználtam a HTTP szerver programhoz (lásd: 2.2. fejezet). Az alaplap felépítése a 2.3. ábra látható.

2.3. ábra: Az LM3S6965 alaplap blokkdiagramja. (Kép forrása: [15])

2.1.4 Ethernet interfész A mikrokontroller egyik legfontosabb tulajdonsága a teljesen integrált Ethernet vezérlő. Az RJ45 csatlakozó az alaplapra van integrálva, így az eszköz teljes 10/100BaseT interfésszel rendelkezik. Az MDI/MDI-X automatikus támogatását is beleépítették, így nincs szükség keresztkötésű (crosslink) UTP-kábelre, amikor a hálózatra, vagy egy másik alaplaphoz csatlakoztatják. A mikrokontroller az Ethernet fizikai rétegének időzítéséhez egy, a fő oszcillátortól teljesen független, 25MHz-es kristályt használ [17]. A mikrokontroller Ethernet-vezérlője megfelel az IEEE 802.3-2002 specifikációnak, teljes értékű autonegotiation funkcióval bír, támogatja a duplex és szimplex 100 Mbps, duplex és szimplex 10 Mbps üzemmódokat. A fizikai cím és a csatlakozó LEDjei is programozhatók [18].

- 14 -

2.4. ábra: Az Ethernet vezérlő blokkdiagramja. (Kép forrása: [19])

Az Ethernet vezérlő két rétegre osztható: PHY (Network Physical) és MAC (Media Access Controller) rétegekre, amelyek az OSI modell (lásd: 4.1. ábra.) első és második rétegének felelnek meg (2.4. ábra).

2.1.5 SD/MMC csatlakozó Az alaplapon külső illesztőként MicroSD kártya csatlakozót is elhelyeztek. Az alaplaphoz példakódok között szerepel olyan, amely könyvtárak és fájlok beolvasását demonstrálja egy FAT fájlrendszerrel formázott SD kártyáról. Ebben minden adat-, és vezérlési utasítás a kártya SPI üzemmódját használja. A SD specifikáció nem írja elő a gyártók számára kötelezően az SPI mód támogatását, de a legtöbb kártya így is támogatja (használat közben nekem sem adódott ebből problémám) [20]. A fejlesztés során egy 2Gb-os kártyát használtam. A programban az mmc-ek-lm3s6965.c fájlban találhatók a memóriakártya használatához szükséges függvények. Ezek három csoportba sorolhatók: alacsony szintű utasítások (például: CHIP SELECT), diszk szintű utasítások (például: disk_status, disk_read, disk_write) és a fájlrendszer időkezeléséhez szükséges get_fattime függvény. A HTTP szerver megvalósításában nem volt szükség a kártyára történő írásra, az adatok beolvasása elegendő a kliensek kiszolgálásához.

2.2 A rendszer szoftver elemeinek áttekintése A Stellaris sorozatba tartozó eszközökhöz a Texas Instruments elérhetővé tett egy StellarisWare nevű programkönyvtárat, amely sok alaplaphoz és perifériához tartalmaz példakódokat. Többek között az időzítés beállításához, a különböző perifériák illesztéséhez, fájlrendszer kezeléséhez is találhatók benne minták.

- 15 -

Erre a programcsomagra alapul az elkészített HTTP szerver program is, természetesen kisebb-nagyobb módosításokkal. Felhasználja az LwIP [21] könyvtárat (LightWeight IP. a TCP/IP protokoll egy megvalósítása), és alkalmazza a FatFs [22] fájlrendszer-kezelőt (beágyazott rendszerek számára C nyelven írt modul). Ezeket integráltam a CooCox saját moduljaival (lásd: 5.4.2. fejezet). A fejlesztéshez megismertem és használatba vettem a CoIDE fejlesztőkörnyezetet.

2.2.1 LwIP Az elkészített HTTP szerver program használja az LwIP (LightWeight IP) könyvtárat, amely a TCP/IP protokollcsalád egy elterjedt megvalósítása. Ezt eredetileg Adam Dunkels fejlesztette a Svéd Számítástechnikai Intézetnél, mostanra azonban nem ő a kizárólagos fejlesztő. Az implementáció célja az erőforrás-használat csökkentése, miközben teljesértékű TCP szolgáltatást nyújt [21].

2.5. ábra: Internet protokollok és programok. (Kép forrása: [5])

Az általam az LwIP-ből felhasznált protokollok (egymáshoz való viszonyaikat a 2.5. ábra. ábra mutatja): ARP (Address Resolution Protocol) – A fizikai címfeloldáshoz. - 16 -

DHCP (Dynamic Host Control Protocol) – Dinamikus IP-címkiosztás (ha nincs a helyi hálózatban DHCP-szerver, akkor az eszköz AUTOIP segítségével egy Link-Local tartományba eső címet szerez). IP (Internet Protocol) – Az adatcsomagok hálózati átviteléhez. UDP (User Datagram Protocol) – A DHCP protokoll erre épül. Nem szükséges hozzá kapcsolat felépítése a küldő és a fogadó fél között. ICMP (Internet Control Message Protocol) – Hálózati hibaüzenetek és vezérlő üzenetek küldéséhez. TCP (Transmission Control Protocol) – Az adatok csomagokra bontásához, küldéséhez, és a sorrend visszaállításához, hibakezeléshez. A küldő és a fogadó felek itt kapcsolatot építenek ki, ellentétben az UDP-vel.

2.2.1.1 TCP/IP protokollcsalád A TCP/IP-alapú hálózatokat csomagkapcsoltnak nevezik, mert a kommunikáció az adatok csomagokra bontásával, és ezen csomagok továbbításával történik. A csomagok által bejárt útvonal a hálózat forgalmi telítettségétől is függ. (A TCP/IP protokollcsalád kialakulását és réteges felépítését a 4.1.1. fejezetben mutatom be.) Az általános csomagtovábbítási stratégiát úgy alakították ki, hogy amikor egy interfésznek egy adatcsomagot kell küldenie, két lehetőség áll fenn attól függően, hogy a csomag küldője és címzettje ugyanarra az alhálózatra kapcsolódik-e. Egy-egy adatcsomag küldésekor a hálózati eszközök az alábbi két eset vizsgálatát iterálják, amíg végül a csomag célba nem ér:

•

Az egyik eshetőség az, hogy a csomag feladója és címzettje külön alhálózaton van. Ekkor a csomagot a küldő interfész alapértelmezett átjárója (default gateway) kapja meg, az IPcíme alapján. Ilyenkor a gateway eszköz a továbbítás előtt a csomagban átírja a feladó fizikai címét a sajátjára. (I.)

•

A másik konfigurációs eset az első komplementere: a csomag címzettje ugyanazon alhálózathoz tartozik, mint az interfész. Ekkor közvetlenül a címzett részére kerül továbbításra az adat a fizikai cím alapján, tehát az IP-cím alatti réteg jut szerephez a kommunikációban. (II.) Annak meghatározása, hogy két eszköz ugyanarra az alhálózatra kapcsolódik-e, az IP-

címhez tartozó, úgynevezett alhálózati maszk (netmask) segítségével történik. A netmask egy olyan, 32-bites szám, amelynek az elején csupa 1-es áll, ezek után pedig csupa 0 következik. Az IP-címet és a hozzá tartozó netmaskot bitenként párba állítva, és a párokon bitenkénti AND - 17 -

műveletet elvégezve (maszkolás) kapjuk meg a hálózat címét. Amennyiben ez a cím mindkét hálózati interfész esetén megegyezik, akkor ők ugyanarra az alhálózatra kapcsolódnak. A HTTP szerver programjában a TCP/IP-ből használt protokollok működését a 7. fejezetben tesztelem.

2.2.1.1.1 IP-címek tartományainak jelölési módjai Egy IP-címtartományt – tehát az alhálózatot képező címeket – a legkisebb címével és a hozzá tartozó netmaskkal szokás megadni ([5] „Internet címek” szakasz). A netmask hosszából számolható a címtartomány nagysága (számossága). Egy IP-cím a netmask nélkül, önmagában nem egyértelmű. Az IPv4 szabványban kiosztott címek 4-bájtosak. Mind önálló címek, mind tartományok megadásánál leggyakrabban az úgynevezett pontozott decimális jelöléssel találkozhatunk. A címhez tartozó alhálózati maszkot általában a két, alább bemutatott leggyakoribb jelölés ([5] „Internet címek” és „CIDR” szakasz) közül az egyikkel írják le. Az egyszerűbbik lehetőség, hogy az IP-cím mellett a netmaskot is pontozott decimális formátumban tüntetik fel. A másik eset az, hogy nem bájt, hanem bit-alapú jelölést választanak. Ez a gyakorlatban azt jelenti, hogy az IP-cím után a netmask bitjeinek hosszát írják. Példa címtartomány megadására a pontozott decimális jelöléssel: 172.016.0.0/255.240.0.0 Ugyanez a hálózat a másik jelöléssel: 172.016.0.0/12 A teljes tartomány ekkor: 172.016.0.0 – 172.031.255.255 A 2.6. ábra mutatja be a fenti IP-cím bitenkénti felírását.

2.6. ábra: 172.016.0.0/12 hálózat szemléltetése

- 18 -

A netmask maximális hossza értelmes esetben 30 bit, így az alhálózati és broadcast cím mellett kettő kiosztható host cím marad ([23] 1. fejezete). (Megjegyzés: speciális esetként egy /32-es tartomány egyetlen IP-címet jelent.)

2.2.1.1.2 Példa az IP-cím és netmask kapcsolatára Az ipconfig parancs [24] segítségével meghatározható a számítógépnek kiosztott IPcím, és a hozzá tartozó netmask. A kapott kimenet egy részlete a parancssorból:

C:\Users\hallgato>ipconfig /all […] Ethernet-adapter Helyi kapcsolat: Kapcsolatspecifikus DNS-utótag. . : itk.ppke.hu Leírás. . . . . . . . . . . . . . : Intel(R) 82566DM-2 Gigabit hálózati kapcsolat Fizikai cím . . . . . . . . . . . : 00-0F-FE-D3-19-CC DHCP engedélyezve . . . . . . . . : Igen Automatikus konfiguráció engedélyezve : Igen Kapcsolati szintű IPv6-cím . . . : fe80::b9d5:7c86:33a9:2ebf%10(Kívánt) IPv4-cím. . . . . . . . . . . . . : 10.4.20.154(Kívánt) Alhálózati maszk. . . . . . . . . : 255.255.255.0 Bérleti jog kezdete . . . . . . . : 2012. április 18. 18:01:10 Bérleti jog vége. . . . . . . . . : 2012. április 19. 18:01:09 Alapértelmezett átjáró. . . . . . : 10.4.20.254 DHCP-kiszolgáló . . . . . . . . . : 10.4.20.252 DNS-kiszolgálók . . . . . . . . . : 193.225.109.62 […] A fenti esetben a netmask első 24 bitje 1, a többi 0. Ezt jelöli a pontozott decimális alakban a 255.255.255.0 cím. Tehát az IPv4-címet ezzel maszkolva a hálózat címére 10.4.20.0 adódik. Ebben a hálózatban elméletileg 255 cím kiosztása lehetséges. A hálózat broadcast címe 10.4.20.255, a default gateway pedig 10.4.220.254. Ezek alapján a „közönséges” eszközök interfészei számára kosztható címtartománynak a 10.4.220.1 – 10.4.20.253 adódik, és a fenti, 10.4.20.154-es IP-cím valóban ebbe az intervallumba tartozik. - 19 -

2.2.1.1.3 Speciális IP-címek Az alhálózatban kiosztható legnagyobb cím a hálózat úgynevezett broadcast címe, vagyis az erre küldött csomagokat minden, az alhálózathoz tartozó interfész megkapja. Az alhálózatban kiosztható legkisebb cím magát a hálózatot jelöli. Ezeket a címeket nem osztják ki az interfészeknek. Az alhálózatban alapértelmezett átjáró interfésze a gyakorlatban általában a hálózat broadcast címétől eggyel kisebb címet kapja meg, a többi „közönséges” hálózati eszköz számára pedig a maradék címtartományból oszthatók ki a szabad címek. Vannak speciális célokra fenntartott IP-címek. Ezeket az 5735-ös számú RFC-ben leírt jelenlegi legjobb gyakorlat (Best Current Practice) határozza meg ([25] 3. fejezete). Közülük a HTTP szerver megvalósítása szempontjából fontosakat emelem ki (2.1. táblázat.): Tartomány

Fenntartás célja Jelentése: „ez” a hálózat.

0.0.0.0/8

Jelentése: „ez” a kliens „ezen” a hálózaton. A 0.0.0.0/8 tartomány többi címe jelölhet konkrét klienst. Privát hálózatok számára fenntartva.*

0.0.0.0/32 10.0.0.0/8

172.16.0.0/12

Ez a tartomány szolgál a visszacsatolás megvalósítására. Egy magasabb szintű protokoll által bármely, a tartományon belüli címre küldött datagram az interfészhez tartozó eszközön belül marad, a hálózatra nem kerül kiküldésre IPszinten. Az ebbe az intervallumba tartozó címek nem jelenhetnek meg semmilyen hálózaton. A 127.0.0.1–es cím közismert. Rendszerint erre a címre vonatkoztatva implementálják a 127.0.0.0/8 tartomány local loopback funkcióját. Gyakran említik localhost néven is ezt a nevezetes címet. Ez az úgynevezett link-local tartomány. Olyan esetekben használható, amikor egy adott hálózati pontra több eszköz is csatlakozik. Az eszközök ilyenkor automatikus párbeszédet folytatva állítják be a saját link-local tartománybeli címeiket. A párbeszéd módját a 3927-es számú RFC határozza meg. Privát hálózatok számára fenntartva.*

192.168.0.0/16

Privát hálózatok számára fenntartva.*

127.0.0.0/8

127.0.0.1/32

169.254.0.0/16

Az IPv4 multicast címblokk, részletesen a 3171-es számú RFC foglalkozik vele. A „limited broadcast” cím. Ez helyi hálózati cím, az ide címzett adatcsomagokat tilos továbbítani másik helyi hálózatra. Használatára olyankor kerül sor, ha egy kliens 255.255.255.255/32 nem tudja a saját hálózati címét ([26] 7. fejezete). A használatra példa a BOOTP és a DHCP protokoll ([27] „Limited broadcast” szakasz). 224.0.0.0/4

2.1. táblázat: Fontosabb fenntartott IP-tartományok.

- 20 -

* Megjegyzés: az 1918-as számú RFC kifejezetten a privát hálózatok számára fenntartott címtartományokkal ([28] 3. fejezete) foglalkozik. Az itt meghatározott tartományok címei nem jelenhetnek meg a nyilvános Internet hálózaton, a külvilág elől el vannak rejtve. Ezek használathoz nem szükséges az IANA, vagy más, az IP-címek kiosztásáért felelős szervezet külön engedélye.

2.2.1.2 HTTP protokoll A feladatomat tekintve olyan hangsúlyos témakörnek tartom a HTTP protokollt, hogy külön fejezetben ismertetem az irodalma alapján a kapcsolódó ismereteket. Ehhez kapcsolódóan a TCP/IP protokollcsalád réteges felépítését, valamint a HTTP protokollnak ezen rétegeződésben elfoglalt helyét a 4.1.1. fejezetben tárgyalom.

2.2.1.3 A HTML jelölőnyelv felhasználása A HTML fájlok statikus szövegfájlok, amelyek a közölni kívánt tartalmi információn kívül a megjelenítés módját megadó jelöléseket is tartalmaznak, ezt nevezik angolul markupnak. A jelölés lehetséges HTML címkékkel is, a fájlba „bedrótozva”, vagy CSS stíluslapok segítségével. Ez utóbbi újabb és elegánsabb módszer, és az az előnye is megvan, hogy ha módosítani kell egy weblap kinézetén úgy, hogy a tartalom ne változzon meg (vagy fordítva), akkor elegendő a stíluslapot kicserélni. Ez sok felesleges munkát takaríthat meg. A statikus tartalom dinamikussá tehető javascript segítségével, vagy CGI (Common Gateway Interface), illetve SSI (Server Side Includes) tagek alkalmazásával is, erről a 4.2. fejezetben írok. A böngészőprogrammal megjelenített HTML–jelölés bárki számára értelmezhető formában mutatja a tartalmakat. Mivel böngészőprogramot mindenfajta PC-s operációs rendszer tartalmaz, ezért ez a platformok közötti eltéréseket is áthidalhatja. A különböző karakterkódolások, és a sokféle böngészőváltozat tartogat nehézségeket, azonban a böngészők folyamatos fejlesztésével egyre jobbá válik a helyzet. A fájlrendszer-kezelésre, a memóriakártya használatra, a TCP/IP protokollcsalád megvalósítására egészen a HTTP protokollig azért van szükség a feladatom megvalósításában, hogy a HTML által nyújtott lehetőségeket ki lehessen használni.

2.2.2 FatFs fájlrendszerkezelő A FatFs egy beágyazott rendszerek számára, C nyelven írt FAT fájlrendszerkezelő modul [22]. Több kötet használatát is támogatja, valamint lehetővé teszi hosszú fájlnevek használatát (LFN, Long File Name). Könnyen portolható, mivel a hardvertől függetlenre írták, a diszk I/O szinttől teljesen elkülönítve. Éppen emiatt a felhasználónak ki kell egészítenie a

- 21 -

programjában az alacsonyszintű lemezkezeléshez szükséges függvényekkel. A FatFs függvényei fájl szintű utasításokat tartalmaznak (application interface), de a lemez szintű elérés megvalósításához szükséges függvények (disk I/O interface) egy része is megtalálható a modulban. A programban a StellarisWare alapján a MicroSD kártya használatához alkalmazom a FAT32 fájlrendszert. A FatFs legfrissebb változatát (R0.09) használom fel, amely már támogatja az LFN-t, tehát nem csak az úgynevezett 8.3 formátumú fájlneveket tudja kezelni.

2.2.3 CooCox CoOS operációs rendszer Feladatomnak, a HTTP szerver elkészítésének hosszú távú célja az, hogy a CooCox CoOS beágyazott operációs rendszer által futtatható, önálló modul legyen, így az azt futtató, önálló működésre képes berendezés hálózaton keresztül történő elérését biztosítsa. Az operációs rendszer egyszerre több ilyen modult futtathat, és a fejlesztés során használt LM3S6965 mikrokontroller is képes megbírkózni a terheléssel, amelyet ez jelent. (A CoOSről még írok az 5. fejezetben.) Kopcsó Tamás hallgatótársam egy ilyen modult készített el, amely TFTP protokoll segítségével a beágyazott eszköz szoftveres frissítését és konfigurálását teszi lehetővé. Ezeknek a moduloknak első felhasználására az egyetemen fejlesztett izomstimulátorban kerülhet sor.

- 22 -

3 Beágyazott rendszerek felépítése A beágyazott rendszerek mikroprocesszor-alapú rendszerek, amelyeket egy, vagy néhány funkció ellátására építenek, és a végfelhasználó nem programozhatja őket úgy, ahogyan egy általános célú PC-t lehet átprogramozni a szoftver kibővítésével, vagy lecserélésével [29]. A beágyazott processzoroknak négy alapvető típusa van: 8 bites akkumulátor, 16/32 bites komplex utasításkészletű (CISC) processzor, csökkentett utasításkészletű (RISC) processzor és a digitális jelfeldolgozó processzor (DSP) [30]. Az LM3S6965 RISC architektúrára épül. A beágyazott eszközök teljesen integrált rendszerré váltak a processzor, a memória és a perifériák egy közös chipre történő összevonásával [31]. Beágyazott eszközre történő fejlesztés lehetséges keresztfordító segítségével: ilyenkor a szoftvert egy általános célú számítógépen (host) szerkesztik és fordítják, majd az eszközre (target) letöltve a kód debug-olása mindkét eszköz használatával történik [32]. A CooCox környezetben is így zajlik a programfejlesztés. Egy beágyazott, valósidejű operációs rendszer (RTOS) ellátja a memóriakezelés, feladatütemezés és erőforráskezelés feladatait (ilyen a CooCox CoOS is). Bonyolult alkalmazásoknál nagyon hasznos egy ilyen operációs rendszer alkalmazása, de egyszerűbb alkalmazások esetén a beágyazott rendszer működhet RTOS nélkül is [33]. Egy mikrokontrolleren működő HTTP szerver kisebb és egyszerűbb a „hagyományos” webszerverekhez képest (például: Apache, Nginx). Az ilyen kiszolgálók kevesebb beállítási lehetőséggel rendelkeznek, némelyik megvalósítás csak egyetlen kapcsolaton keresztül kapcsolódik a klienshez. Beágyazott környezetben nem a kiszolgálás sebessége a fontos, hanem az, hogy a szerver hogyan bánik a szűkös erőforrásokkal [34]. Mindemellett dinamikus tartalom szolgáltatására is van mód még mikrokontrolleres környezetben is. Egy ilyen szerver felépítését mutatja a 3.1. ábra. A dinamikus tartalomszolgáltatást megvalósító szkriptkezelés lehet többek között az SSI technika is.

3.1. ábra: A szerver-oldali szkriptfeldolgozás lépései. (Kép forrása: [34] 4. oldala)

- 23 -

3.1 Operációs rendszer nélküli programok Gyengébb mikrokontrolleren, vagy olyan speciális esetben, amikor csupán egyetlen feladat ellátása szükséges, használható operációs rendszer nélküli programfelépítés. Ilyenkor egy esetleges inicializálás után a program futása végtelen ciklusban zajlik. Eseményvezérelt programban ezt a ciklust interruptok szakítják meg és ezek handler függvényein keresztül valósul meg a tényleges működés. Egyszerűbb esetben nem is interruptok érkeznek, hanem busy-waiting jellegű a rendszer működése. Ekkor várakozás közben a processzor folyamatos terhelés alatt van, ez nem gazdaságos megoldás fogyasztás szempontjából. Hosszútávon kifejezetten az a cél, hogy a HTTP szerver ne ilyen rendszerben, hanem a CooCox CoOS operációs rendszeren belül működjön. A könnyebb fejlesztés érdekében azonban az elkészült program még operációs rendszer nélkül, önmagában fut a mikrokontrolleren, azonban a fejlesztés mostanra eljutott abba a stádiumba, hogy megkezdődhet az operációs rendszerbe történő integrálás. Az én feladatom ennek a CoOS-hez történő adaptálásnak az előkészítése volt, amelyet sikeresen elvégeztem.

3.2 Operációs rendszerekkel kapcsolatos fogalmak A HTTP szerver fejlesztéséhez és a hosszútávú feladat megoldásához egyaránt szükséges alapfogalmak rövid ismertetését adom ebben a fejezetben. (Ez a fejezet az általam korábban írt Mérnöki tervezés beszámoló című dokumentum egyes fejezeteire [35] épül.) Különbséget kell tenni az időosztásos, a multiprogramozott és a valósidejű operációs rendszer fogalma között: Időosztásos – más néven timesharing, vagy multitaszk [36] – operációs rendszerben egyszerre több felhasználó dolgozhat. Ilyen rendszer a CooCox CoOS is. Multiprogramozott operációs rendszer esetén egyszerre több munka feldolgozása zajlik. Ez a processzor jobb kihasználását tette lehetővé batch utasításokkal. Valósidejű operációs rendszerben minden rendszerhívás meghatározott időn belül le kell, hogy fusson. A többi operációs rendszerben nincsen ilyen időbeli megkötés.

3.2.1 Időosztásos operációs rendszer Az időosztásos operációs rendszer jelentése az, hogy a processzor meg van osztva egyszerre több, párhuzamosan dolgozó felhasználó között, azonban ők mindannyian úgy látják az erőforrást, mintha az teljesen csak az ő rendelkezésükre állna. „Ezért fontos elvárás, hogy a rendszer válaszideje értelmes tűréshatáron belül legyen.” [37] Ennek az időosztásos - 24 -

működésnek elengedhetetlen része, hogy az alapidőzítés megfelelő legyen. Ezt a SysTick timer szolgáltatja a Cortex-M3 processzoroknál. A SysTick egy egyszerű időzítő, amely a NVIC része a Cortex-M3 processzorokban. Eredeti célja, hogy egy valósidejű beágyazott operációs rendszer (RTOS) számára periodikus megszakítást küldjön, de más, egyszerű időzítési funkciókra is használható [38]. Indokok arra, hogy több folyamat legyen egy rendszerben:


hatékonyabb erőforrás-kihasználás




a feladat-végrehajtás gyorsítása




többféle feladat egyidejű végrehajtása




rendszerstrukturálás Aszinkron parancsindítás: a kezelő egy parancs indítását követően, még annak

befejeződése előtt újabb parancsokat adhat a rendszernek [39]. Szinkron működés esetén erre nincs lehetőség, meg kell várni az előző parancs végrehajtásának befejezését, mielőtt újabb parancs kiadható lenne [40].

3.2.2 A LM3S6965 időzítése Valósidejű operációs rendszer használatához elengedhetetlen az időzítés helyes beállítása. A Stellaris családba tartozó mikrokontrollerekben két fő órajel-forrás használata lehetséges [41]. Ezeket a 3.1. táblázat szemlélteti.

Fő oszcillátor (main) Belső oszcillátor (internal)

Belső óra meghajtása Igen Igen

Bootolásra képes Igen Nem

3.1. táblázat: Stellaris mikrokontrollerek órajel-forrásai.

Órajel előállításához először ki kell választani a bemeneti oszcillátort, amelyet alkalmazni szeretnénk. A további útvonal az osztók (SYSDIV, illetve PWMDIV) használatának megválasztásán múlik. Bemeneti oszcillátor lehet:


Fő oszcillátor kristállyal,

•

Fő oszcillátor óragenerátorral.

•

Belső oszcillátor.

- 25 -

Az osztók, amelyek használatával lehetőség van a kimeneti órajel beállítására:


SYSDIV (rendszerosztó)




PWMDIV (PWM osztó) Egy harmadik, állandó órajellel működő osztó működteti az ADC órát. Ennek a

megfelelő működési frekvenciájához szükséges a PLL használata. Van lehetőség a PLL megkerülésére, ez a BYPASS jel értékétől függ. Amennyiben a PLL használatban van, állandó 200MHz-es órajelet ad ki. Ezt a jelet a rendszerosztóval kombinálva kapjuk meg a rendszeróra jelét. A PWM modul inputjára vezetett órajel a fenti rendszerórából származik. Szükség esetén ennek a bemeneti jelnek a frekvenciája csökkenthető a PWM osztóval, mielőtt a PWM modulba ér. Az órajel útvonalát szemlélteti a 3.2. ábra:

3.2. ábra: Órajel útvonal ábrázolása a beállítási lehetőségekkel. Az a-val jelölt elemek az RCC (Run-Mode Clock Configuration) regiszterben állítható bitek. (Kép forrása: [41])

Az időzítés szerepe kulcsfontosságú az interruptok és a fájlrendszer működésének szabályozása szempontjából (lásd: 6.3. fejezet).

3.2.3 Interruptok A HTTP szerver program működése eseményvezérelt, ugyanis interruptokra épül. A rendszer inicializálása (az időzítés, a debug kimenet, a képernyő, az Ethernet vezérlő, az interruptok és a fájlrendszer, valamint az SSI-tagek beállítása után IP-cím kérése) után elindul a kiszolgáló. Ez lényegében egy egyszerű végtelen ciklus, amelyet időről-időre interruptok szakítanak meg, és ezeknek a megszakítás eseményeknek a kezelése valósítja meg a tulajdonképpeni szerver funkciót. (Egyszerűbb operációs rendszerek is hasonló elven - 26 -

működnek: a végtelen üres ciklus maga az operációs rendszer, és a működés valójában az interruptok kezelését jelenti.) A Stellaris mikrokontroller család felhasznált tagja 42 interrupt forrást, és 8 prioritási szintet támogat. Az Interrupt Controller API különböző függvényeket szolgáltat interruptok engedélyezésére, letiltására, prioritás beállítására és interrupt handlerek regisztrálására. Ezen metódusok segítségével vezérelhető a NVIC (Nested Vectored Interrupt Controller), amely az általános interruptkezelést végzi el (maszkolás, prioritáskezelés, a megfelelő handler feloldása) [42]. Az API elsődleges feladata, hogy kezelje az interruptvektor-táblát, amelyet a NVIC használ arra, hogy a megszakításkéréseket feloldja. Handler regisztrálása úgy lehetséges, hogy a kezelő függvény címét be kell szúrni ebbe a táblába.

- 27 -

4 Beágyazott rendszerek kommunikációja interneten Mivel a program mikrokontrolleren működik, nem elvárás, hogy nagyméretű médiafájlokat szolgáljon ki, sem az, hogy egyszerre sok kliens kapcsolódhasson hozzá. Nem igény a szerverrel szemben, hogy gyorsítótárazást (cache) tartalmazzon. A felhasználási területnek megfelelő keretek között kell működnie. A World-Wide Web 1990 óta használja a HTTP protokollt ([4] „Abstract” fejezete). Ennek implementálásához a HTTP szöveg feldolgozására és jól működő hálózati kommunikációra van szükség, amellyel küldeni és fogadni lehet a szöveges HTTP üzeneteket.

4.1 HTTP protokoll A HTTP a Hypertext Transfer Protocol kifejezés rövidítése. Legújabb verziója a HTTP/1.1, melyet az IETF 2616-os számú RFC-je definiál [4]. Elnevezésére az a magyarázat, hogy eredetileg hiperszövegek, azaz HTML nyelvű tartalmak továbbítására fejlesztették ki a CERN-ben [43]. Kliens-szerver alapú hálózatok kommunikációját teszi lehetővé, az internet is erre épül. A hálózat klienseket (ügyfelek) illetve szervereket (kiszolgálók) kapcsol össze. Kétfajta üzenet küldése lehetséges: kérésé vagy válaszé ([4] 4.1 fejezete). Ez a fejezet jelentős mértékben az Önálló laboratórium beszámoló című, korábban általam készített dolgozat vonatkozó részeire épül [44].

4.1.1 A HTTP helye a hálózati kommunikációs modell rétegeiben A hálózati kommunikáció szabványosítása lassú folyamat volt, de egy alapos előíráshoz vezetett, mely a hétrétegű OSI referencia modell néven vált ismertté. Ennek rétegei jól definiált interfészekkel kapcsolódnak egymáshoz, ezáltal lehetővé téve, hogy az egyes rétegek külön-külön teljesen lecserélhetővé váljanak, és a többi réteg működése zavartalan legyen. Ezek egészen alacsony szintről, a vezetékek és hardverek szintjétől a merevlemezeken tárolt adatokig épülnek egymásra (4.1. ábra). Adatküldéskor minden réteg becsomagolja egy újabb „dobozba” a felette levő rétegtől kapott csomagot, majd továbbadja az alatta levő rétegnek. Ezt a matrjoska-szerű többszörös csomagolást nevezzük enkapszulációnak [45]. Maga a csomagolás azt jelenti, hogy a fentről kapott csomag a továbbadandó csomag tartalmát (payload) fogja képezni, és az adott réteg ezt a saját fejlécével (header) látja el.

- 28 -

Adat fogadásakor ugyanezek a rétegek visszafelé dolgoznak: a szomszédos alsó rétegtől fogadott „dobozt” bontják ki, levéve róla a fejlécet, és a tartalmat a felső szomszédnak adják tovább.

4.1. ábra: A hétrétegű OSI modell. (Kép forrása: [46])

(Megjegyzés - 4.1. ábra: az egyes rétegek fizikai összeköttetése „függőleges” irányú, azonban a rétegek egymással „vízszintesen” is kommunikálnak, ezt nevezzük logikai kapcsolatnak.)

4.2. ábra: Az OSI modell és a TCP/IP protokollcsalád összehasonlítása. (Kép forrása: [46])

- 29 -

A referencia modell elég részletes, és átgondolt, azonban gyakorlati alkalmazása nem követi a specifikációt. Az ipar ugyanis nem várta meg, míg az OSI modell elhúzódó szabványosítása lezajlik, és azzal párhuzamosan kialakította a TCP/IP protokollcsaládot, amely nem minden réteget valósít meg a hétből, illetve néhányat közülük összevon [47]. A 4.2. ábra jól szemlélteti a két modell különbségeit. (Megjegyzés: a DoD a United States Department of Defense-t jelöli. Ez az USA Védelmi Minisztériuma, amelynek nagy szerepe volt a TCPI/IP protokollcsalád kifejlesztésében.)

4.1.2 HTTP üzenetek felépítése Egy HTTP üzenet kérés vagy válasz lehet, de mindkét változatnak hasonló a felépítése, mert az RFC 822 szabvány által meghatározott formátumot használják. Ez alapján az üzenet tartalma egy kezdő sorból (start-line), nulla, vagy több fejléc mezőből (header field), ezután a fejlécek végét jelző, kötelezően üres sorból (amelyben csakis a karakterek szerepelnek, előttük még úgynevezett whitespace karakter, mint szóköz vagy tabulátor sem lehet), és egy nem kötelező üzenettestből áll ([4] 4.1 fejezete). Az egyes fejléc mezők külön sorba kerülnek, amelyek karakterekkel zárulnak. Ezekből a mezőkből elég sokat definiál a 2616-os RFC, ezért nem férne bele jelen dokumentum kereteibe a részletes tárgyalásuk. A szerepük annyi, hogy a kérést módosíthatják, valamint a kiszolgálónak lehet a segítségükkel információkat eljuttatni a kliensről ([4] 5.3 fejezete). A HTTP/1.1 óta a kéréseknél kötelező mező a Host ([4] 14.23 fejezete).

4.1.2.1 Egy HTTP kérés felépítése Egy HTTP kérés struktúrája olyan, hogy a legelső sorba (start-line) a hívó metódus kerül. A kérés legelső sora <metódusnév> <erőforrás> alakú kell, hogy legyen ([4] 5.1 fejezete). Egy tipikus példa:

GET /index.html HTTP/1.1 A kliens itt a GET metódussal kéri meg a szervert, hogy küldje el neki az index.html fájlt, és megadja, hogy a kérése a HTTP/1.1 szabvány szerint épül fel. A HTTP szabvány részletesen tartalmazza, hogy milyen metódusokat tartalmazhatnak a lekérések, milyen kulcs: érték párok szerepelhetnek a kérés fejlécében, valamint hogy melyikre milyen válaszokat küldhet egy szerver a kliensnek. A következőkben ezeket ismertetem.

- 30 -

4.1.2.1.1 HTTP metódusok Az RCF2616 ajánlás az alábbi nyolc metódust ([4] 5.1.1 fejezete) definiálja (ezek csoportosítását a 4.1.2.1.2. és 4.1.2.1.3. fejezetben mutatom be): OPTIONS: Az adott URL-re vonatkozó, a szerver által támogatott HTTP–kérések listáját adja vissza. GET: Ez a leggyakrabban alkalmazott metódus, a megjelölt erőforrás elküldését kezdeményezi ezzel a kliens. HEAD: Ez a kérés egyetlen pontot kivéve megegyezik a GET metódussal: ilyen üzenetben tilos üzenettestet küldeni, mindössze a státusz sort, és a fejléc többi részét szabad válaszként a kliensnek eljuttatni. POST: Ez a metódus feldolgozandó adatot is küld a szervernek az üzenettestben. Tipikusan HTML űrlapokon használják, de adatbázis-kapcsolattal rendelkező szervereken is gyakori (például termék azonosítója szerepel az URL-ben). PUT: A megjelölt erőforrást a kliensről feltölti a szerverre. Megjegyzendő, hogy csak egész fájl feltöltését támogatja. DELETE: Törli a megadott erőforrást a szerveren, azonban a törlés felülírható; ezért a kliens számára semmi sem garantálja, hogy – akár sikeres válasz esetén is – a kiszolgálón fájlrendszer szinten törölve lett az adott erőforrás. TRACE: A kliens ezzel a metódussal olyan kérést indít el, amely a szerveren egészen az alkalmazási rétegig jut el, majd onnan „visszaverődik” egy 200 OK státuszú üzenet testeként. Ennek segítségével a kliens diagnosztizálhatja, hogy az általa elküldött üzenetből mi érkezik meg végül az ellenoldalra. Erre az enkapszuláció miatt van lehetőség, ugyanis a protokollrétegek mindegyike hozzáadja az üzenethez a saját fejlécét, annak belseje így változatlan marad. CONNECT: Fenntartva arra, hogy proxyval lehessen használni, például SSL tunneling esetén (azaz titkosított kapcsolat kiépítésére nem titkosított szerveren keresztül) ([4] 9.9 fejezete).

4.1.2.1.2 Biztonságos metódusok Biztonságos alatt az értendő, hogy az ebbe a csoportba tartozó kérések nem módosíthatják (jelentősen) sem a szerver, sem a kliens állapotát, nem lehetnek jelentős mellékhatásai. Ide sorolhatók a GET és a HEAD ([4] 9.1.1 fejezete). Nem tekinthetők azonban biztonságosnak a POST, PUT, DELETE, hiszen ezek kimondottan arra irányulnak, hogy erőforrásokat hozzanak létre, módosítsanak, töröljenek.

- 31 -

4.1.2.1.3 Idempotens metódusok Ide a GET, HEAD, PUT és DELETE kérések tartoznak. Közös tulajdonságuk, hogy (bizonyos lejárati időn belül, és az esetleges hibaüzenetektől eltekintve) egyetlen lekérés mellékhatásai ugyanolyanok, mintha a kliens sok ugyanolyan lekérést hajt végre. Mivel az OPTIONS és TRACE metódusoknak eleve tilos mellékhatást kifejteniük, őket is ide soroljuk ([4] 9.1.2 fejezete). Megjegyzem, hogy a POST eljárást kifejezetten arra használják, hogy az egyes lekéréseket különböző adatokkal kiegészítve lehessen a szervernek elküldeni, ezért ez nem idempotens.

4.1.2.2 HTTP válaszüzenet státuszkódjai A HTTP kérés és válasz típusú üzenetek közötti lényeges eltérés csupán az első sorban van, ugyanis itt nem metódusok, hanem státuszt jelző kódok szerepelnek. A webszerver a beérkezett HTTP kérésre a válasz első sorában egy három számjegyű státusz kódot küld a kliensnek. Ezeket az első számjegy alapján csoportokba soroljuk, melyek a következők ([4] 6.1.1 fejezete): 1xx: Informatív válasz. Csak kísérleti környezetben használható. Azt jelzi, hogy a szerver megkapta a kérést. 2xx: Siker. A kettes számmal kezdődő kód azt jelzi, hogy a kérés sikeresen megérkezett, valamint értelmezésre, elfogadásra és feldolgozásra került. 3xx: Átirányítás. Az ilyen kód jelentése, hogy a kérés teljesítéséhez a kliensnek további teendőket kell végrehajtania. 4xx: Kliens hiba. A sikertelenséget okozhatja hibás vagy teljesíthetetlen kérés. 5xx: Szerverhiba. Ilyen eset akkor fordul elő, ha egy egyébként teljesen érvényes kérést valamilyen okból a szerver nem képes kiszolgálni. Az alábbiakban néhány gyakori válaszkódon szemléltetem a fenti csoportosítást. 200 OK: A kérés kiszolgálása sikeres. Ez a leggyakrabban előforduló státuszkód, hiszen normál működést jelez. 301 MOVED PERMANENTLY: „Elköltözött”. Ezzel a kéréssel kezdődően a további ide irányuló kéréseket is az adott URI-ra kell átirányítani. 403 FORBIDDEN: Tiltva. A szerver visszautasítja a hozzáférést a kívánt erőforráshoz – és ekkor (az esetleges autentikációtól függetlenül) tiltja a hozzáférést.

- 32 -

404 NOT FOUND: Nem található. Az elérni kívánt erőforrás jelenleg nem elérhető (de ez nem jelenti azt, hogy ez a későbbiekben is így lesz). 500 INTERNAL SERVER ERROR: Belső kiszolgálóhiba. Ez általános hibaüzenet. 503 SERVICE UNAVAILABLE: A kiszolgáló nem elérhető - általában túlterhelés, vagy karbantartás miatt.

4.2 A HTML dinamikus kiterjesztése Az önmagában csupán statikus HTML-ben rejlő lehetőségeket a 2.2.1.3. fejezetben már ismertettem, ebben a fejezetben pedig azt mutatom be, hogy a HTML a dinamikus kiterjesztése hogyan növeli őket tovább. A HTTP szerver programban a kiterjesztés az SSI (Server-Side Includes) technika alapján történt. Ennek lényege, hogy a HTML szövegben speciális jelölést (tag) helyeznek el, amelyet a szerver feldolgoz, mielőtt a fájlt elküldené a kliensnek. Ha a feldolgozás során valamilyen hiba történt, vagy a szerver nem ismeri fel, akkor a tagek egyszerű HTML megjegyzésként viselkednek. Az elterjedt Apache szerver program által megvalósított változatban [48] ezek a jelölések nem maradnak benne a HTML fájlban, és különböző direktívákkal paraméterezni lehet őket. A HTTP szerver program eltér ettől: az SSI címkék nem paraméterezhetőek és a jelölések benne maradnak a válaszként elküldött fájlban, de közvetlenül utánuk kerül beszúrásra a feldolgozás eredményeként kapott karaktersorozat. Az implementációról még írok a 6.4. fejezetben.

4.3 Az LM3S6965 hálózati kommunikációja A TCP/IP protokollcsaládot megvalósító LwIP könyvtár nem tartalmazza az adatkapcsolati rétegbe tartozó Ethernet vezérlését, azonban erre nincsen szükség, hiszen a Stellaris LM3S6965 elvégzi az Ethernet működéséhez szükséges feladatokat. (Erről bővebben: lásd 2.1.4. fejezet.) Az én mikrokontroller példányom fizikai címe: 00:1A:B6:00:0B:A3. Az interneten található számos weboldal, ahol fizikai cím alapján listázható az eszköz gyártója. A 00:1A:B6 kód a Texas Instruments-t jelöli, és mivel a Stellaris LM3S6965 alaplap gyártója a Texas Instruments, ezért ez nem váratlan eredmény. A hardver lehetőséget ad arra, hogy a fizikai címet átprogramozzam, de én nem éltem vele a fejlesztés során.

- 33 -

5 Tervezés A feladathoz hardver eszköz adott. Kézenfekvő megoldás hozzá a saját gyártója, a Texas Instruments által kiadott programkönyvtárat és perifériaillesztőket használni: ez a StellarisWare programcsomag. A megvalósítás indulásakor van egy µVision környezetben, operációs rendszer nélkül működő, minimális funkcionalitású HTTP szerver, amely szinte semmiben nem tér el a StellarisWare példaprogramjától. Ezt kell átalakítanom úgy, hogy a MicroSD kártyát használja tárhelynek, és a CoOS operációs rendszer által futtatható HTTP modul legyen. Ami jó, azt megtartom belőle: az LwIP TCP/IP megvalósítás és a FatFs fájlrendszerkezelő, valamint a MicroSD kártya illesztője marad a CooCox környezetre adaptált programban is. A mikrokontrollert vezérlő fájlokat azonban a CooCox moduljaiból veszem át (lásd: 5.4.2. fejezet) és a HTTP-t dinamikussá teszem, mivel ez is elvárás a programmal szemben, és a régi verzió ezt sem tudja. A célom az, hogy a HTTP szerver megfelelően működjön, tudja kezelni a hálózati kapcsolatokat, a beérkező kérésekre a kliens számára feldolgozható választ küldjön. A feladatom nem foglalja magába, hogy teljesen önálló CoOS modulként készítsem el a HTTP szervert, de elő kell készítenem a programot arra, hogy minél könnyebben megvalósulhasson ez a hosszútávú cél. Amikor ezt az állapotot eléri a szerver fejlesztése, akkor a TCP/IP modul már nem lesz közvetlenül a HTTP szerver része, hanem az operációs rendszeren kereszül fogja elérni a hálózatot. Erre azért van szükség, hogy a CoOS által futtatott többi önálló modul (például a TFTP, amely a program frissítését fogja elvégezni) is hozzáférjen a hálózathoz. A következő fejezetben bemutatom az indokokat, amelyek alapján eldőlt, hogy szükség lesz operációs rendszerre hosszú távon. majd pedig ismertetem a döntés szempontjait és eredményét.

5.1 Igény egy operációs rendszerre A Keil uVision [49] IDE-t a fejlesztés legelején a StellarisWare könyvtár megismeréséhez használtam, és a HTTP szerver első működő változatát ebben készítettem. A feladat hosszútávú célkitűzései miatt (önálló HTTP szerver modul, amely mellett más modulok is működhetnek) azonban egy operációs rendszerre van szükség. (Ennek kiválasztását az 5.2. fejezetben ismertetem. A döntés után a HTTP szervert úgy fejlesztettem tovább, hogy a CooCox CoOS operációs rendszerrel lehessen használni.)

- 34 -

A feladat hosszútávú megoldásával szemben elvárás, hogy a HTTP szerver mellett más programok is futtathatók legyenek a LM3S6965 mikrokontrolleren, és fordítva: a szerver is legyen képes más programokkal egyszerre futni. Így a mikrokontroller alkalmassá tehető a képességeit sokkal jobban kihasználó feladatok ellátására. Ehhez az egymás melletti futáshoz arra van szükség, hogy egy időosztásos operációs rendszer futtassa mind a HTTP szervert, mind az egyéb programokat. Első látásra kézenfekvőnek tűnik a Windows Mobile, vagy Android operációs rendszer használata, azonban ezeket az operációs rendszereket úgy tervezték, hogy nagyméretű kijelzők vezérlését tegyék lehetővé. A Stellaris mikrokontrollerre szánt HTTP szerverhez azonban erre nincsen szükség: az alaplapra integrált OLED kijelző [50] egy 128x96 pixeles, 16 színárnyalatú egység. Ugyanakkor szükség van operációs rendszeri funkciókra, például taszk ütemezésre, hiszen lehetőséget szeretnék adni arra, hogy a szerver párhuzamosan fusson más programokkal, például egy TFTP szerverrel.

5.2 A CooCox CoOS operációs rendszer kiválasztása A leendő operációs rendszerrel kapcsolatban a következő lehetőségek jöhettek szóba:

•

Létező mikrokontroller operációs rendszer megvétele: sajnos ez az opció túl nagy anyagi vonzattal járt volna.

•

Saját operációs rendszer írása: ez a feladat túlzottan összetett és időigényes feladat lenne, ezért ezt elvetettem.

•

Létező, ingyenes, jól működő operációs rendszert kell találni, és ha szükséges, akkor átalakítani. Ebben az irányban folytattam a kiválasztást. Vázolom az érveket, amelyek mentén a CooCox CoOS operációs rendszere mellett

döntöttem. Olyan valósidejű, beágyazott, időosztásos operációs rendszert kerestem, amely ingyenesen elérhető, nyílt forráskódú, kicsi és gyors, jól dokumentált, támogatja a LM3S6965 mikrokontrollert és lehetőleg van hozzá ingyenes fejlesztőkörnyezet. Potenciális választásként az alábbiak álltak előttem (2011. márciusában, a döntés meghozatalakor): eCosPro Developer’s Kit [51]. Alaposan tesztelt, Eclipse-alapú IDE-vel és minden egyéb segédprogrammal ellátott, és erős support-tal kínált csomag. Nemcsak Microsoft Windowsra, hanem Linux platformra is elérhető. Létezik nyílt változata is.

- 35 -

RTOS ThreadX [52]. A teljes ARM skálát támogatja, kiterjedt eszköztárral bír, minimális kernelmérete 2kByte alatt van. Sajnos azonban fizetős, ezért minden előnye ellenére kiesik a számomra elérhető eszközök közül. SMXRTOS [53]. Ez egy moduláris, valós idejű operációs rendszer. Sajnos nem támogatja a Luminary Micro LM3S6xxx sorozatból a memóriakártyát, ráadásul fizetős is, így ezt sem választom. FreeRTOS [54]. Sok architektúrát támogat, és tartalmaz execution trace funkciót is, a kernel mérete tipikusan 4-9kByte között van. Ingyenes, de a dokumentációjáért fizetni kellene, ami kizárja a használatát. Linux-alapú RTOS mikrokontroller operációs rendszerek. Találtam egy uClinux nevű Linux operációs rendszert [55], azonban ez még csak ARM7TDMI processzorra van portolva, és az LM3S6569–ben nem ilyen van [56]. Egy ilyen portolás végrehajtása túl komplex feladat lenne időben és méretben, ezért nem vállalkozom rá (ráadásul a portolással kapcsolatos információkról megadott link nem is működött az oldalon). CooCox CoOS [57]: Beágyazott, valósidejű, időosztásos operációs rendszer, kifejezetten az ARM Cortex M sorozatba tartozó eszközökhöz (lásd még: 5.3. fejezet). Az 5.1. Táblázat összesítve mutatja a választás szempontjait. Ingyenes?

Támogatja-e az eszközt

eCosPro Developer’s Kit RTOS ThreadX

Nem Nem

SMXRTOS

Nem

FreeRTOS

A dokumentáció nem

uClinux

Igen

CooCox CoOS

Igen

Memóriakártya használatát nem támogatja Portolni kellene Cortex-M3 processzorra Igen

5.1. Táblázat: Operációs rendszer választási szempontjai.

Konzulensem, Tihanyi Attila tanár úr ajánlása alapján és a fentiek fényében a CooCox CoOS-t választottam. Ez megfelel a fenti igényeknek, ingyenes, nyílt forrású, kicsi, jól dokumentált rendszer.

5.3 A CooCox CoOS tulajdonságai A CooCox CoOS [57] egy ingyenes és nyílt, valós idejű, multitaszk, beágyazott operációs rendszer és kifejezetten az ARM Cortex M sorozatú mikrokontrollereihez kezdte el

- 36 -

fejleszteni a kínai Wuhan Műszaki Egyetem. A Texas Instruments Stellaris LM3S6965 mikrokontrollert is támogatja. Skálázható, a minimális kernel mérte 1kByte alatt van. Adaptív feladatütemező algoritmust használ, preemptív prioritásos, illetve round-robin ütemezést is támogat [58]. Az interruptok késleltetése közelítőleg 0ms. Stack túlcsorduláskezelés is szerepel a tulajdonságai között. Támogatja az ICCARM, ARMCC, GCC platformokat. Szemaforok, flagek, kölcsönös kizárás, és üzenetküldés állnak rendelkezésre a kommunikáció és szinkronizáció végrehajtásához. Példakódokkal [59] és dokumentációval is ellátták, ami segíti a használatát. Saját fejlesztőkörnyezet, a CooCox CoIDE [60] is elérhető ehhez az operációs rendszerhez. A fejlesztés során ezzel dolgoztam.

5.4 A CooCox CoIDE fejlesztőkörnyezet A

CooCox

CoIDE

[60]

Eclipse-alapú,

keresztfordítót

tartalmazó

integrált

fejlesztőeszköz. Ez számomra előny, hiszen az Eclipse jól használható, elterjedt, sok programozási nyelvhez létezik olyan fejlesztőkörnyezet, ami ráépül, magam is több változatát használtam már. BSD licenccel, ingyenesen használható [61], szoftver, Microsoft Windows platformra érhető el. Fejlesztése folyamatos, több verziófrissítés is történt [62], mialatt a HTTP szerver programon dolgoztam. A CooCox programokat folyamatosan frissítik, időrőlidőre megjelennek újabb verziók. A frissítés automatikussá tétele érdekében használom a CoCenter [63] programot. Ez kijelzi, illetve igény szerint letölti, és telepíti is az újonnan kiadott változatokat. A CooCox CoIDE szemlélete alacsony szintű, moduláris projektfelépítést tesz lehetővé, kód szinten támogatja a fejlesztőt - ellentétben az általam korábban használt µVision-nel, amely a StellarisWare-t library szinten, egyben használja fel, megnehezítve így a felhasznált kód testreszabását. Paradox módon a moduláris felépítés okozta a feladatom megvalósításásak nehézségét is, mivel a korábban más fejlesztőeszközzel, más struktúrában felépített, más logikájú programot kellett átültetnem ebbe a környezetbe. Egy projekt létrehozása a CooCox-ban: a mikrokontroller gyártó és az eszközcsalád meghatározása után kell a lehetséges modulok közül kiválasztani azokat, amelyekre szükség van a projektben. A projekt adatai XML-ben vannak eltárolva.

5.4.1 Kapcsolat a hardverrel Különösen fontos, hogy a CoIDE támogatja a feladat eszközéül szolgáló Stellaris LM3S6965 típusú alaplapot. Lehetőséget ad arra is, hogy közvetlenül állítani lehessen a periféria tulajdonságokat. Az IDE-be integrálták a CoBuildert [64]. Debug-olást is lehetővé

- 37 -

tesz, módot ad lépésenkénti futtatásra a CoDebugger [65] révén. Példakódok és dokumentáció is elérhető hozzá [57]. A korábbi verziókban még az elterjedt GCC fordító is benne volt. Jelenleg ez nem része a telepítőnek, de továbbra is ezt ajánlják használatra. A lefordított programot a mikrokontroller flash memóriájába a CooCox CoFlash-sel [67] lehet feltölteni. Ez felismeri az alaplapra integrált hardveres debug interfészt, ezért nem kellett sem fizikai debugger eszközt építeni, sem egyéb debug függőséget feltelepíteni hozzá. A CoIDE támogatja a JTAG (Joint Test Action Group) debug módszert [68], amelyet az alaplap USB csatlakozóján keresztül én is használok fejlesztés közben. A debug beállítási lehetőségek [69] többféle reset módot és különböző nézeteket rejtenek [70].

5.4.2 A CoIDE v1.4.1-ben felhasznált modulok Ahogy a CooCox verziók frissültek, úgy változott a Repository (a felhasználható modulok gyűjtőhelye) szerkezete, és így a felhasznált modulok is. Az utóbbi néhány CooCox verzióban azonban már nem történtek nagyobb változtatások. A HTTP szerver program jelenlegi változata az 1.4.1 verziójú CoIDE-ből az alábbi CooCox modulokat használja fel (5.1. ábra):

5.1. ábra: CooCox CoIDE v1.4.1 Repository: komponens nézet a perifériák használatához rendelkezésre álló modulokkal.

- 38 -

A modulok részben egymásra épülnek. Az egymás közötti függőségeket az 5.2. ábra mutatja be.

5.2. ábra: A modulok függőségi diagramja (CoIDE v1.4.1).

5.4.2.1 COMMON könyvtár A program aktuális változata csak egy modult használ innen. CMSIS Core A perifériák elérését lehetővé tevő adatstruktúrákat tartalmaz (CMSIS: Cortex Microcontroller Software Interface Standard). A core_cm3.h a Cortex-M3 belső perifériáinak adatstruktúráit írja le, és a címfordítást végzi ezekhez. Alapszintű elérést is biztosít a Cortex-M3 belső regisztereihez és perifériáihoz, hatékony függvények segítéségével. A core_cm3.c fájlban különböző segédfüggvények vannak, amelyek a processzor regisztereit érik el [71].

- 39 -

5.4.2.2 BOOT könyvtár Innen felhasználtam mindkét modult. cmsis_boot Az LM3S sorozat CMSIS boot komponense. Meghatározza az aktuális eszközhöz tartozó perifériákat, tartalmazza az indítási, valamint a teljes interrupt vektortáblát. Eszközspecifikus beállításokat juttat érvényre és inicializálja az oszcillátort [72]. BOOTLOADER Indításhoz szükséges definíciókat tartalmaz LM3S sorozatú eszközökre fejlesztett projektek számára. Ebben a modulban kap helyet a minimális Cortex M3 vektortábla és az alapértelmezett handler függvények [73].

5.4.2.3 PERIPHERAL.LUMINARY könyvtár Az innen felhasznált modulok: CPU A három fő utasítás csomagolófüggvényeit tartalmazza: interruptok engedélyezését (CPSIE) és tiltását (CPSID), valamint az interruptra való várakozást (WFI) [74]. LOWLAYER Ez a többi modul alacsony szintű függőségeként került be a projektbe [75]. INTERRUPT Interruptvezérlő. Az interrupt API függvényeket szolgáltat az egymásba ágyazott vektoros interruptkezeléshez (NVIC). Az NVIC globális interruptmaszkolást, prioritás-, és interruptkezelést tesz lehetővé. (A Stellaris család fejlesztés során használt tagja 42 interruptforrást és 8 prioritási szintet támogat [50].) A következő funkciók megvalósítására szolgáló függvények találhatók itt: interruptok engedélyezése/tiltása, interrupt handlerek kezelése, interrupt prioritásának beállítása [76]. SYSCTL Ez a rendszervezérlő határozza meg az eszköz általános működését. Szabályozza az órajelet, az engedélyezett perifériákat, az eszköz beállításait, és újraindítási módjait, valamint információt szolgáltat az eszközről [77].

- 40 -

6 Implementáció végrehajtása A megvalósítási folyamat első fontosabb mérföldköve az volt, amikor a StellarisWarealapú HTTP szerver program első változatát sikeresen működésre bírtam. Ekkor még Keil µVision [49] fejlesztőeszközzel dolgoztam, és a szerveren a böngészőből elérhető tartalmak a LM3S6965 flash memóriájában kerültek tárolásra. Ez nemcsak kicsi volt, hanem a tartalom módosításakor minden esetben el kellett végezni egy kompilálási műveletet is. A második nagyobb mérföldkövet akkor értem el, amikor az operációs rendszer igénye miatt (lásd: 5.2. fejezet) a µVision-ről CooCox környezetre tértem át, és ott újra beüzemeltem a szervert, immár a CooCox moduljainak használatával, ehhez az időzítést is be kellett állítanom. Következő fontos lépésként a tartalom megjelenítését fejlesztettem: a rendszer most már képes használni a memóriakártyát, így sokkal nagyobb mennyiségű tartalom szolgáltatható, valamint a fájlok módosítása is közvetlenül lehetséges. Az utolsó lépés az eddig csupán statikus tartalmak kiszolgálására képes szerver dinamikus megjelenítésre való képességgel való felvértezése volt SSI segítségével. A HTTP szerver programjának főbb egységei: az LwIP TCP/IP stack implementáció, a FatFs fájlrendszer implementáció (lásd: 2.2.2. fejezet), a MicroSD memóriakártya-kezelő (lásd: 2.1.5. fejezet), valamint a CooCox programkönyvtáraiból felhasznált modulok (lásd: 5.4.2. fejezet). A kód alapvetően a Texas Instruments által készített StellarisWare könyvtárra épül. Munkámat könnyítette, hogy az alkalmazott alrendszerek többsége mások által is kipróbált és használt kód. A memóriakártya illesztőjét és a FatFs modult módosítások nélkül használtam fel, ezért ezekre nem térek ki. A programban a StellarisWare nyomán az LwIP-t alkalmaztam a TCP/IP protokollcsalád és a HTTP megvalósítására. A StellarisWare programcsomagjában enet_lwip– nek nevezik az Ethernet-alapú hálózatkezelés példa projektjét.

6.1 Enet_lwip használata HTTP szerver megvalósítására Ebben a fejezetben a httpd.c fájl alapján bemutatom a HTTP szerver működését, mely az alkalmazási rétegbe tartozik. A HTTP kapcsolatok kezeléséhez szükséges definíciók között vannak a HTTP fejlécek küldésénél használt tHTTPHeader adatstruktúra, és a g_psHTTPHeaderStrings tömb,

- 41 -

amely a kliensnek küldendő válaszba kerülő fejlécek generálásához kell. A HTTP kapcsolat állapotainak kezeléséhet az LwIP a http_state adatstruktúrát alkalmazza. A szerver által felismert fájltípusok a g_psHTTPHeaders tömbben vannak felsorolva. Ezek jelenleg: .html, .htm, .shtml, .shtm, .ssi, .gif, .png, .jpg, .bmp, .ico, .class, .cls, .js, .ram, .css, .swf, .xml. (A fájlok kiterjesztését a t_http_headers függvány vizsgálja.) Az SSI kiterjesztéssel kapcsolatos beállítások is szerepelnek a fájlban. A szerver a g_pcSSIExtensions tömbben meghatározott fájltípusokban (.shtml, .shtm, .ssi) vizsgálja SSI címkék meglétét. Az SSI tagfeldolgozás állapotait a tag_check_state felsorolási (enum) típus határozza meg. Az SSI utasítások jelölésének bevezető és lezáró része is módosítható, ha szükséges. A programban most az Apache webszerver által is használt karaktersorozatokat alkalmazom. SSI utasítás bevezető része: . (Több SSI-vel kapcsolatos beállítás a 6.4. fejezetben olvasható.) Ha a kliens a tartalom gyökérkönyvtárát kéri le (GET / kérést küld), akkor a kérése nem tartalmaz fájlnevet. Ekkor a szervernek meg kell határoznia, hogy az alapértelmezésben megjelenítendő (index) fájlnak mi a pontos neve. A g_psDefaultFilenames tömb határozza meg a sorrendet, amely alapján a szerver keresi ezt a fájlt. Ez jelenleg a következő: /index.shtml -> /index.ssi -> /index.shtm -> /index.html -> /index.htm . A http_recv függvény végzi el ezt a vizsgálatot. Ha egyik névvel sem talál fájlt a memóriakártyán, akkor 404-es HTTP státuszt ad vissza válaszként. A HTTP szervert megvalósító függvények: conn_err: Ez a függvény végzi el a szükséges módosításokat a HTTP állapotát kezelő struktúrában, valamint ha meg van nyitva egy fájl, akkor bezárja azt és felszabadítja a puffert, továbbá elvégzi a lehetséges memóriafelszabadítást. A http_accept függvény állítja be a tcp_err függvénypointerben, hogy kapcsolati hiba esetén hívja meg ezt a függvényt. close_conn: Lezárja a kapcsolatot. Ha nyitva van egy fájl, akkor bezárja, valamint felszabadítja a memóriát. Hívása lehetséges a send_data és a http_recv függvényekből. get_tag_insert: Ez a függvény hívja meg az SSI utasításra a hozzá megszabott handler függvényt. A send_data függvény hívja meg, amikor a HTTP válasz küldés előtti feldolgozása során eléri egy felismert SSI tag lezáró részét. Ha az SSI tag nem felismerhető, vagy kezelése sikertelen, akkor a következő sztring kerül beszúrásra a HTML fájlba: ”***unknown tag***”. - 42 -

get_httpd_headers: A paraméterként megadott fájlhoz a HTTP válaszhoz szükséges HTTP fejlécek generálását és kimeneti pufferbe írását végzi el. A http_recv függvény hívja meg. send_data: Élő HTTP kapcsolat esetén a HTTP válaszüzenet küldését végzi. A fejléceket, majd a fájl beolvasott blokkjait küldi el, pufferelve. Szükség esetén az SSI utasítások kezelése is megtörténik. A http_poll, http_sent és http_recv függvények hívják meg. http_poll: Élő kapcsolat esetén, ha már érkezett GET HTTP kérés és meg van nyitva egy fájl küldésre, akkor meghívja rá a send_data függvényt. A http_accept függvényből kerül sor a meghívására. http_sent: Akkor kerül meghívásra (a tcp_sent függvénypointer segítségével), ha a TCP kapcsolat ellenoldalára sikeresen megérkeztek az adatok. A http_recv függvényből kerül meghívásra. get_404_file: Megpróbálja beállítani a /404.html-re vagy ennek hiányában a /404.htm-re a kliensnek küldendő HTTP válasz URL-jét. Ha egyik sem létezik, akkor NULL–ra állítja a fájl URL-t, így jelzi a hívó http_recv függvénynek, hogy az alapértelmezett HTTP 404 státuszt küldje válaszként. http_recv: Ez a függvény kezeli a HTTP GET kérés fogadását. Jelzi a TCP kapcsolat másik résztvevőjének, amikor megkapta a kérést. Kezeli azt az esetet, ha a kliens a gyökérkönyvtárat kérte le, vagy nem található a kért fájl és szükség esetén az SSI tagek kezelését

is

engedélyezi.

Előállítja

a

válaszhoz

a

küldendő

fejléceket

a

get_http_headers meghívásával, majd beállítja a http_sent függvénypointert, ezután pedig megkezdi a válasz küldését a send_data segítségével. A http_accept hívja. http_accept: Kiépíti a HTTP kapcsolatot, inicializálja a HTTP állapotát kezelő adatstruktúrát. Beállítja a http_recv és http_err függvénypointert, majd a http_poll hívásával elindítja az adatküldést (amennyiben már érkezett HTTP GET kérés). A http_init függvényben kerül meghívásra a tcp_accept függvénypointeren keresztül. httpd_init: Az enet_lwip.c main függvényéből kerül meghívásra, ez indítja el a tulajdonképpeni HTTP szervert. Lefoglalja a 80-as TCP portot a tcp_bind meghívásával, ezen fogja várni a beérkező adatcsomagokat a szerver (tcp_listen hívás). Az inicializálás végén a tcp_accept függvénypointeren keresztül meghívja a http_accept függvényt.

- 43 -

http_set_ssi_handler: Ez a függvény inicializálja az SSI utasítások kezelését. Az SSI tagek és handlereik hozzárendelésével (bővebben lásd: 6.4. fejezet). Az enet_lwip.c main függvénye hívja meg a HTTP szerver indításakor. Az enet_lwip a HTTP/1.0 protokollt alkalmazza, melyet az 1945-ös számú RFC [78] definiál. Ez régebbi, és némileg egyszerűbb a HTTP/1.1 –nél. A verziók közötti különbségeket megvizsgálom a feladat szempontjából: A HTTP/1.1 –ben új metódus az OPTIONS [79]. Ez nem lényeges, mivel a szerver program csak GET metódusokat szolgál ki. Sávszélesség optimalizálása: a HTTP/1.1 már tudja kezelni, ha a kliens egy nagyobb fájlnak csak egy részét kéri elküldésre [80]. A mikrokontrolleres program a felhasználás jellege miatt elsődlegesen nem nagyméretű fájlokat fog kiszolgálni, ezért ez nem elég indok a HTTP/1.1 használatára. Hálózati kapcsolatok kezelése: az eredeti HTTP minden fájlhoz külön TCP kapcsolat felépítését igényelte, az új azonban a pipelining segítségével és perzisztens (tartós) TCP kapcsolatokkal sok TCP kapcsolatfelépítést megspórol [81]. Ez mind időben, mind sávszélességben előnyös. Ez a tulajdonság szintén a beágyazott környezet miatt jelent túl nagy költséget az esetleges előnyökkel szemben a megvalósítás terén. Üzenetátvitel: az üzenet címzettjének tudnia kell, hogy milyen hosszú az üzenet. Mivel azonban az üzenetek dinamikus elemeket is tartalmazhatnak (a HTTP szerver programban az SSI utasítások ilyenek), ezért a szervernek az egész választ pufferelnie kell a küldés során, hogy meg tudja adni a válasz hosszát a kliensnek a Content-length fejlécben. Mivel a HTTP/1.0 nem használ perzisztens kapcsolatot, ezért a küldés végeztével egyszerűen lezárja a TCP kapcsolatot [82]. Mivel a mikrokontrolleres környezetben és a várható felhasználás során elsősorban kisméretű tartalmakkal kell operálnia a szervernek, ezért a pufferelés nem jelent gondot. A tesztelés során sem tapasztaltam ebből adódó problémát. Internetcímek megőrzése: a HTTP/1.0 kérései nem kezelik a kérés hoszt név részét – ezért nem lehet egy IP-címhez több domaint rendelni [83]. Ez a várható felhasználás során szintén nem lesz szempont, de egyébként nem lenne gazdaságos külön domainnevet vásárolni és fenntartani egy mikrokontrolleres eszköznek. A használata életszerűbb közvetlenül IP-cím alapján.

- 44 -

A HTTP természetesen felfelé kompatibilis, tehát a HTTP/1.1 –et használó kliensek, illetve hálózati csomópontok értelmezni tudják a HTTP/1.0 üzeneteket is. Mivel beágyazott rendszerre írt programról van szó, elégséges a HTTP/1.0 használata.

6.2 Interruptok kezelése A HTTP szerver programban két saját interruptkezelő kerül felhasználásra [84]. Ezeket a handlereket úgy regisztráltam, hogy az interruptvektort kezelő táblában (helye: cmsisboot/startup/startup_lm3s.c) #pragma

weak módosítóval definiált

alapértelmezett handlereket a program kódjában felülírtam. A #pragma weak jelölés erre lehetőséget ad, azt jelzi a linkernek, hogy ha az itt definiált szimbólumot valahol a programban újra definiálják, akkor a gyenge definíciót írja felül az ottani erőssel.

6.2.1 SysTick interrupt Itt valósul meg a HTTP kérések kiszolgálása. A handler neve: SysTick_Handler Definíció helye: enet_lwip.c Funkció:

kezeli

a

rendszer

léptetését.

A

jelenlegi

konfigurációban

10

milliszekundumonként (azaz a beállított 100Hz-es frekvenciával, lásd 3.2.2. fejezet) hívja meg az LwIP időzítő handlerét, valamint a fájlrendszer tick handlerét.

6.2.2 Ethernet interrupt Itt valósul meg a szerver IP-címkérése, és a kapott cím beállítása a szerver indításakor. A handler neve: Ethernet_IRQHandler Definíció helye: lm3slib/utils/lwiplib.c Funkció: Az LwIP TCP/IP stackjének megszakításait kezeli. A beérkezett packeteket sorba fűzi, hogy feldolgozhatók legyenek a magasabb szinten (lásd: OSI modell rétegei); a kimenő sorból pedig kiküldi a megfelelő packeteket a megfelelő MAC címre. Ezen kívül – mivel a HTTP szerver jelenleg még önmagában, operációs rendszer nélkül fut a mikrokontrolleren – az LwIP periodikus időzítését is kezeli. Ez

utóbbi

az

lwIPHostTimerHandler

lwIPServiceTimers függvényen keresztül.

- 45 -

függvény

meghívását

jelenti

a

6.3 A PLL és az alapidőzítés beállítása a programban Ez a fejezet a 3.2.2. fejezetben ismertetett időzítő rendszer beállítását mutatja be. A PLL kétféleképpen állítható: közvetlenül a regiszterek írásával, illetve a Driver Library segítségével. Közvetlen írásnál az RCC regiszter tartalmát kell módosítani. Ez az 3.2. ábra a –val jelölt bitjeinek változtatását jelenti. Driver Library használata esetén a PLL beállítása a SysCtlClockSet függvény megfelelően felparaméterezett hívásával valósítható meg. A HTTP szerver programjában a Driver Library segítségével történik a PLL konfigurálása, az alábbi kódrészlet segítségével (6.1. ábra):

6.1. ábra: PLL beállítása a HTTP szerver inicializálásakor.

A SysCtlClockSet függvény a lm3slib/driverlib/sysctl.c fájlban található, paraméterei pedig a lm3slib/driverlib/sysctl.h fájlban meghatározott értékek lehetnek. A paraméterek jelentése: SYSCTL_SYSDIV_1: A processzor órajele: oszcillátor/PLL SYSCTL_USE_OSC: Az oszcillátor órája legyen a rendszeróra SYSCTL_OSC_MAIN: A bemeneti oszcillátor a fő oszcillátor legyen SYSCTL_XTAL_8MHZ: A külső kristály frekvenciája 8MHz legyen Mivel a mikrokontrollert az alaplapra integrált állapotban használom, ezért a kontroller szempontjából külső kristály az alaplapi kristály lesz. A

SysCtlClockSet

segítségével

beállított

órajelet

módosítom

ezután

a

SysTickPeriodSet függvény meghívásával. Ennek az az oka, hogy a µVision-ben működő kiindulási rendszerben az interruptok időegység alatti bekövetkezési gyakoriságát megmérve, az alapidőzítésre 100Hz (10msec) adódott, ezért a CooCox környezetbe átültetett rendszerben is ennyinek kell lennie.

- 46 -

6.2. ábra: A program időzítése.

Jelenleg SYSTICKHZ=100, vagyis a SysTick periódust ennek az értéknek a századára állítom (6.2. ábra). A CooCox környezetbe átültetett programváltozatnál szintén megmérve az interruptok bekövetkezése közötti időt, azt kaptam, hogy ugyanúgy 10msec telik el két interrupt bekövetkezése között, mint a µVision-ös progamváltozatban, tehát így jól van beállítva a működési frekvencia.

6.4 Az SSI kiterjesztés használata a programban Az elterjedt Apache webszerverbe beépített SSI funkció előre meghatározott, paraméterezhető utasításokat, úgynevezett direktívákat tartalmaz. Ezek használatához a következő alakban kell az utasítást a HTML fájlba ágyazni: [48] Az HTTP szerver programban általam megvalósított SSI működés ennél egyszerűbb: az utasítások nem paraméterezhetők. Lehetőség van viszont saját utasítás tagek definiálására. További eltérés a hagyományos SSI-től, hogy a HTML-be ágyazott SSI tageket nem cseréli le a szerver a felhasználónak küldött kódban, hanem utánuk fűzi a tag handler függvény kimenetét. A programban alkalmazható utasítás tagek alakja a következő:

A szerver az .shtml, .ssi és .shtm kiterjesztésű fájlok tartalmát figyeli ilyen utasításokra várva. Ha talált, akkor meghívja az SSIHandler kezelő függvényt, ennek kimenetét pedig az SSI utasítás után fűzi a HTML fájlon belül, és csak ezután küldi el a kliensnek. Ha nem szerepel a fájlban SSI utasítás, akkor a válasz feldolgozása teljesen megegyezik egy sima HTML fájléval. Amennyiben a szerver olyan taget talált, amelyhez nem került sor handler definiálására, ezt úgy jelzi a felhasználónak, hogy egy - 47 -

*** UNKNOWN TAG tagname *** alakú HTML kódrészletet illeszt az érintett tag után. Az SSI funkció bekapcsolása az INCLUDE_HTTPD_SSI nevű konstans beállításával történik, alapértelmezésben be van kapcsolva. Definíció helye: lwipopts.h A használni kívánt tagek neveit fel kell sorolni a g_ppcConfigSSITags tömbben. Alapértelmezésként néhány demo taget definiáltam, ezeket tetszés szerint módosítani lehet a felhasználáskor. Definíció helye: enet_lwip.c A tag neve nem tartalmazhat whitespace karaktereket vagy kötőjelet, de a között szerepelhet whitespace karakter. Egy tag neve MAX_TAG_NAME_LEN hosszú lehet, ez jelenleg 8 karakterre van állítva. Definíció helye: lm3slib/third_party/lwip-1.3.2/apps/httpserver_raw/httpd.h A tageket kezelő handler függvény neve SSIHandler és az enet_lwip.c fájlban definiáltam. Ennek a függvénynek a feladata, hogy a paraméterül kapott SSI utasításhoz előállítsa azt a karaktersorozatot, amelyet a szerver beilleszthet az adott utasítás után a HTML fájlba a kliensnek való küldés előtt. Jelenleg a definiált tagekhez demonstrációs céllal egy-egy előre definiált sztringet ad vissza, ezt a használatba vételkor módosítani kell. Valahányszor a szerver SSI taget talál egy .shtml fájlban, meghívja ezt a függvényt. Definíció helye: enet_lwip.c. Paraméterei: int

iIndex:

Ez

a

szám

az

aktuális

SSI

utasítás

sorszámát

jelöli

a

g_ppcConfigSSITags tömbön belül. char *pcInsert: A feldolgozás eredményét adó karaktersorozatot az ez által a pointer által meghatározott memóriacímre kell írni. int iInsertLen: Annak a puffernek a mérete, amely a pcInsert–ben megadott memóriacímen kezdődik. Visszatérés: int érték – az eredményként kapott sztring hossza. Az

SSI

utasítás

MAX_TAG_INSERT_LEN

feldolgozása hosszú

során

lehet,

előállított

ez

az

érték

karaktersorozat 192.

maximum

Definíció

helye:

lm3slib/third_party/lwip-1.3.2/apps/httpserver_raw/httpd.h A

HTTP

szerver

inicializálása

után

(httpd_init

hívás)

a

http_set_ssi_handler függvény segítségével szabtam meg, hogy az SSI tagre a fentebb bemutatott SSIHandler függvényt kell meghívni. Hívás helye: enet_lwip.c Az SSI funkció tesztelését a 7.5. fejezetben végzem el.

- 48 -

6.5 A program használata Ebben a fejezetben néhány hasznos tanácsot adok, melyek a későbbi továbbfejlesztést segíhetik. CooCox CoIDE használatba vétele: A telepítést érdemes a CooCox CoCenter program segítségével végezni. A CoIDE-n kívül a CoFlash feltelepítését is javaslom. Ha elérhető egy frissítés valamelyik programhoz, akkor a CoCenter azt jelzi. A számítógépen érdemes olyan elérési útvonalra feltelepíteni a programot, amely nem tartalmaz szóközt. A fordító beállítását a Project > Select Toolchain Path menüpontban lehet elvégezni, én a GCC-t használtam, ahogyan ezt a CooCox is javasolja [85]. MicroSD kártya védelme: A MicroSD kártya behelyezése vagy eltávolítása előtt biztonsági okokból ki kell kapcsolni az alaplapot a kártya esetleges sérülésének elkerülése érdekében [20]. SSI funkció testreszabása: A programban jelenleg definiált SSI tagek és az őket kezelő függvények csupán demonstrációs célokat szolgálnak. Ha a szever ismeretlen SSI utasítást talál, akkor a httpd.c fájl get_tag_insert függvényében jelzi ezt egy karaktersorozattal, amelyet módosítani lehet igény esetén. A felhasználáshoz saját tageket és handlereket lehet definiálni, a lehetséges beállításokat a 6.4. fejezetben mutatom be részletesen. TCP beállítások: A TCP kapcsolatkezelés paramétereinek átállítására a lwipots.h fájlban van mód, a „TCP options” szekcióban. HTTP

beállítások:

A memóriakártya

gyökérkönyvtárában

célszerű

elhelyezni

egy

index.html nevű fájlt, ugyanis ha a kliens kérése nem tartalmaz fájlnevet, akkor alapértelmezésben ezt a fájlt fogja keresni a szerver. (A 6.1. fejezetben a szerver által kezelt fájltípusokról és a típusok vizsgálatának sorrendjéről több információ szerepel.) A felhasználáskor készíteni lehet saját 404-es HTTP státuszt jelző fájlt is, de ez nem kötelező. A szerver a httpd.c fájl get_404 file metódusában vizsgálja ennek meglétét. Dokumentáció: A program kódja el van látva megjegyzésekkel, melyek a megértést és a használatot segítik. Ezek automatikus dokumentációkészítő program segítségével (ilyen például a Doxygen) könnyen kinyerhetők.

- 49 -

7 Tesztelés A program a jelenlegi változatában az alaplaphoz csatlakoztatott MicroSD kártyán elhelyezett tartalmat képes szolgáltatni. (A megvalósítás során a mikrokontroller flash memóriájából nem lehet tartalmat megjeleníteni, ennek kis mérete egyébként sem jelentene nagy előnyt.) Egy MicroSD kártya akár 2GB tárhelyet is nyújthat, könnyen és egyszerűen cserélhető, szabványos eszköz, és napjainkban olcsón hozzáférhető. A tesztelés során a fő hangsúlyt a TCP/IP protokollcsalád elemeinek vizsgálatára helyeztem, de a használat közben megbizonyosodtam arról is, hogy a fájlrendszer és a memóriakártya használata megfelelően működik, hiszen a böngészőben megjelentek a megfelelő fájlok, amelyeket a szerver a MicroSD kártyáról olvasott be, és az SSI címkéket is sikeresen feldolgozta. A mikrokontrolleren futó HTTP szerver gyakorlati kipróbálása alapján a program a kiírásoknak megfelelő módon, jól működik. A TCP/IP protokollcsalád megfelelő működésének ellenőrzéséhez annak felépítéséből kell kiindulni. A HTTP szerver előírásszerű működéséhez szükséges, hogy TCP/IP rétegekből legalább az alábbi, egymásra épülő szolgáltatások megfelelő módon implementálva legyenek a programban (7.1. táblázat). TCP/IP réteg

Protokoll neve

Alkalmazási (Application)

HTTP

Szállítási (Transport)

TCP

Hálózati (Network)

IP

Adatkapcsolati (Data)

ARP

Protokoll célja Az érdemi adatok szintje. Erőforrások (tipikusan fájlok) azonosítása, kliens és szerver kapcsolatának kezelése. Az adatok csomagokra bontása a küldő oldalon - a fogadó oldalon pedig az eredeti adat visszaállítása a beérkezett csomagokból. Megérkezett csomagok nyugtázása, a helyes csomagsorrend visszaállítása. A csomagok továbbítása a hálózaton át, logikai címzéssel. A hálózati eszközök azonosítása – fizikai címzés.

7.1. táblázat: A TCP/IP protokollcsalád megvalósításához szükséges modulok áttekintése.

Ha az ARP címfeloldás működik, és az eszköz kapcsolatban van egy alapértelmezett átjáróként funkcionáló hálózati csomóponttal, akkor az általános TCP/IP csomagtovábbítási stratégia (lásd 2.2.1.1. fejezet) működik. Ezen kívül a szerver képes kell, hogy legyen arra, hogy egy számára DHCP-vel kiosztott IP-címet használatba tudjon venni. - 50 -

A következő fejezetekben bemutatom a használt protokollok vizsgálatát és a kapott eredményeket. Az adatforgalmat a Wireshark nevű hálózati forgalom-elemző programmal rögzítettem, valamint a Microsoft parancssori eszközeit használtam [87] a teszt során.

7.1 ARP Az ARP a fizikai réteg feletti első réteg, az Address Resolution Protocol rövidítése, melynek jelentése: címfeloldási protokoll. Az eszközök fizikai címe és az IP-címek között átváltást biztosítja [86], ezt logikai címfeloldásnak is nevezik. A fizikai, vagy MAC cím 6 bájtos, a címben a legnagyobb helyiértékű bájt van elöl (big endian bájtsorrend) és a kiosztható címek négy csoportba sorolhatók: világállandó, lokálisan kiosztható, multicast, valamint broadcast csoportba. A broadcast, vagyis az összes állomásnak szóló üzeneteket az FF:FF:FF:FF:FF:FF címre kell küldeni. (Megjegyzés: az alhálózat IP broadcast címe és az Ethernet broadcast cím különböző fogalmak.) A világállandó csoportba tartozó címek legnagyobb helyiértékű bájtja *0, *4, *8 vagy *C lehet, és az első három bájt a gyártó céget azonosítja. A lokálisan kiosztható címek legnagyobb helyiértékű bájtja *2, *6, *A vagy *E lehet. A multicast, vagyis egyszerre több címzettnek szóló üzenetek címzettjének legnagyobb helyiértékű bájtja *1, *3, *5, *7, *9, *B, *D vagy *F, kivéve a már fent említett broadcast címet ([88] „Mac címek fajtái” szakasz). Az ARP működése a fizikai eszközök által nyilvántartott, úgynevezett ARP-táblák vizsgálatával figyelhető meg. Amikor olyan IP-címre kell adatot küldenie az eszköznek, amellyel egyazon alhálózatra kapcsolódnak, akkor az ARP protokoll segítségével először az IP-címhez tartozó fizikai címet határozza meg. Ha korábban már felvette a címzettel a kapcsolatot, akkor a címe szerepel az ARP-táblázatban, így a logikai címfeloldás elvégezhető, ellenkező esetben új bejegyzést hoz létre a táblában a címmel (lásd 2.2.1.1. fejezet (II.) ). Ha a címzett egy másik alhálózaton van, akkor az alapértelmezett átjáró kapja meg a csomagot, és az ARP-táblázatba nem kerül be új bejegyzés, hiszen nem kerül sor az ARP IPcímről a fizikai címre való konvertálására (lásd 2.2.1.1. fejezet (I.) ). Az eszközök hálózati interfészei az ARP-táblájukat folyamatosan frissítik (a frissítés gyakorisága implementációfüggő), ezért ez jó lehetőséget kínál a tesztelésre. Ha az ARP protokoll jól működik, akkor – ha közös alhálózaton vannak – a kliens gép Ethernet interfészének ARP-táblázatában megjelenik a Stellaris szerver fizikai címe, miután a kapcsolat felvétele megtörtént.

- 51 -

7.1.1 ARP közös alhálózat esetén A vizsgálathoz alkalmazott konfiguráció (7.1. ábra):

7.1. ábra: A HTTP szerver és kliens közös alhálózatra csatlakozik.

Az ipconfig [24] parancs segítségével meghatároztam a számítógépem Ethernet interfészének aktuálisan kiosztott IP-címét a netmask-kal együtt: 192.168.11.124/255.255.255.0 A Stellaris alaplap kijelzőjéről leolvastam a HTTP szervernek kiosztott IP-címet: 192.168.11.137/255.255.255.0 (Megjegyzés: ha az IP-cím nem lenne így megjelenítve, akkor nehezebb lenne a fizikai cím meghatározása. Ilyen esetben először célszerű lenne az alkalmazott konfigurációhoz hasonlóan a kliens számítógéppel közös alhálózatba kapcsolni az alaplapot, majd a számítógépről végigpásztázni a hálózatra kapcsolódó eszközöket. Ilyen feladatokra alkalmas például az nmap nevű program, de ez végső esetben akár manuálisan is elvégezhető a megfelelő parancsok kiadásával.) A vizsgálat kezdetén a szerver fizikai címe nem szerepel a kliens PC ARP-táblázatában. Ennek tartalma az arp [89] parancs segítségével listázható:

C:\Windows\system32>arp -a Interface: 192.168.11.124 --- 0xa

- 52 -

Internet Address

Physical Address

Type

192.168.11.1

00-19-cb-24-bd-30

dynamic

192.168.11.255

ff-ff-ff-ff-ff-ff

static

224.0.0.22

01-00-5e-00-00-16

static

224.0.0.252

01-00-5e-00-00-fc

static

255.255.255.255

ff-ff-ff-ff-ff-ff

static

Ahhoz, hogy bekerüljön ide egy bejegyzés a HTTP szerverről, valamilyen módon fel kell venni vele a kapcsolatot. Erre a legegyszerűbb megoldás egy ping [90] kérés küldése, amelyre választ kapván a PC bővíteni fogja a táblázatot a szerver IP-címével és fizikai címével. A pingelés kimenete:

C:\Windows\system32>ping 192.168.11.137 Pinging 192.168.11.137 with 32 bytes of data: Reply from 192.168.11.137: bytes=32 time=3ms TTL=255 Reply from 192.168.11.137: bytes=32 time=1ms TTL=255 Reply from 192.168.11.137: bytes=32 time=1ms TTL=255 Reply from 192.168.11.137: bytes=32 time=1ms TTL=255 Ping statistics for 192.168.11.137: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 3ms, Average = 1ms Ezután újra ellenőriztem az ARP-táblát az arp parancs segítségével:

C:\Windows\system32>arp -a Interface: 192.168.11.124 --- 0xa Internet Address

Physical Address

Type

192.168.11.1

00-19-cb-24-bd-30

dynamic

192.168.11.137

00-1a-b6-00-0b-a3

dynamic

192.168.11.255

ff-ff-ff-ff-ff-ff

static

224.0.0.22

01-00-5e-00-00-16

static

224.0.0.252

01-00-5e-00-00-fc

static

239.255.255.250

01-00-5e-7f-ff-fa

static

255.255.255.255

ff-ff-ff-ff-ff-ff

static

- 53 -

Mivel közös alhálózaton van a kliens PC és a szerver, ezért a kliens ARP-táblázatába bekerült az új bejegyzés (ellenkező esetben erre nem kerülne sor, hiszen a kliens ekkor a default gateway-nek küldené az adatcsomagokat, lásd: 7.1.2 fejezet). Most már szerepel benne a szerver IP-címe, és leolvasható az alaplap fizikai címe: 00:1A:B6:00:0B:A3 Ahogyan azt vártam, ez megegyezik az általam használt eszköz fizikai címével. Mindezek alapján megállapítható, hogy a HTTP szerver ARP protokoll megvalósítása jól működik az alhálózaton belül.

7.1.2 ARP eltérő alhálózat esetén A teszteléshez alkalmazott hálózatot a 7.2. ábra szemlélteti. Most külön alhálózatra csatlakozik a HTTP szerver és a kliensként használt PC.

7.2. ábra: A HTTP szerver és a kliens külön alhálózaton vannak.

A HTTP szerver IP-címe: 192.168.1.101 A már említett módon leolvastam a kliens PC paramétereit is:

C:\Windows\system32>ipconfig

- 54 -

[...] Ethernet adapter Local Area Connection: Connection-specific DNS Suffix

. :

Link-local IPv6 Address . . . . . : fe80::f18f:355c:c780:6d49%10 IPv4 Address. . . . . . . . . . . : 192.168.2.100 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.2.1 Ellenőriztem az ARP-táblázatot:

C:\Windows\system32>arp -a Interface: 192.168.2.100 --- 0xa Internet Address

Physical Address

Type

192.168.2.1

00-21-27-f2-e7-8a

dynamic

192.168.2.255

ff-ff-ff-ff-ff-ff

static

224.0.0.22

01-00-5e-00-00-16

static

224.0.0.252

01-00-5e-00-00-fc

static

239.255.255.250

01-00-5e-7f-ff-fa

static

255.255.255.255

ff-ff-ff-ff-ff-ff

static

Ahogyan várható is volt, nem szerepel benne bejegyzés a HTTP szerver paramétereivel. A következő lépésben kliens számítógépről megpingeltem a szervert:

C:\Windows\system32>ping 192.168.1.101 Pinging 192.168.1.101 with 32 bytes of data: Reply from 192.168.1.101: bytes=32 time=2ms TTL=254 Reply from 192.168.1.101: bytes=32 time=1ms TTL=254 Reply from 192.168.1.101: bytes=32 time=1ms TTL=254 Reply from 192.168.1.101: bytes=32 time=1ms TTL=254 Ping statistics for 192.168.1.101: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 2ms, Average = 1ms

- 55 -

Ezután újra megvizsgáltam az ARP-táblázatot, és az megegyezett a fenti állapottal: a HTTP szerver nem került bejegyzésre, hiszen mivel a külön alhálózaton vannak, a kliens az alapértelmezett átjárójára küldte az adatokat. Wireshark programban vizsgálva az elküldött kérést (7.2. táblázat):

Frame száma Időpont Forrás cím Cél cím Protokoll Információ

Packet adatok 276 429.566227

IP szint

(PC) 192.168.2.100 (IP: Stellaris, Ethernet: Router) 192.168.1.101 ICMP Echo (ping) request (id=0x0001, seq(be/le)=11/2816, ttl=1)

Ethernet szint 00:1e:33:53:76:33 00:21:27:f2:e7:8a

7.2. táblázat: ping kérés adatai Wireshark programból.

Látható, hogy a kérés küldőjének fizikai címe megegyezik a PC fizikai címével, azonban a cél fizikai címe (00:21:27:f2:e7:8a) láthatóan nem egyezik meg a Stellaris alaplap Ethernet interfészének fizikai címével (00:1a:b6:00:0b:a3). Ugyanezt tapasztaltam a válaszkérés adatainál is (7.3. táblázat): Packet adatok Frame száma Időpont Forrás cím Cél cím Protokoll Információ

IP szint

Ethernet szint

277 429.568086 (IP: Stellaris, Ethernet: Router) 192.168.1.101 00:21:27:f2:e7:8a (PC) 192.168.2.100 00:1e:33:53:76:33 ICMP Echo (ping) reply (id=0x0001, seq(be/le)=11/2816, ttl=254) 7.3. táblázat: ping válasz adatai Wireshark programból.

Jobban megfigyelve azonban észrevehető, hogy a kérdéses fizikai cím szerepel a számítógép

ARP-táblázatában,

a

192.168.2.1

IP-címhez

rendelve,

amely

az

alapértelmezett átjárót jelenti az ipconfig parancs kimenete alapján. Ez tehát azt jelenti, hogy a 2.2.1.1. fejezetben az (I) pont alatt ismertetett viselkedést követte az útválasztó eszköz, amelyhez a PC kapcsolódott: a PC által látott válasz adatcsomagban a feladó fizikai címe az alapértelmezett átjáróé, de a feladó IP-je a HTTP szerveré. A HTTP szerverrel való kommunikáció sikeresen zajlott mindkét irányban, hiszen mind a négy ping kérésre rendre megérkeztek a szervertől a válaszok. Ezek alapján megállapítható,

- 56 -

hogy a HTTP szerver ARP protokoll megvalósítása jól működik különböző alhálózatok esetén is.

7.2 IP Az ARP két esetének vizsgálata alapján az ARP szolgáltatás megfelelően működik, a szerver képes volt az alaplap fizikai címe, és a kiosztott IP-cím közötti megfeleltetésre. Az ARP feletti rétegek működése szempontjából irreleváns, hogy a küldő és a címzett interfészek közös alhálózaton vannak-e, ezért nem szükséges a továbbiakban a vizsgálat külön esetekre bontása. Mivel az alapértelmezett átjáró használata is rendben van, ezért az általános csomagtovábbítási stratégia megvalósításra került. (Megjegyzés: a router által DHCP-vel kiosztott IP-címet a szerver sikeresen használatba vette. Ez azért fontos, mert így lehet majd a harmadik (hálózati) és afeletti rétegből elérni a szervert, például böngészővel. Ha a routeren nem lenne DHCP szolgáltatás, vagy közvetlenül PC-vel kötnöm össze az alaplapot, akkor egy előre beállított „offline” IP-t használ a szerver: 169.254.164.11 Ez a link-local címtartományba tartozó IP-cím a programban módosítható.) Az előző fejezetben alkalmazott ping parancs egy ICMP echo üzenet. Az ICMP protokoll az IP-vel egy szinten van, a TCP/IP protokollcsalád hálózati rétegében (lásd: 2.5. ábra). A később fejezetekben leírt, böngészővel végzett tesztek alapján az IP protokoll is megfelelően működik.

7.3 TCP A TCP protokoll feladata, hogy a felette levő rétegben elhelyezkedő HTTP kapcsolat résztvevői között az adatcsomagok sikeres átvitelét biztosítsa. Ezt egy úgynevezett állapotgép (egy véges állapotú automata) segítségével valósítja meg, amely meghatározza a kapcsolat megfelelő felépítését, az adatok küldését és fogadását, valamint a kapcsolat lezárását. Lehetőség van az adatküldés sebességének szabályozására is (a slow start, a sliding window technika és a Nagle-algoritmus szolgálnak erre, ezek vizsgálatára nem térek ki a dolgozatban). A TCP állapotgép lehetséges állapotait, és az ezek közötti átmenetet a 7.3. ábra mutatja be. A HTTP kapcsolat alapértelmezésben a 80-as portot használja, ezért a szerver programnak hozzá kell tudnia férni ehhez a porthoz. A CoIDE Debug nézetében meggyőződtem arról, hogy szerver inicializálásakor (a http_init függvény meghívása) a program sikeresen hozzárendeli a bejövő TCP kapcsolat figyelését a szerver lokális 80-as portjához a tcp_bind függvény segítségével.

- 57 -

7.3. ábra: A TCP állapotgép állapotátmenetei. (Kép forrása: [91] )

Az LwIP modulban TCP állapotgépet a src/core/tcp_in._c fájlban szereplő tcp_process függvény valósítja meg. Case vezérlési szerkezettel kezeli le a SYN_SENT, SYN_RCVD, CLOSE_WAIT, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, CLOSING, LAST_ACK eseteket, és egy default ága is van. . (A programban a TCP beálllítások az lwipopts.h fájlban vannak megadva.) Ha az ESTABLISHED állapot áll fent, akkor fogad adatot a szerver, a tcp_receive függvénnyel. Ez fogadja és kezeli a szegmenseket, és szükség szerint nyugtáz, állít a küldés sebességén, kezeli a küldött és küldendő adatokat tartalmazó sorokat (queue), illetve adott esetben levezényli a kapcsolat lezárását. A fogadott adatokat feladja az alkalmazási rétegnek

- 58 -

Adatok küldésekor a kimenetre szánt adatokat a tcp_write függvény gyűjti be, a tényleges küldés pedig a tcp_output függvény meghívásával történik. A programkód tanulmányozása, a Wireshark programmal készített mérések, valamint a (szállítási réteg feletti) HTTP protokoll általam tapasztalt, jó működése alapján nem találtam hibát a TCP csomagkezelésében.

7.4 HTTP A HTTP protokoll a legfelső, alkalmazási rétegben szerepel. A szerver által kiszolgált tartalom, a felhasználó számára fontos adatok itt kerülnek definiálásra. A HTTP protokoll részletes ismertetését a 4.1 fejezetben tettem meg. Két esetet kell vizsgálni, hogy a működés ellenőrizhető legyen: egy „sikeres” HTTP kérést, amelyre a szerver a 2xx típusú üzenetkóddal válaszol, és a lekért erőforrást elküldi a kliensnek, ahol ez megjelenítésre kerül, valamint egy „sikertelen” kérést, ahol a szerver 3xx, 4xx vagy 5xx üzenetkóddal válaszol, mert például a kért erőforrás nem létezik. Erre azért van szükség, hogy megbizonyosodhassak arról, hogy a szerver működése a normálistól eltérő körülmények esetén sem hibásodik meg, sőt, a szabványnak megfelelően viselkedik. A két esetet a 7.4. ábra mutatja be, böngészőből vizsgálva.

- 59 -

7.4. ábra: HTTP 404 és HTTP 200 státusz megjelenítése böngészőben.

A HTTP protokoll megvalósítása tehát jól működik, ez alapján pedig kijelenthető, hogy a TCP/IP protokollcsalád vonatkozó részei működnek. A HTTP szerver program már használható állapotban van.

7.5 Dinamikus tartalom megjelenítése Mivel az SSI-tagek formátumát a HTML komment formátum magába foglalja, ezért ha véletlenül olyan fájlba kerül bele SSI utasítás, amely nem .ssi vagy .shtm, sem .shtml, akkor szerver nem dolgozza fel, a kliens böngészője pedig HTML megjegyzésként fogja értelmezni. A vizsgálat során három esetet néztem meg: •

Nincs SSI utasítás a megjelenített lapon,

- 60 -

•

Csak

olyan

SSI

tag

szerepel

a

HTML

fájlban,

amelyet

megadtam

a

g_ppcConfigSSITags tömbben (lásd 6.4. fejezet), •

Olyan SSI jelölésű címkét is tartalmazott a lekért lap, amelyet biztosan nem ismer fel a szerver érvényes SSI utasításként. Mindhárom esetben a várt működést tapasztaltam. A honlap megjelenése akkor sem

esett szét, amikor a szerver számára ismeretlen SSI tag szerepelt a fájlban. Az előre definiált módon, vastag betűvel, és a kérdéses tag nevét feltüntetve megjelent a hibaüzenet az adott helyen. A felismert tagek után a HTML forráskódban a megfelelő szöveg került beillesztésre.

7.6. ábra: SSI tag feldolgozás után.

7.5. ábra: SSI tag feldolgozás előtt.

A memóriakártyára másolt eredeti .shtml fájlt a 7.5. ábra szemlélteti. Itt csak az SSI címkék szerepelnek a forráskódban. A szerver által feldolgozott, és a kliensnek elküldött fájlban már az egyes SSI tagek után a kódba beszúrt sztringek is láthatók: a PC-n futtatott böngészőben az oldal forrásának megtekintését mutatja a 7.6. ábra.

- 61 -

8 Összefoglalás Ebben a fejezetben számba veszem az elért eredményeket, értékelem az elkészült programot és bemutatom a további fejlesztés lehetőségeit. Az elkészült HTTP szerver program képes arra, hogy a FAT fájlrendszerrel formázott memóriakártyán elhelyezett statikus, illetve SSI-vel kiegészített dinamikus HTML fájlokat HTTP kérés beérkezése esetén feldolgozza, majd a kliens számára értelmezhető HTTP válaszként elküldje. A program az alaplapra szerelt kijelzőn megjeleníti a használathoz leginkább szükséges információt, az Ethernet interfész IP-címét (8.1. ábra.).

8.1. ábra: Az alaplap kijelzője a HTTP szerver program működése közben.

8.1 Eredmények A

feladatkiírásban

megfogalmazott

általános

feladatokat

a

munka

során

megvalósítottam. A Texas Instruments Stellaris LM3S6965 mikrokontrolleren futó HTTP szerver program Ethernet hálózaton keresztül elérhető, a 80-as TCP proton figyeli a bejövő kapcsolatokat. Az elkészült program a HTTP GET kéréseket feldolgozza, és az eredményt a TCP kapcsolaton keresztül HTTP válaszként elküldi a kliensnek, amelyet az böngészőben megjeleníthet. A HTML dinamikus kiegészítését SSI-szerű megoldással valósítottam meg.

- 62 -

A feladatkiírásban megfogalmazott részfeladatokat is elvégeztem. Az embedded processzorokat tartalmazó rendszerek felépítéséről a 3. fejezetben írok, a használt LM3S6965 mikrokontrollerről pedig a 2.1. fejezetben. A beágyazott rendszerek hálózati kommunikációjáról a 4. fejezet szól. A tervezés folyamatát az 5. fejezetben, a követelményeket az 1.1. fejezetben tárgyalom, a rendszerben felhasznált elemeket pedig a 2.2. fejezetben veszem sorra. Az implementáció folyamatát a 6. fejezetben ismertetem. A tesztelés eredményeit a 7. fejezet tartalmazza. Az elkészült rendszer használatához a 6.5. fejezetben adok leírást. A fentiek alapján kijelenthetem, hogy a kiírt feladatot sikeresen elvégeztem, a HTTP szerver a Stellaris LM3S6965 mikrokontrolleren CooCox környezetben megfelelően működik.

8.2 További fejlesztési lehetőségek A HTTP szerver programot természetesen mindig lehet fejleszteni, jobbá tenni. A tervezett és lehetséges bővítés feladatai közül néhány elképzelést vázolok fel. A HTTP szerver integrálása a CooCox CoOS operációs rendszerébe. Ez a feladatom hosszútávú célja. Ennek előkészítését végeztem el a munka során. HTTPS (Hypertext Transfer Protocol Secure) használata. Ez a HTTP protokoll titkosított kapcsolatot használó változat. Olyan beágyazott rendszerekben lenne szükség erre, ahol fontos az eszköz biztonságos kezelése (például az, hogy a rendszer kódját ne frissíthesse akárki a webes kezelőfelület segítségével). A HTTPS lehetővé tenné, hogy a kliens és a szerver közötti kapcsolatot ne lehessen lehallgatni. A program adaptálása Ethernet helyett vezetéknélküli kapcsolatot használó eszközre. Ezen a feladaton már dolgozik egy hallgatótársam. A könnyebb használat érdekében a beállítások egy központi helyre történő összevonása. A program moduljainak paraméterezését jelenleg külön fájlokban lehet megoldani, a későbbiekben célszerű lehet ezeket egy helyen elvégezni. Ez megkönnyítené a webes vezérlő felület kialakítását is. A program lehetséges alkalmazási területei: Oktatási célok: az elkészült HTTP szerver segíthet a mikrokontrolleres témák, a C nyelvű programozás és a hálózati ismeretek (elsősorban a TCP/IP protokollcsalád megismerése) elsajátításának oktatásában. A kód továbbá hasznos tapasztalatokkal szolgálhat a diákoknak - 63 -

azzal kapcsolatban, hogy hogyan valósítható meg több, egymástól függetlenül fejlesztett szoftvermodul együttes működésének összehangolása. A program az egyetemen futó izomstimulátor projektbe való bekapcsolódás: az elkészült stimulátor eszköz ARM-alapú verziójának távoli vezérlését, adatainak leolvasását is segítheti. A hardverben rejlő lehetőségek alapján elképzelhető olyan felhasználás, ahol a LM3S6965 mikrokontroller frekvenciastabilizátor segítségével alacsony sebességű, nagy pontosságú órajelek előállítására alkalmas eszköz lesz. Pontos időmérésre sok területen van szükség, például GPS pozícionálás során.

- 64 -

9 Köszönetnyilvánítás Köszönöm konzulensemnek, Tihanyi Attila tanár úrnak, hogy bármikor fordulhattam hozzá tanácsért, munkámat nagy türelemmel irányította, és útmutatást adott a fejlesztés fázisai során. Külön köszönöm a Texas Instruments segítségét, mely lehetővé tette, hogy reális körülmények között tudjam megvalósítani a programot. Szeretném megköszönni ezen a helyen is családom felbecsülhetetlen támogatását, melyet tanulmányaim során kaptam.

- 65 -

10 Fogalmak jegyzéke Beágyazott rendszer: (embedded rendszer, mikrokontroller) mikroprocesszor-alapú rendszer, amely specifikus funkciót lát el, és a végfelhasználó nem programozhatja át egy általános célú számítógéppel ellentétben. Default gateway: alapértelmezett (hálózati) átjáró. Evaluation board: Fejlesztői kártya, alaplap. Handler: kezelő. Általában programkód-beli függvényekre vonatkozik. Harvard-architektúra: külön adat. és utasítás busz – ellenétben a Neumann-architektúrával. Host/hoszt: kliens. Interrupt: megszakításkérés. Netmask: alhálózati maszk, bináris számsorozat. PC: általános használatú személyi számítógép (például laptop). A mikrokontroller ellentéte. Pointer: memóriacímre mutat. Protokoll: számítógépes hálózati átviteli eljárások szabványosított gyűjteménye. Szerver: kiszolgáló. Stack: verem. Tag: címke a HTML, XML jelölőnyelvekben, valamint címke és utasítás az SSI technika használatakor.

- 66 -

11 Rövidítések jegyzéke ACK

Acknowledge

ADC

Analog-to-Digital Converter

API

Application Programming Interface

ARM

Advanced RISC Machines

ARP

Address Resolution Protocol

BOOTP Bootstrap Protocol BSD

Berkeley Software Distribution

CGI

Common Gateway Interface

CISC

Complex Instruction Set Computer

CMSIS

Cortex Microcontroller Software Interface Standard

CPSID

Change Processor State Interrupt Disable

CPSIE

Change Processor State Interrupt Enable

CPU

Central Processing Unit

CR

Car Return

CSS

Cascading Style Sheets

DHCP

Dynamic Host Control Protocol

DSP

Digital Signal Processor

FAT

File Allocation Table

FIN

Finish

GCC

GNU Compiler Collection

GPS

Global Positioning System

HTML

Hypertext Markup Language

HTTP

Hypertext Transfer Potocol

HTTPS

Hypertext Transfer Protocol Secure

IANA

Internet Assigned Numbers Authority

ICMP

Internet Control Message Protocol

IEEE

Institute of Electrical and Electronics Engineers

IETF

Internet Engineering Task Force

IP

Internet Protocol

IRQ

Interrupt Request

JTAG

Joint Test Action Group

LED

Light-emitting Diode

LF

Line Feed

- 67 -

LFN

Long File Name

LwIP

Lightweight IP

MAC

Media Access Controller

MCU

Microcontroller Unit

MDI

Medium Dependent Interface

MDI-X

Medium Dependent Interface Crossover

NVIC

Nested Vector Interrupt Controller

OLED

Organic LED

OS

Operating System

OSI

Open Systems Interconnect

PC

Personal Computer

PHY

Physical Layer

PLL

Phase-locked Loop

PWM

Pulse-width Modulation

RCC

Run-mode Clock Configuration

RFC

Request For Comments

RISC

Reduced Instruction Set Computer

RTC

Real-time Clock

RTOS

Real-time Operating System

SD

Secure Digital

SPI

Serial Peripheral Interface Bus

SSI

Server Side Includes

SSL

Secure Socket Layer

SYN

Synchronise

TCP

Transmission Control Protocol

TFTP

Trivial File Transfer Protocol

UDP

User Datagram Protocol

URI

Uniform Resource Identifier

URL

Unified Resource Locator

USB

Universal Serial Bus

UTP

Unshielded Twisted Pair (Cable)

WFI

Wait for Interrupt

XML

Extensible Markup Language

- 68 -

12 Ábrák jegyzéke 2.1. ábra: Stellaris LM3S6965 Ethernet Evaluation Board működés közben. 2.2. ábra: Az ARM Cortex-M3 processzor blokkdiagramja. (Kép forrása: [10]) 2.3. ábra: Az LM3S6965 alaplap blokkdiagramja. (Kép forrása: [15]) 2.4. ábra: Az Ethernet vezérlő blokkdiagramja. (Kép forrása: [19]) 2.5. ábra: Internet protokollok és programok. (Kép forrása: [5]) 2.6. ábra: 172.016.0.0/12 hálózat szemléltetése 3.1. ábra: A szerver-oldali szkriptfeldolgozás lépései. (Kép forrása: [34] 4. oldala) 3.2. ábra: Órajel útvonal ábrázolása a beállítási lehetőségekkel. Az a-val jelölt elemek az RCC (Run-Mode Clock Configuration) regiszterben állítható bitek. 4.1. ábra: A hétrétegű OSI modell. (Kép forrása: [46]) 4.2. ábra: Az OSI modell és a TCP/IP protokollcsalád összehasonlítása. (Kép forrása: [46]) 5.1. ábra: CooCox CoIDE v1.4.1 Repository: komponens nézet a perifériák használatához rendelkezésre álló modulokkal. 5.2. ábra: A modulok függőségi diagramja (CoIDE v1.4.1). 6.1. ábra: PLL beállítása a HTTP szerver inicializálásakor. 6.2. ábra: A program időzítése. 7.1. ábra: A HTTP szerver és kliens közös alhálózatra csatlakozik. 7.2. ábra: A HTTP szerver és a kliens külön alhálózaton vannak. 7.3. ábra: A TCP állapotgép állapotátmenetei. (Kép forrása: [91] ) 7.4. ábra: HTTP 404 és HTTP 200 státusz megjelenítése böngészőben. 7.5. ábra: SSI tag feldolgozás előtt. 7.6. ábra: SSI tag feldolgozás után. 8.1. ábra: Az alaplap kijelzője a HTTP szerver program működése közben.

- 69 -

13 Táblázatok jegyzéke 2.1. táblázat: Fontosabb fenntartott IP-tartományok. 3.1. táblázat: Stellaris mikrokontrollerek órajel-forrásai. 5.1. Táblázat: Operációs rendszer választási szempontjai. 7.1. táblázat: A TCP/IP protokollcsalád megvalósításához szükséges modulok áttekintése. 7.2. táblázat: ping kérés adatai Wireshark programból. 7.3. táblázat: ping válasz adatai Wireshark programból.

- 70 -

14 Irodalomjegyzék [1]

“XXX. Jubileumi OTDK Informatika Tudományi Szekció, Az Informatika Tudományi Szekció eredményei,” 2011.04.23. [Online]. Available: http://otdk2011.itk.ppke.hu/node/23. [Hozzáférés: 2012.05.08.]

[2]

"Transmission Control Protocol, DARPA Internet Program Protocol Specification" ietf.org, 1981. szeptember. [Online]. Available: http://tools.ietf.org/html/rfc793. [Hozzáférés: 2012.05.21.]

[3]

“Service Name and Transport Protocol Port Number Registry”, 2012.05.18. [Online]. http://www.iana.org/assignments/service-names-port-numbers/service-names-portnumbers.xml. [Hozzáférés: 2012.05.21.]

[4]

R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", ietf.org, 1999. június. [Online]. Available: http://tools.ietf.org/html/rfc2616. [Hozzáférés: 2012.05.16.]

[5]

Pásztor M., Számítógéphálózatok - 1. előadás", itk.ppke.hu, 2012. [Online]. Available: http://users.itk.ppke.hu/~mpasztor/netora/2012-tavasz/eloadas-1.html. [Hozzáférés: 2012.05.08.]

[6]

“Company Profile - ARM”, 2012. [Online]. Available: http://www.arm.com/about/company-profile/index.php. [Hozzáférés: 2012.05.13.]

[7]

“ARM Company Milestones - ARM”, 2012. [Online]. Available: http://www.arm.com/about/company-profile/milestones.php. [Hozzáférés: 2012.05.13.]

[8]

T. Martin,The insider’s guide to the STM32 ARM based microcontroller: An Engineer’s Introduction To The STM32 Series. Coventry, United Kingdom: Hitex, 2008, p. 9.

[9]

J. Yiu, The definitive guide to the ARM Cortex-M3, 2nd ed. Burlington, MA, USA: Newnes, 2010, p. 4.

[10] J. Yiu, The definitive guide to the ARM Cortex-M3, 2nd ed. Burlington, MA, USA: Newnes, 2010, p. 12. [11] “Cortex-M3 processor- ARM”, 2012. [Online]. Available: http://arm.com/products/processors/cortex-m/cortex-m3.php. [Hozzáférés: 2012.05.13.] [12] J. Yiu, The definitive guide to the ARM Cortex-M3, 2nd ed. Burlington, MA, USA: Newnes, 2010, pp. 99-100. [13] “Stellaris® ARM® Cortex™-M-based MCUs - 6000 Series - LM3S6965 - TI.com”, 2007. [Online]. Available: http://arm.com/products/processors/cortex-m/cortex-m3.php. [Hozzáférés: 2012.03.25.]

- 71 -

[14] “Stellaris ARM Cortex-M3 MCU - 6000 Series - TI.com”, 2007. [Online]. Available: http://www.ti.com/mcu/docs/mculuminaryfamilynode.tsp?sectionId=95&tabId=2599&f amilyId=1758. [Hozzáférés: 2012.03.25.] [15] Texas Instruments: Stellaris® LM3S6965 Evaluation board: User’s Manual, EKLM3S6965-06, Austin, TX, USA: Texas Instruments, 2010, p. 8. [16] Texas Instruments: Stellaris® LM3S6965 Evaluation board: User’s Manual, EKLM3S6965-06, Austin, TX, USA: Texas Instruments, 2010, p. 7. [17] Texas Instruments: Stellaris® LM3S6965 Evaluation board: User’s Manual, EKLM3S6965-06, Austin, TX, USA: Texas Instruments, 2010, p. 11. [18] Texas Instruments: Stellaris® LM3S6965 Evaluation board: User’s Manual, EKLM3S6965-06, Austin, TX, USA: Texas Instruments, 2010, p. 39. [19] Texas Instruments: Stellaris® LM3S6965 Evaluation board: User’s Manual, EKLM3S6965-06, Austin, TX, USA: Texas Instruments, 2010, p. 538. [20] Texas Instruments: Stellaris® LM3S6965 Evaluation board: User’s Manual, EKLM3S6965-06, Austin, TX, USA: Texas Instruments, 2010, p. 14. [21] “LwIP - A Lightweight TCP/IP stack - Summary”, 2012. [Online]. Available: http://savannah.nongnu.org/projects/lwip/. [Hozzáférés: 2012.05.19.] [22] “FatFs Generic FAT File System Module”, 2012.05.09. [Online]. Available: http://elmchan.org/fsw/ff/00index_e.html [Hozzáférés: 2012.05.19.] [23] A. Retana, R. White, V. Fuller, D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-toPoint Links", ietf.org, 2000. december. [Online]. Available: http://tools.ietf.org/html/rfc3021. [Hozzáférés: 2012.05.21.] [24] “Ipconfig”, 2012. [Online]. Available: http://technet.microsoft.com/enus/library/bb490921.aspx. [Hozzáférés: 2012.04.18.] [25] M. Cotton, L. Vegoda, "Special Use IPv4 Addresses", ietf.org, 2010. január. [Online]. Available: http://tools.ietf.org/html/rfc5735. [Hozzáférés: 2012.05.02.] [26] J. Mogul, "Broadcasting Internet Datagrams In The Presence Of Subnets", ietf.org, 1984. október. [Online]. Available: http://tools.ietf.org/html/rfc922. [Hozzáférés: 2012.05.02.] [27] Pásztor M., Számítógéphálózatok - 6. előadás", itk.ppke.hu, 2012. [Online]. Available: http://users.itk.ppke.hu/~mpasztor/netora/2012-tavasz/eloadas-6.html. [Hozzáférés: 2012.05.02.] [28] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, "Address Allocation for Private Internets", ietf.org, 1996. február. [Online]. Available: http://tools.ietf.org/html/rfc918. [Hozzáférés: 2012.05.02.] [29] S. Heath, Embedded Systems Design, ed. 2, Burlington, MA: Newnes, 2003, p. 2. [30] S. Heath, Embedded Systems Design, ed. 2, Burlington, MA: Newnes, 2003, p. 15. - 72 -

[31] S. Heath, Embedded Systems Design, ed. 2, Burlington, MA: Newnes, 2003, p. 23. [32] R. Muresan, Ed. Embedded System Development and Labs for ARM, University of Guelph, 2005. [PDF] Available: http://www.eos.uoguelph.ca/webfiles/rmuresan/EmbeddedSystemsAndLabsForARMV1.1.pdf. p. 19. [Hozzáférés: 2012.03.17.] [33] R. Muresan, Ed. Embedded System Development and Labs for ARM, University of Guelph, 2005. [PDF] Available: http://www.eos.uoguelph.ca/webfiles/rmuresan/EmbeddedSystemsAndLabsForARMV1.1.pdf. p. 20. [Hozzáférés: 2012.03.17.] [34] K-D. Walter, “Web Server for Embedded Systems”, dilnetpc.com, 2001. [PDF]. Available: http://www.dilnetpc.com/WSforES1-1.pdf. [Hozzáférés: 2012.03.16.]. [35] Göndöcz M., " Statikus HTTP szerver megvalósítása Texas Instruments Stellaris LM3S6965 mikrokontrolleren," Mérnöki tervezés beszámoló, PPKE ITK, Budapest, 2011.12.15. pp., 6-9. [36] Benyó B., Fék M., Kiss I., Kóczy A., Kondorosi K., Mészáros T., Román Gy., Szeberényi I., Sziray J., Operációs rendszerek Mérnöki megközelítésben, Budapest: Panem, 2000., p. 58. [37] Benyó B., Fék M., Kiss I., Kóczy A., Kondorosi K., Mészáros T., Román Gy., Szeberényi I., Sziray J., Operációs rendszerek Mérnöki megközelítésben, Budapest: Panem, 2000., p. 26. [38] Luminary Micro Inc.: Luminary Micro ™ Stellaris® Peripheral Driver Library: User’s Guide, Version 1716, Austin, TX, USA: Texas Instruments, 2007, p. 195. [39] Benyó B., Fék M., Kiss I., Kóczy A., Kondorosi K., Mészáros T., Román Gy., Szeberényi I., Sziray J., Operációs rendszerek Mérnöki megközelítésben, Budapest: Panem, 2000., p. 53. [40] Benyó B., Fék M., Kiss I., Kóczy A., Kondorosi K., Mészáros T., Román Gy., Szeberényi I., Sziray J., Operációs rendszerek Mérnöki megközelítésben, Budapest: Panem, 2000., p. 34. [41] Texas Instruments: Clocking options for Stellaris® Family Microcontrollers: Application Note, AN01240-04, Austin, TX, USA: Texas Instruments, 2009, p. 4. [42] Luminary Micro Inc.: Luminary Micro ™ Stellaris® Peripheral Driver Library: User’s Guide, Version 1716, Austin, TX, USA: Texas Instruments, 2007, p. 127. [43] “CERN History highlights - 1990”, 2008. [Online]. Available: http://public.web.cern.ch/public/en/About/History90-en.html. [Hozzáférés: 2012.05.13.] [44] Göndöcz M., "Statikus HTTP szerver megvalósítása Texas Instruments Stellaris LM3S6965 mikrokontrolleren," Önálló laboratórium I. beszámoló, PPKE ITK, Budapest, 2011.12.15. pp., 3-6. - 73 -

[45] W. R. Stevens, TCP/IP Illustrated, 26th ed., Vol.1. Addison-Wesley, 2005, p. 9. [46] “TCP/IP - Internet Protocol Suite and Ethernet”, 2008.02.12. [Online]. Available: http://bit.kuas.edu.tw/~csshieh/teach/np/tcpip/index.html. [Hozzáférés: 2012.04.18.] [47] A. S. Tanenbaum, Computer Networks, 4th ed. Prentice Hall, 2002, p.43. [48] “Apache Tutorial: Introduction to Server Side Includes – Apache HTTP Server”, 2012. [Online]. Available: http://httpd.apache.org/docs/2.4/howto/ssi.html [Hozzáférés: 2012.05.13.] [49] “µVision IDE - Overview”, 2012. [Online]. Available: http://www.keil.com/uvision [Hozzáférés: 2012.03.11.] [50] Texas Instruments: Stellaris® LM3S6965 Evaluation board: User’s Manual, EKLM3S6965-06, Austin, TX, USA: Texas Instruments, 2010, p. 9. [51] “eCosPro Developer's Kit”, 2011., [Online]. Available: http://www.ecoscentric.com/ecos/ecospro.shtml [Hozzáférés: 2011.05.22.] [52] “RTOS - Real-Time Operating Systems for Embedded Development, Real Time System By Express Logic”, 2010., [Online]. Available: http://rtos.com/products/threadx/ARMThumb [Hozzáférés: 2011.05.22.] [53] “Embedded RTOS - ARM ColdFire Royalty Free Multitasking Kernel USB H/D/O FAT Flash Filesystem GUI TCP/IP PowerPC x86 RTOS”, 2011., [Online]. Available: http://www.smxrtos.com/rtos/product.htm [Hozzáférés: 2011.05.22.] [54] “A Free real time operating system (RTOS) for small embedded systems - list of RTOS features”, 2011., [Online]. Available: http://www.freertos.org/FreeRTOS_Features.html [Hozzáférés: 2011.05.22.] [55] “uClinux -- Embedded Linux/Microcontroller -- uClinux: Ports!”, 2011., [Online]. Available: http://www.uclinux.org/ports [Hozzáférés: 2011.05.22.] [56] “ARM7 Processor Family - ARM”, 2011., [Online]. Available: http://www.arm.com/products/processors/classic/arm7/index.php [Hozzáférés: 2012.04.14.] [57] “Free and open ARM Cortex M3 and Cortex M0 RTOS”, 2011., [Online]. Available: http://www.coocox.com/CoOS.htm [Hozzáférés: 2012.05.09.] [58] CooCox CoOS User’s Guide,, rev. 1.1. 2009., p. 16. [59] “Examples and Application Solutions base on CoOS RTOS”, 2011., [Online]. Available: http://www.coocox.com/CoOSguide/Examples.htm [Hozzáférés: 2012.05.09.] [60] “CooCox CoIDE”, 2011., [Online]. Available: http://coocox.com/CooCox_CoIDE.htm [Hozzáférés: 2012.05.09.] [61] “Terms and Conditions”, 2011., [Online]. Available: http://coocox.com/policy.htm [Hozzáférés: 2012.05.09.] - 74 -

[62] “CooCox CoIDE Update History”, 2011., [Online]. Available: http://coocox.org/CoIDE/CoIDE_Updates.htm [Hozzáférés: 2012.05.09.] [63] “CooCox CoCenter”, 2011., [Online]. Available: http://coocox.org/CoCenter.htm [Hozzáférés: 2012.05.09.] [64] “CooCox CoBuilder”, 2011., [Online]. Available: http://www.coocox.org/CooCox_Builder.htm [Hozzáférés: 2012.05.09.] [65] “CooCox CoDebugger”, 2011., [Online]. Available: http://www.coocox.org/CooCox_CoDebugger.htm [Hozzáférés: 2012.05.09.] [66] “CooCox CoDebugger”, 2011., [Online]. Available: http://www.coocox.org/CooCox_CoDebugger.htm [Hozzáférés: 2012.05.09.] [67] “CooCox CoFlash”, 2011., [Online]. Available: http://www.coocox.org/CoFlash_Programmer.htm [Hozzáférés: 2012.05.09.] [68] “Boundary-Scan (JTAG) test and in-system programming solutions (IEEE 1149.1) About”, 2012., [Online]. Available: http://www.jtag.com/en/About [Hozzáférés: 2012.05.08.] [69] “Debug Configurations”, 2011., [Online]. Available: http://www.coocox.org/CoIDE/Configuring_configuration.html [Hozzáférés: 2012.05.08.] [70] Kopcsó T., "FTP szerver megvalósítása Texas Instruments Stellaris LM3S6965 mikrokontrolleren," Önálló laboratórium II. beszámoló, PPKE ITK, Budapest, 2011. pp., 11-12. [71] “CMSIS core for Cortex M3 V1.30 source code and example free download”, 2011., [Online]. Available: http://www.coocox.org/show_comp.php?id=bf7c3c91-96ed-11df80ae-001d7d723e56 [Hozzáférés: 2012.05.10.] [72] “LM3S CMSIS Boot V1.20 source code and example free download”, 2011., [Online]. Available: http://www.coocox.org/show_comp.php?id=c07b8421-96ed-11df-80ae001d7d723e56 [Hozzáférés: 2012.05.10.] [73] “Startup code source code and example free download”, 2011., [Online]. Available: http://www.coocox.org/show_comp.php?id=56e31cf1-9c7b-11e0-a293-001fd0c63d33 [Hozzáférés: 2012.05.10.] [74] “CPU source code and example free download”, 2011., [Online]. Available: http://www.coocox.org/show_comp.php?id=c087b920-96ed-11df-80ae-001d7d723e56 [Hozzáférés: 2012.05.10.] [75] “Low layer Module source code and example free download”, 2011., [Online]. Available: http://www.coocox.org/show_comp.php?id=c08f5a41-96ed-11df-80ae001d7d723e56 [Hozzáférés: 2012.05.10.]

- 75 -

[76] “Interrupt Controller source code and example free download”, 2011., [Online]. Available: http://www.coocox.org/show_comp.php?id=c09d15e1-96ed-11df-80ae001d7d723e56 [Hozzáférés: 2012.05.10.] [77] “System Control source code and example free download”, 2011., [Online]. Available: http://www.coocox.org/show_comp.php?id=c0bb9a60-96ed-11df-80ae-001d7d723e56 [Hozzáférés: 2012.05.10.] [78] T. Berners-Lee, R. Fielding, H. Frystyk, " Hypertext Transfer Protocol -- HTTP/1.0", ietf.org, 1996. május. [Online]. Available: http://tools.ietf.org/html/rfc1945. [Hozzáférés: 2012.05.21.] [79] B. Krishnamurthy, J. C. Mogul, D. M. Kristol, Key differences between HTTP/1.0 and HTTP/1.1. Toronto: Elsevier, 1999. p. 2. [80] B. Krishnamurthy, J. C. Mogul, D. M. Kristol, Key differences between HTTP/1.0 and HTTP/1.1. Toronto: Elsevier, 1999. p. 5. [81] B. Krishnamurthy, J. C. Mogul, D. M. Kristol, Key differences between HTTP/1.0 and HTTP/1.1. Toronto: Elsevier, 1999. pp. 6-7. [82] B. Krishnamurthy, J. C. Mogul, D. M. Kristol, Key differences between HTTP/1.0 and HTTP/1.1. Toronto: Elsevier, 1999. p9. 7-8. [83] B. Krishnamurthy, J. C. Mogul, D. M. Kristol, Key differences between HTTP/1.0 and HTTP/1.1. Toronto: Elsevier, 1999. p. 9. [84] Göndöcz M., "Statikus HTTP szerver megvalósítása Texas Instruments Stellaris LM3S6965 mikrokontrolleren," Mérnöki tervezés beszámoló, PPKE ITK, Budapest, 2011.12.15. p., 9. [85] “Compiler Setting”, 2011., [Online]. Available: http://coocox.com/CoIDE/Compiler_Settings.html [Hozzáférés: 2012.05.08.] [86] D. C. Plummer, "An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", ietf.org, 1982. november. [Online]. Available: http://tools.ietf.org/html/rfc826. [Hozzáférés: 2012.05.14.] [87] “TCP/IP utilities and services”, 2012. [Online]. Available: http://technet.microsoft.com/en-us/library/bb491012.aspx [Hozzáférés: 2012.05.01.] [88] Pásztor M., Számítógéphálózatok - 2. előadás", itk.ppke.hu, 2012. [Online]. Available: http://users.itk.ppke.hu/~mpasztor/netora/2012-tavasz/eloadas-2.html. [Hozzáférés: 2012.04.23.] [89] “Arp”, 2012. [Online]. Available: http://technet.microsoft.com/enus/library/bb490864.aspx. [Hozzáférés: 2012.04.18.] [90] “Ping”, 2012. [Online]. Available: http://technet.microsoft.com/enus/library/bb490968.aspx. [Hozzáférés: 2012.04.18.] - 76 -

[91] Pásztor M., Számítógéphálózatok - 7. előadás", itk.ppke.hu, 2012. [Online]. Available: http://users.itk.ppke.hu/~mpasztor/netora/2012-tavasz/eloadas-7.html. [Hozzáférés: 2012.05.12.]

- 77 -

15 Mellékletek CD lemez, amely tartalmazza a következőket: •

a jelen dolgozatot elektronikus formában,

•

az aláírt diplomaterv-témabejelentő lap másolatát,

•

az elkészült HTTP szerver program forráskódját.

- 78 -