Examensarbete
IP4DSP I samarbete med Institutionen för Teleinformatik, Kungl. Tekniska Högskolan Realtidssystem, Enea Data AB
I P 4 D S P Stefan Lindblad
[email protected]
RAPPORT
1(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
Distribution Detta dokument är ej under kontrollerad distribution. Innehavaren ansvarar själv för att den senaste utgåvan av detta dokument används och att inaktuella kopior (utskrifter) förstörs. Senaste version av detta dokument kan hämtas från Internet i PDF1 format på adressen http://www.e.kth.se/~e92_sli/exjobb/rapport/rapport.pdf
Revisionshistorik Revision
Datum
Kommentar
P1.0.0
2000-02-24
Första preliminära utgåvan.
P1.1.0
2000-08-15
Andra utgåvan efter en övergripande omarbetning av rapporten.
P1.2.0
2000-11-19
Slutlig utgåva efter en total översyn.
Förord Det här dokumentet är en rapport över mitt examensarbetet med att ta fram en prototyp till en Internet-kommunikationskomponent för inbyggda system med digitala signalprocessorer. Rapporten beskriver prototypen och miljön runt omkring, samt allmänt om problem och lösningar för en minnessnål kommunikationskomponent.
1
Portable Document Format (PDF). Läses med hjälp av t.ex. Acrobat Reader, som kan hämtas gratis från Adobes hemsida på adressen http://www.adobe.com
RAPPORT
2(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
Innehållsförteckning 1
Inledning ......................................................................................... 3 1.1 Rapportens struktur ................................................................. 3 1.2 Hur bör rapporten läsas............................................................ 3 1.3 Definitioner och förkortningar.................................................. 3 1.4 Referenser................................................................................ 5 2 OSE for DSPs ................................................................................. 6 2.1 DSP......................................................................................... 6 2.2 Kompilatorer ........................................................................... 6 2.3 Operativsystem ........................................................................ 6 2.4 Realtid ..................................................................................... 7 2.5 Förutsägbarhet......................................................................... 7 2.6 Processer ................................................................................. 7 2.7 Systempoolen .......................................................................... 8 2.8 Signaler ................................................................................... 9 2.9 Emulerad miljö......................................................................... 9 2.10 Byteordning ............................................................................. 9 3 IP4DSP ......................................................................................... 11 3.1 Planering................................................................................ 11 3.2 Krav ...................................................................................... 11 3.3 Flödeskontroll........................................................................ 12 3.4 Protokoll................................................................................ 13 3.5 Signaler ................................................................................. 15 3.6 Processer ............................................................................... 16 3.7 Datastrukturer ....................................................................... 17 3.8 Gränssnitt .............................................................................. 20 3.9 Konfiguration......................................................................... 22 4 Epilog............................................................................................ 23
RAPPORT
3(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
1
Inledning Den här rapporten handlar om mitt examensarbete och beskriver vad det är, vad jag gjort och hur resultatet blev.
1.1
Rapportens struktur Rapporten är uppdelad i fem kapitel med ökande fördjupning i examensarbetet. Första kapitlet är en inledning på rapporten och förklara hur rapporten är uppbyggd och bör läsas, samt definierar förekommande förkortningar. Det andra kapitlet ägnar sig åt att förklara den miljö i vilken examensarbetet är utfört och grundläggande mekanismer beskrivs. Tredje kapitlet beskriver hur examensarbetet är uppbyggt och vilka problem som har lösts, samt hur de lösts. Därefter följer fjärde kapitlet som berättar om mina slutsatser av prototypen. Sista kapitlet är ett index för att lättare kunna hitta nyckelord i rapporten.
1.2
Hur bör rapporten läsas Det är tänkt att personer med skiftande teknisk bakgrund och kunskap inom området ska kunna läsa rapporten med behållning och därför har jag inför tre grader av fördjupning i dokumentet. Varje läsare får själv avgöra vilken fördjupning som passar för varje rubrik. Notera att alla fördjupningarna kanske inte förekommer överallt och att hela stycken kan ha en och samma fördjupning. Materialet i fördjupningarna ersätter inte varandra utan kompletterar varandra, vilket innebär att en person som är väldigt intresserad av rubriken bör läsa alla delar. De tre fördjupningarna är översiktligt, utförligt och detaljerat. Den översiktliga fördjupningen fungerar som en kort sammanfattning av stycket och markeras inte alls. Varje stycke börjar oftast med en översiktlig del. Fördjupningen utförligt markeras av en rand i vänstra kanten av alla de stycken som ingår i den fördjupningen. Den sista och detaljrikaste fördjupningen markeras av en dubbelrand i vänstra kanten av alla de stycken som berörs. Den här nivån tar upp alla egenheter och detaljer som kan vara värda att veta.
1.3
Definitioner och förkortningar Adresserat till alla noder på nätverket broadcast DSP
Digital Signal Processor En specialiserad processor för digital signalbehandling.
DSP OS
Se OSE for DSPs
HTTP
Hyper-Text Transport Protocol
RAPPORT
4(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
ICMP
Internet Control Message Protocol version 4, RFC 792
ID
Identifikationsnummer
IETF
Internet Engineering Task Force Finns på adressen www.ietf.org.
IGMP
Internet Group Management Protocol
IP
Internet Protocol version 4, RFC 791
IP4DSP
Internet Protocol for Digital Signal Processors En förkortning av Internet protokoll för digitala signalprocessorer och namnet på mitt examensarbete.
IP for DSPs
Se IP4DSP
LSB
Least Significant Bit Den bit i ett ord som representerar minst värde.
MSB
Most Significant Bit Den bit i ett ord som representerar störst värde.
MTU
Maximum Transmission Unit
multicast
Adresserat till en grupp noder, oftast bestämt av IGMP.
OSE
Operating System Embedded OSE är ett samlingsnamn på alla olika varianter av Eneas realtidsoperativsystem.
OSE for DSPs
En variant av operativsystemet för DSPer.
OSE Treat
Ett annat namn på OSE for DSPs.
RFC
Request For Comment Alla RFCer kan hämtas från IETFs webbplats.
SLIP
Serial Line Internet Protocol, RFC 1055
TCP
Transmission Control Protocol, RFC 793
TCP/IP
Förkortning av protokollen TCP och IP tillsammans.
UDP
User Datagram Protocol, RFC 768
UDP/IP
Förkortning av protokollen UDP och IP tillsammans.
Unicast
Adresserat till en enda nod
RAPPORT
5(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
1.4
Referenser ∗ Projektplan för IP4DSP spec/ip4dsp-001 Stefan Lindblad ∗ Litteraturstudie för IP4DSP fört/ip4dsp-002 Stefan Lindblad ∗ Specifikation av Protokoll för IP4DSP spec/ip4dsp-003 Stefan Lindblad Samtliga referenser finns att hämta på Internet i PDF1 format på examensarbetets hemsida: http://www.e.kth.se/~e92_sli/exjobb/
RAPPORT
6(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
2
OSE for DSPs Namnet betecknar Eneas egenutvecklade operativsystem för digitala signalprocessorer. IP4DSP är en systemkomponent till operativsystemet.
2.1
DSP Förkortningen står för Digital Signal Processor (även på engelska) och skiljer sig en del från generella processorer i instruktionsuppsättning och arkitektur. Framför allt har DSPer inte alla instruktioner som vanliga generella processorer har. Istället har de ofta speciella instruktioner för att snabba upp vissa typer av beräkningar som t.ex. talkodning, frekvens analys, med mera. DSPer används bara i speciella situationer där det räcker med lite begränsad funktionalitet på processorn mot att den istället kan vara anpassad för just det problemet. Oftast görs begränsningar i arkitekturen för att processorn ska bli billigare. Den kan innebära att mista dataenhet är 16-bitars ord eller att adressutrymmet begränsas till 16-bitars ord. Det är också vanligt att de saknar externt minne och måste begränsa sig till det interna minnet på processorn. Det interna minne brukar vara litet och i storleksordningen 64 kb. De flesta generella processorer använder det interna minnet för mellanlagring av instruktioner och data eftersom det interna minnet är snabbt och oftast kör i samma hastighet som processorn själv. De behöver då inte hämta instruktioner och data från det externa långsammare minnet lika ofta.
2.2
Kompilatorer DSP-tillverkarna utvecklar egna C-kompilatorer för sina DSPer. Det innebär att olika kompilatorer används beroende på vilken DSP-familj som utnyttjas. Kompilatorn från en del tillverkare klarar inte C++ och därför sker den mesta utvecklingen i C. Dessutom är C mer resurssnålt och snabbare än C++. Mitt examensarbete är skrivet helt i C.
2.3
Operativsystem Varje operativsystem tillhandahåller tjänster åt applikationer och drivrutiner. Tjänsterna brukar fylla grundläggande behov som minneshantering, delad körningstid mellan processer, åtkomst av maskinvara, med mera. Genom att göra tjänsterna oberoende av maskinvaran kan applikationer lättare flyttas mellan olika maskinvaruplattformar. OSE Treat är extremt litet, distribuerat och händelsestyrt med hårda realtidskrav och avbrytbara processer. All distribution sker i bakgrunden och är inte synlig för applikationerna. Det innehåller även felhantering och detektering av fel.
RAPPORT
7(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
2.4
Realtid Med realtid menas garantier för att ett system reagerar på en händelse inom en viss kort tidsgräns. För att systemet ska hinna reagera på en sådan händelse måste systemet antingen ha lite att göra eller så måste den kunna avbryta det den håller på med tillräckligt snabbt för att hinna reagera på händelsen i tid. Det hela kompliceras av att ett system kan ha prioriteringar mellan händelser så att händelser med högre prioritet får avbryta händelser med lägre prioritet, men inte tvärt om. När händelsen på högre prioritet är klar påbörjas arbetet på den händelse i systemet som har högst prioritet. Det pratas ofta om hård och mjuk realtid. I hård realtid är det ett katastrofalt fel att inte reagera på alla händelser i tid. Det kan till och med vara så att människoliv hänger på det. I mjuk realtid är det inte katastrofalt att missa en tidsgräns. Det är inte bra, men det är inte ens i närheten av livshotande. OSE for DSPs kan användas i både mjuka och hårda realtidssystem och kan då garantera vissa tidsgränser. Det kan tyckas att alla system är realtidssystem eftersom alla system reagerar inom någon viss stor tidsgräns, men för att vara ett realtidssystem måste tidsgränsen vara känd och garantier ges för att den hålls. Dessutom måste systemet vara byggt så att tidsgränsen minimeras och detta oberoende av om det gäller mjuka eller hårda realtidssystem.
2.5
Förutsägbarhet Med förutsägbarhet menas att ett system ska uppföra sig som förväntat för alla möjliga händelser. Det ska gå att förutspå hur systemets svarstider, resursbehov, med mera påverkas av olika händelser. Uppförandet får alltså inte vara slumpmässigt eftersom det är raka motsatsen till förutsägbarhet. När det är komplicerat att räkna ut exakta resursbehovet så antas oftast värsta fallet, dvs. då resursbehovet är som störst. Det kan förenkla beräkningarna mycket och ett system måste dimensioneras så att det klarar av det största resursbehovet som kan uppkomma i systemet.
2.6
Processer En process utför maskinkod, men för att göra det behöver den utnyttja körningstid på en processor. I ett modernt operativsystem delas körningstiden på processorn upp i många små enheter som fördelas på de processer som vill köra för tillfället. Efter varje enhet av körningstid byts den tidigare processen ut mot en ny som står i kö. Processernas prioritet avgör hur många enheter körningstid de får och högre prioritet får fler än processer med låg prioritet. Tilldelningen av enheterna kan antingen ske under drift dynamiskt eller kan ställas in statiskt i förväg.
RAPPORT
8(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
Det finns även processer som väntar på yttre händelser och de kallas för avbrottsprocesser (engelska: ”Interrupt process”). De avbryter alla andra processer som körs tills de är klara. Alltså är det viktigt att de är snabba så att avbrotten inte märks. Exempel på yttre händelser kan vara data som inkommer på nätverket, en användare som trycker på en knapp eller någon sensor som ger utslag. Varje process har ett eget process-ID som identifierar den och som används för att adressera meddelanden (signaler) till processer. De tre process typerna i OSE for DSPs är prioritetsprocesser, avbrottsprocesser och användarens avbrottsprocesser. Alla avbrottsprocesser har högre prioritet än prioritetsprocesser och avbryter dessa. Det enda som kan avbryta en avbrottsprocess är en annan avbrottsprocess på en högra prioritet och alla avbrottsprocesser körs tills de är klara, vilket innebär att en avbruten prioritetsprocess får inte fortsätta köra förens alla avbrottsprocesser är klara. Skillnaden mellan systemets avbrottsprocesser och användarens avbrottsprocesser ligger i hur de startas. Den tidigare typen kan startas av både signaler och yttre händelser medan den senare bara kan startas av signaler. I OSE for DSPs delas inte körningstiden på processorn upp på ett bestämt tidsintervall utan sker endast i samband med systemanrop eller interrupt. Systemet måste vara formgett så att det är händelsestyrt och tunga beräkningar ligger på en låg prioritet så att systemet kan reagera på händelser. 2.7
Systempoolen Systempoolen är en enkel minneshanterare som är inbyggd i alla OSEvarianter. Det är en global minneshög (engelska: ”global memory heap”) som delas av alla processer. Den delar upp minnet i en eller flera delar, kallade pooler. Varje pool delar ut minnesblock av en av de fördefinierade storlekarna. När ett block väl har fått en storlek kan storleken inte ändras även om minnesblocket frigörs för annars skulle det inte vara förutsägbart. I ett inbyggt system kan inte minnet ta slut eftersom det är förutsägbart och det går därför att garantera att det aldrig används mer minne än det finns plats för. Därför går det alltid att allokera minne och inga felkontroller eller felhantering behövs för minnesbrist. Dock måste även applikationerna vara förutsägbara så att åtminstone en maximal allokeringsgräns finns. En del arkitekturer tillåter även minne utanför processorn och det nås i så fall genom en minneshanterare för externt minne. Oftast finns det väldigt höga tidsgränser för OSE for DSPs så att det tar för lång tid att hämta externt minne och att operativsystemet plus alla
RAPPORT
9(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
applikationerna får dela på den interna minnet i processorn. Det minnet är ofta uppdelat på dataminne och programminne. 2.8
Signaler En signal är ett meddelande som skickas mellan processer. Processerna behöver inte vara på samma värd om en länkhanterare används som kan förmedla signalen mellan olika värdar och det syns inte för processen om meddelandet behövde förmedlas eller inte. Det enda som skiljer är troligen svarstiden som är lite längre i det distribuerade fallet. Signalen är en datastruktur som måste allokeras från systempoolen för att vara global så att flera processer kan läsa den. I datastrukturen måste det första fältet vara ett signalnummer som identifierar vilken typ av signal det är och hur datastrukturen är uppbyggd.
2.9
Emulerad miljö En emulerad miljö är ett program som kan agera så att andra program tror att de kör i en annan miljö än de verkligen gör. Till exempel finns det en emulerad miljö för OSE for DSPs, vilket gör att dess applikationer kan köras under plattformarna Win32, Linux eller Solaris. Det är inte alltid säkert att det finns maskinvara klart när programkoden skrivs och då måste en emulerad miljö användas. Det är oftast lättare att leta buggar i en emulerad miljö eftersom det finns bättre verktyg för de plattformarna. Dessutom har de större plattformarna bättre möjligheter till att ge återkoppling med hjälp av filer och skärmen. De inbyggda systemen saknar ofta filsystem och skärm. Emuleringen kan ske på olika nivåer. Den kan ske på maskinvarunivå och då översätts maskinkoden till något som passar den verkliga miljön. Den kan ske på systemanrops nivå, vilket är betydligt enklare att implementera, och den har då funktioner för systemanropen i den verkliga miljön. Det finn även varianter däremellan. I den emulerade miljön till OSE for DSPs finns alla systemanrop som funktioner i verkliga miljön och det finns även stöd för att anropa minnesmappad maskinvara, sådan som använder minnesadresser i vanliga minnet för att kommunicera med operativsystem och applikationer. Den emulerade miljön ger funktionsanrop för att skriva och läsa från sådan maskinvara och kan via drivrutiner även förmedla dessa till den verkliga miljön. Tyvärr innebär lösningen också att programmen måste anpassas lite för att fungera i den emulerade miljön efter som den inte gömmer maskinvaran från applikationen.
2.10
Byteordning I standarden för Internet protokollet specificeras i vilken ordning varje byte ska skickas. Ett ord i en viss arkitektur kan bestå av en, två, fyra eller fler bytes. Hur ett ord som består av flera bytes lagras i minnet skiljer sig åt i olika arkitekturer beroende på patent och bakåtkompatibilitet. Om den bit
RAPPORT
10(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
med störst signifikans (MSB) har det högsta indexet i ett ord så ser det ut på följande sätt: Big-Endian (Network byteorder) 1-Byte
7- 0
2-Byte 15- 8 |
7- 0
4-Byte 31-24 | 23-16 | 15- 8 |
7- 0
Little-Endian 1-Byte
7- 0
2-Byte
7- 0 | 15- 8
4-Byte
7- 0 | 15- 8 | 23-16 | 31-24 figur 1. Byteordning
Till exempel har Intels arkitekturer byteordningen ”little-endian”, där lägsta minnesadressen för ett ord innehåller LSB och högsta minnesadressen för ordet innehåller MSB. Alltså måste alla dataenheter större än en byte konverteras till ”big-endian” innan det skickas över nätverket eftersom det är nätverkets byteordning. Notera att IP4DSP bara byter byteordningen på protokollinformationen (om det behövs) och inte alls på det data som skickas. Det går inte att byta byteordningen på det data som skickas utan att känna till strukturen på det efter som ordningen beror av ordstorleken. Motorola tog patent på ”big-endian” när de skapade sina första mikroprocessorer och tvingade Intel och alla andra att använda annan byteordning. Patentet har gått ut, men på grund av bakåtkompatibilitet så måste alla Intel-processorer ändå använda ”little-endian”. Det finns dock fördelar med ”little-endian” gentemot ”big-endian”, för när ett ord förlängs eller förkortas är bittarnas placering i orden är oberoende av ordens längd.
RAPPORT
11(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
3
IP4DSP Det här kapitlet beskriver prototypens uppbyggnad och hur olika problem har lösts i prototypen.
3.1
Planering Jag började projektet med att göra en litteraturstudie och bestämma omfattningen på projektet. Därefter skrev jag en projektplan med en tidsplan för projektet. Tidsplanen hölls inte helt och redovisningen hölls en månad senare än planerat. Det var väldigt svårt att göra en tidsuppskattning eftersom det var så mycket som var nytt för mig. Jag hade aldrig tidigare kommit i kontakt med DSPer, OSE, realtidssystem, med mera.
3.2
Krav Ingen formell kravspecifikation har skrivits för prototypen, men det innebär inte att krav saknas. IP4DSP är bara en prototyp och har inte samma hårda krav som skulle ställas på en produkt. Den är till för att studera vissa mekanismer och lösningar som kanske kommer att kunna användas i en produkt i framtiden. Till exempel saknas krav på prestanda, vilket är en avgörande egenskap för en produkt. Dessutom ingår kanske inte alla protokoll som en produkt skulle stödja. De mål som satts upp för prototypen är uppräknade nedan.
3.2.1
Minnessnål Det första och största kravet på prototypen är minnessnålhet. Det ska inte krävas mycket minne för att köra prototypen och minnesutnyttjandet ska vara förutsägbart. IP4DSP ska köras på en DSP och de har normalt sett väldigt begränsade minnesresurser som prototypen måste dela med operativsystem och andra applikationer.
3.2.2
Realtid Prototypen ska vara realtidsmässig och inte låsa upp processorn eller andra resurser längre än att andra uppgifter hinns med. Trots de låga realtidskraven på IP4DSP får den inte bli en flaskhals så att en massa arbete som den inte hinner hantera köas upp.
3.2.3
Förutsägbarhet Det ska gå att räkna på maximalt minnesutnyttjande och det tillfälliga minnesutnyttjandet ska kunna förutspås vid varje tillfälle. Alla konsekvenser av ett visst handlande måste vara kända.
RAPPORT
12(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
3.2.4
Protokoll Prototypen behöver åtminstone ett protokoll på varje lager i TCP/IPmodellen och vilka protokoll det ska vara är beroende på användningsområde. I prototypen passar protokollen SLIP, IP, ICMP och UDP in bäst, men vissa ändringar är gjorda i protokollen för att de ska bli mer minnessnåla. Dessutom är prototypen terminerande vilket innebär att den aldrig skickar vidare paket utan antingen tar emot dem själv eller kastar dem. Det är tänkt att prototypen ska köras på en DSP och då faller det sig naturligt att det rör sig om realtidsdata. TCP är inte realtidsmässigt eftersom dess flödeshantering med buffring inte är det och protokollet är väldigt oförutsägbart. Det är osäkert om TCP har något användningsområde på en DSP och dessutom krävs det mycket och komplex kod. Därför är inte TCP med i prototypen. På länklagret har det blivit mycket vanligare med PPP än med SLIP, men eftersom prototypen inte har någon nytta av den extra funktionalitet som PPP ger så känns det onödigt att implementera det. Det skulle nog vara intressant att se hur PPP kan göras mer minnessnålt, men det ligger utanför prototypen att prova det.
3.3
Flödeskontroll Flödeskontroll behövs för att reglera arbetsbelastningen så att ingen del av systemet får mer arbete än den klarar av. Det måste finna något sätt att begränsa flödet av arbete så att det inte inträffar och om det skulle inträffa även tillfälligt så låser det upp en massa resurser som inte kan utnyttjas innan arbetet är gjort. Det är viktigt att det är den process som ska utföra arbete på något data som bestämmer takten på inkommande data så att minne inne låses upp i väntan på att bli behandlat. I så fall är det bättre att stoppa flödet av nytt data så att det som finns kan behandlas.
3.3.1
Applikationer Flödeskontrollen i IP4DSP fås genom att varje applikation skickar in en färdigallokerad buffert till varje socket den vill lyssna på. Bara om det finns någon buffert i en socket kan data tas emot på den socketen, och då bara så mycket utrymme som bufferten har.
3.3.2
Drivrutin för inkommande trafik För varje paket som inkommer hämtas eller skapas en buffert för protokollhuvuden, som skickas till IP4DSP där beslutet om paketet ska tas emot eller inte fattas. Om paketet ska och kan tas emot hämtas buffert för paketdata från en socket och skickas till drivrutinen för att läsa resten av paketet. Annars måste paketet kastas. Den inkommande trafiken begränsas
RAPPORT
13(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
endast av att varje drivrutin bara kan ta emot ett paket åt gången och tillgången på buffertar i socket. 3.3.3
Drivrutin för utgående trafik När en applikation skickar ett paket till IP4DSP hämtas eller skapas det en buffert för protokollhuvuden och sedan skickas paketdata och protokollhuvuden vidare till drivrutinsprocessen för utgående trafik där arbetet köas tills det kan skrivas. Varje drivrutin kan bara skriva ett paket åt gången till nätverket för att sedan fortsätta med nästa paket. Det finns alltså ingen flödesbegränsning i hur många paket som kan vara köade samtidigt och det är upp till applikationerna att se till att inte för mycket resurser är låsta i kön.
3.4
Protokoll De protokoll som är implementerade i prototypen är uppräknade och förklarade i underrubrikerna till denna. Alla protokollen följer inte nödvändigtvis de standarder som är framtagna utan kan skala bort funktionalitet som är oväsentlig för prototypen och ger en vinst i minnesåtgång. Det står förklarat under varje rubrik vilka avsteg som är planerade och vilka effekter de får. I princip ingår det ett protokoll på vart och ett av de lagren i TCP/IP modellen. Det är SLIP i länklagret, IP i nätverkslagret och UDP i transportlagret, samt ICMP i transportlagret.
3.4.1
SLIP Protokollet SLIP, som står för ”Serial Line Internet Protocol”, är egentligen ingen standard utan den ansågs vara för enkel för att få bli en standard. Däremot är protokollet vedertaget och har använts flitigt även om de flesta gått över till PPP numera. SLIP är ett länklagerprotokoll och beskriver hur paket kan skickas över en seriell fysisk förbindelse mellan två noder. Över förbindelsen skickas en ström av bytes och SLIP kan i den här strömmen säga var ett paket börjar och slutar. Det gör den genom att definiera en viss byte som en stoppvärde. Den finns i början och slutet av varje paket. Eftersom stoppvärdet inte får förekomma inuti ett paket så utnyttjar SLIP en teknik som kallas ”Escaping”, vilket innebär att sekvenser av två byte definieras för att representera förbjudna värden inom ett paket. Varje sådan serie måste börja med kontrollvärdet som också det är ett förbjudet värde. Att ersätta vissa bytes i ett paket till en sekvens med två bytes är det som kallas ”Escaping”. Att utföra det här arbete är väldigt enkelt och get väldigt lite kod. PPP fungerar på samma sätt även om den har otroligt mycket mer funktionalitet
RAPPORT
14(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
inbyggt, men SLIP passar bra i prototypen eftersom den gör det huvudsakliga arbetet på ett enkelt och minnessnålt sätt. 3.4.2
IP ”Internet protocol” som förkortningen IP står för erbjuder anslutningslös och opålitlig förbindelse av datagram över ett paketväxlat nätverk, där datagram är ett block av data före fragmentering eller efter ihopsättning. Det finns idag två versioner av protokollet och det är version 4 och 6. IPv4 som version 4 kallas är fortfarande den vanligaste versionen och används på Internet. Den senare (version 6) kommer på sikt att ersätta version 4, men inte än på ett tag. Prototypen kommer därför bara att hantera version 4. Varje nod i ett IPv4 nätverk måste kunna ta emot datagram på minst 576 bytes i ett eller flera stycken. I IPv4 finns det flera tillval som i de flesta fall är gamla och oanvända. Enligt RFC 1122 som beskriver kraven på varje Internetnod så står det att alla tillval kan ignoreras förutom vägval. Det är inte vanligt att specificera vägval och det har inte så stor användning när det inte får plats så många noder i listan. För prototypens del finns det ingen anledning att ta med vägval och därför finns det inga tillval till IPv4 kvar i IP4DSP. IP4DSP kommer inte att tillåta fragmentering för att det inte är förenligt med den minnesmodell som används i prototypen. Det är endast det första fragmentet som innehåller transportinformationen som behövs för att kunna avgöra vart ett paket ska. Om prototypen inte vet vart fragmentet ska kan den inte hämta minne för att lagra det och fragmenten behöver inte komma i rätt ordning. Det finns också en risk att något fragment går förlorat och det krävs då något sätt att avgöra när det har skett och sedan göra något åt det. Att ta emot fragment betyder att minne låses upp tills alla fragment har inkommit och minnesmodellen måste kringgås för att lagra fragmenten temporärt i väntan på att första fragmentet kommer så att en buffert kan hittas. Numera är det dessutom ovanligt med nätverk som inte måste fragmentera paket under 576 bytes och den främsta tillämpningen för prototypen är för många små paket.
3.4.3
ICMP Förkortningen ICMP står för ”Internet Control Message Protocol” och används för att skicka kontrollmeddelanden mellan IP-noder. Kontrollmeddelandena är uppdelade i de två kategorierna felmeddelanden och informationsmeddelanden. Protokollet ligger i transportlagret, men används av IP för att skicka felmeddelanden, som t.ex. ”Destination Unreachable”, ”Time Exceeded” och ”Parameter Problem”. Det vanligaste informationsmeddelandet är ”Echo” och används ofta för att kontrollera det går att skicka meddelanden till en viss nod. När en nod får ett sådant meddelande måste den svara med samma meddelande fast ändra det från ett frågemeddelande till ett svarsmeddelande. Programmet ”ping”
RAPPORT
15(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
använder ”Echo” meddelandet för att visa svarstider på varje anrop till noden. Enligt RFC 1122 (RfIH) så måste endast ”Echo” och de två ”Source Routing” meddelandena hanteras, men i IP4DSP är det bara ”Echo” meddelandet som hanteras, eftersom IP4DSP alltid är en slutnod och därför inte behöver skicka meddelanden vidare. Den begränsningen gör att antingen måste noden vara sista noden i varje ”Source Route” eller så ska den inte ha paketet alls. Därför hanteras det inte. 3.4.4
UDP Ett annat protokoll i transportlagret är ”User Datagram Protocol”, som förkortas UDP. Det är ett väldigt enkelt protokoll och ger endast otillförlitlig överföring mellan applikationer över ett nätverk. De flesta tillämpningar som använder UDP har tidskrav på sina överföringar och om tidsgränserna inte hålls är de inte intresserade av informationen eftersom den då har blivit gammal. Några exempel på detta är talöverföring, radioutsändningar och strömmandevideo över Internet. Det enda som UDP tillför ett IP paket är identifiering av applikationer och felkontroll på datat i paketet.
3.5
Signaler OSE for DSPs är signalbaserat och det innebär att processer i systemet utbyter data med varandra genom att skicka signaler emellan sig. En signal är ett kort meddelande som innehåller en datastruktur med ett signalnummer som första post. IP4DSP definierar fem signaler som används för kommunikationen med drivrutiner och applikationer.
3.5.1
Buffertsignal En buffertsignal används för att lagra applikationsdata och information om destination, samt applikationens socket. Sådana buffertsignaler skickas till IP4DSP för att ta emot eller skicka applikationsdata. En applikation skapar så många buffertsignaler som den vill kunna ta emot eller skicka data i. Har en applikation inte skapat en buffertsignal och skickat in den till IP4DSP kan den inte heller ta emot något data. När en buffertsignal skapas så ska den göras så stor att den kan innehålla så mycket data som applikationen vill kunna ta emot eller skicka åt gången. Eftersom en applikations alla buffertsignaler måste allokeras för användandet kan den enkelt veta hur mycket minne som går åt för IP4DSP. Alla buffetsignaler som skickas till IP4DSP kommer tillbaka till applikationen då de använts eller då applikationens socket tas bort.
RAPPORT
16(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
3.5.2
Adaptersignal Adaptersignaler används för att skapa eller radera en koppling mellan IP4DSP och drivrutinen för en adapter i systemet. Signalen ger även möjlighet för att visa eller ändra inställningarna för en sådan koppling. Varje drivrutin för en adapter måste skapa en sådan koppling i IP4DSP för att kunna utnyttjas av IP4DSP. Det finns inget sätt för IP4DSP att konfigurera drivrutinen utan det måste göras innan en koppling skapas mot IP4DSP. En applikation kan använda denna signal för att ta reda på eller ändra inställningarna hos en koppling mot en adapters drivrutin.
3.5.3
Socketsignal En Socket är en koppling mellan en applikation och IP4DSP. Signalen skickas för att skapa, radera och konfigurera en socket. För att skapa en socket behövs ett protokoll handtag, ett adapter handtag och ett IP-nod handtag, samt beroende på protokoll ett port nummer. Applikationen får då tillbaka ett socketdata handtag som senare används i buffertsignalen för att skicka eller ta emot med de här inställningarna.
3.5.4
Protokollsignal En protokollsignal bär alla protokollhuvuden i sin buffert. Genom att lagra applikationsdata och protokolldata i skilda buffertar behöver inget onödigt utrymme gå till spillo, eftersom det mesta av protokollinformationen är ointressant för applikationerna och därför kan tas bort. Utifrån en sådan här signal kan IP4DSP bestämma exakt vilken socket ett inkommande paket ska till och en buffert kan hämtas därifrån. När ett paket inkommer till en adapter så hämtar den en protokollsignal från IP4DSP. I signalen lagras all protokollinformation, som sedan skickas till IP4DSP. Den informations som är lagrad i signalen räcker för IP4DSP ska kunna hitta motsvarande socket och hämta en buffertsignal därifrån.
3.6
Processer Prototypen IP4DSP består av två prioritetsprocesser, en för kärnan och en för lokal återkoppling. För att kunna skicka eller ta emot data förutom genom lokal återkoppling så behövs det även drivrutiner för kommunikationsadaptrar och sedan behövs det även prioritetsprocesser för alla applikationer som ska använda IP4DSP.
3.6.1
Applikationer Varje applikation körs i minst en prioritetsprocess och eftersom gränssnittet mot IP4DSP är asynkront och signalbaserat kan det räcka med bara en process för att hantera applikationen och kommunikationen.
RAPPORT
17(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
3.6.2
IP4DSP Kärnan i IP4DSP körs i en enda prioritetsprocess. Den sköter kommunikationen med drivrutiner och applikationer, samt hanterar alla protokollen som ingår. Processens prioritet kan anpassas efter hur pass viktigt det är med kommunikationen.
3.6.3
Lokal återkoppling Lokal återkoppling (engelska: ”Loopback”) körs i en och samma prioritetsprocess för både inkommande och utgående kommunikation, eftersom den bara skickar vidare allt utgående till inkommande. För att skickas vidare måste allt data kopieras eftersom alla buffertar måste återlämnas.
3.6.4
Drivrutiner Normalt sett är drivrutinen för adaptern uppdelar i en avbrottsprocess för inkommande trafik och en avbrottsprocess för utgående trafik, om adaptern kan hantera båda samtidigt, vilket kallas ”full duplex”. Om adaptern inte klarar båda samtidigt kan en avbrottsprocess räcka, vilket kallas ”half duplex”.
3.7
Datastrukturer Här förklaras de viktigaste datastrukturerna i IP4DSP. Varje underrubrik representerar en datastruktur och talar om dess användningsområde och dess huvudsakliga innehåll. För att kunna nå varje datastruktur används antingen så kallade handtag, vilket egentligen är en pekare till datastrukturen eller så används ett identifieringsnummer, förkortat här under som ID. Vilken typ av datastruktur som används är helt beroende på i vilket sammanhang den ska användas. De två huvudsakliga typer av datastrukturer som förekommer i IP4DSP är fält och listor. Ett fält är en lång rad med på varandra följande poster av samma storlek. Med ett index går det snabbt och lätt att hitta en viss post i fältet. Den som bara har indexet kan inte få tag på posten utan att även ha fältet, vilket innebär att posten är säker från modifikation av andra än de som har tillgång till fältet. Det är även lätt att ta bort en post genom att markera den som oanvänd, men den tar då fortfarande upp plats i fältet och det går inte att minska storleken på fältet om det finns datastrukturer med högre index i fältet. Med en omallokering går det att lägga till extra poster i fältet efter som de tidigare indexen inte ändras och att dessa är oberoende av fältets placering i minnet. Det sämsta med den här typen av fält är att de inte går att sortera på något snabbt och enkelt sätt. En lista är löst sammanhängande poster där en post utgör början och den har ett handtag till nästa post i listan. Med ett handtag är det enkelt att nå
RAPPORT
18(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
en viss post i listan. Den som har et handtag kan direkt komma åt allt data som är lagrat i den posten och alla som kommer därefter. Det bästa med en lista är att det är väldigt lätt att lägga till eller ta bort poster ur listan om den inte behöver sorteras. Även om posterna behöver sorteras så går det ganska så fort eftersom det är bara ordningen som ändras, dvs. vilken post som är nästa post efter en viss post. Datastrukturen är här utökad med en pekare till nästa post i listan, vilket på en DSP ofta är två bytes. 3.7.1
Adapterdata Adapterdata är den datastruktur som lagrar allt som IP4DSP behöver veta om en adapters och dess drivrutiner. Datastrukturen skapas då en adapters drivrutiner registrerar sig hos IP4DSP och är sedan direkt åtkomliga för applikationerna. Ursprungligen lagrade jag alla adapterdata i ett fält. Eftersom adaptrar normalt bara läggs till i början och aldrig tas bort så gör det inget om det tar lite tid att lägga till nya adaptrar. Nu har jag dock gått över till att använda en lista, men det är bara för att jag använder en lista i många andra fall och kan spara in på lite data genom att göra hanteringen gemensam. Alltså används handtag för att snabbt komma åt datastrukturen. Adapterdata lagrar information om status, MTU, IP-nodslista, drivrutiner för in- och utgående trafik.
3.7.2
IP-noddata Internet Protokollet kräver att varje nod i nätverket bara ska ta emot data som är adresserat till noden, eller till hela subnätet, eller till hela nätverket. I alla andra fall måste paketet kastas eller skickas vidare. Det är alltså tre parametrar som måste vara kända för att kunna avgöra om ett paket är adresserat till den här noden och det är dess IP-adress, subnätmask och nätverksmask. En IP-adress skrivs ofta som fyra talpar separerade med punkter, som t.ex. IP-adressen (”127.0.0.1”) för lokal återkoppling på varje nod. Hela nummerserien för IP-adresser är uppdelad i fem kategorier, uppräknade från A till E, där den sista används för multicast och IGMP. Till varje annan kategori hör en nätverksmask som avgör största möjliga subnätmask och nätverkets broadcast adress. Alltså räcker det inte med att bara spara själva IP-adressen utan även subnätmasken måste sparas, för annars kan det inte avgöras om ett paket är skickat som broadcast till hela subnätet. I IP4DSP kallas IP-adressen tillsammans med subnätmasken för en IP-nod och flera sådana kan kopplas till varje adapter så att den samtidigt kan lyssna på flera adresser. Det kan vara bra om den ska kunna ta emot multicast och unicast eftersom de har
RAPPORT
19(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
olika nummerserier. Alla IP-noder till en adapter lagas i en lista i dess adapterdata. Maskerna avgör vilken del av IP-adressen som tillhör nätverket och subnätet, samt noden. Om nätverksadressen stämmer och resten av bittarna är ettor så är det ett broadcast på nätverket. Om hela subnätsadressen stämmer och resten av bittarna är ettor så är det ett broadcast på subnätet. Om hela nodens adress stämmer är det ett unicast till noden. 3.7.3
Transportprotokollsdata I IP4DSP kan protokoll i transportlagret läggas till eller tas bort under drift. Alltså har IP4DSP ett funktionsgränssnitt mot alla transportprotokoll, där IP4DSP anropar olika funktioner i transportprotokollet för att utföra visst arbete. Alla sådana funktioner och andra data om protokollet lagras i en datastruktur som kallas transportprotokolldata. De sparas i en lista i IP4DSP. De funktioner som IP4DSP anropar i transportprotokollet är inkommande paket, utgående paket, validering, initiera protokoll och protokollhuvudets längd.
3.7.4
Socketdata Benämningen socket, som är ett engelskt uttryck, användes först i BSD2 och har efter det börjat användas överallt för att beskriva de två parametrarna IP adress och portnummer. En socket identifierar en applikation på en dator på Internet. Till exempel används portnummer 80 för protokollet HTTP, som är det surfprotokollet alla webbläsare använder. En socket måste skapas av varje applikation för att kunna ta emot eller skicka data med IP4DSP. Dessutom måste socketen fyllas med buffertar för att kunna ta emot data. Handtag till socketdata lagras i ett fält med fix storlek, som är en tvåpotens. Det maximala antalet sockets är alltså begränsat till fältets längd. Ur socketdata räknas ett index fram från fyra parametrar och på det indexet lagras handtaget. Om indexet är upptaget ökas indexet med ett tills ett ledigt index hittas. I värsta fallet måste alla index genomsökas efter rätt socketdata, men oftast går det fortare. Anledningen till att indexet räknas fram är att det ska gå fortare att hitta rätt socket för ett inkommande paket. I paketet ingår nämligen de fyra parametrarna och då kan indexet lätt räknas ut. De fyra index beräkningsparametrarna är portnummer, protokollnummer, handtag till adapterdata och handtag till IP-noddata.
2
Berkeley Software Distribution. Se www.freebsd.org
RAPPORT
20(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
3.8
Gränssnitt Alla yttre gränssnitt är signalbaserade. Med yttre menar jag gränssnitt som utnyttjas av andra processer än IP4DSP. Det finns ett internt gränssnitt som inte använder signaler, men som ändå är värt att nämna: Transportgränssnittet. I underrubrikerna förklaras hur gränssnitten ska användas inte exakt hur de ser ut.
3.8.1
Applikationer En applikation måste alltid börja med att skapa en socket. Därefter har de möjlighet att lagra buffertar i socketen för att ta emot data i och skicka buffertar från socketen. Det finns ingen möjlighet att ändra inställningarna i en socket och skulle förutsättningarna ändra så tas socketen bort och alla lagrade buffertar återsänds till applikationen. Detsamma sker när applikationen väljer att radera en socket som den skapat. Applikationerna förväntas känna till vilka adaptrar som är anslutna, men kan även lista alla adaptrar och deras inställningar med hjälp av signaler till IP4DSP. Om en applikation så vill kan den även lägga till eller ta bort IPnoder hos en adapter. När en socket skapas så knyts den till en viss adapter och IP-nod och kan inte använda något annat. En ny socket måste skapas om andra inställningar ska användas. Dessutom binds socketen till ett visst transportprotokoll och det kan inte heller ändras. När som helst kan en applikation få inkommande data skickat till sig så fort som det finns minst en lagrad buffert i dess socket. I bufferten ingår endast fjärrnodens IP-adress och port från det protokolldata som mottogs, men det är fullt tillräckligt för att identifiera sändarapplikationen på fjärrnoden. Det är samma två parametrar som sätts av applikationen innan en buffert skickas till en socket för att gå ut på nätverket. Om inget transportprotokoll används så ignoreras portnummret eftersom det inte används i det protokollhuvud som sänds ut på nätverket. Alla signaler som skickas in till IP4DSP kommer tillbaka. Det gäller alla signaler även buffertsignaler och andra signaler för inställningar. Tanken är att buffertsignaler ska allokeras i början i den mängd som applikationen klarar att hantera och sedan återanvändas om och om igen tills systemet tas ur drift. Det gör att applikationen alltid vet hur mycket minne den har att röra sig med och att det aldrig kan bli mindre eftersom det redan är allokerat. Det är också det som ger en flödeskontroll genom att om en applikation inte hinner med att behandla sina databuffertar så fylls de upp och tar slut, vilket innebär att data kommer att slängas till det finns någon ledig buffert att fylla på med data i. Systemet blir alltså självreglerande och det är upp till konstruktören att anpassa antalet buffertar så att det blir lagom många.
RAPPORT
21(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
3.8.2
Transport Protokoll Gränssnittet gör att alla transportprotokoll kan hanteras på samma sätt. De funktioner som behövs återfinns i datastrukturen för transportprotokollet. Protokollfälten i IP huvudet avgör vilket transportprotokoll som används. Hittas inte något transportprotokoll med samma protokollnummer som i fältet i IP huvudet kan inte paketet tas emot och ett ICMP felmeddelande skickas tillbaka. Se Transportprotokollsdata för mer information om vad som ingår i datastrukturen. Allt som krävs för att lägga till ett nytt transportprotokoll är att gränssnittet implementeras och att sedan en signal skickas till IP4DSP så att Transportprotokollsdata kan skapas. Efter det är det fritt att använda protokollet.
3.8.3
Drivrutiner IP4DSP förutsätter att alla adaptrars drivrutiner startas och initieras, samt initierar sin adapter, innan den registrerar sig hos IP4DSP, för så fort en drivrutin är registrerad så kan den användas. Gränssnittet mellan IP4DSP och drivrutiner är byggt på signaler. En drivrutin är typiskt en avbrottsprocess som väntar på avbrott från sin adapter. Den har då en väldigt hög prioritet och avbryter allt annat arbete. Det är därför viktigt att den gör sitt jobb så fort som möjligt för att sedan låta andra processer fortsätta arbeta medan den väntar på ytterligare avbrott. När en drivrutin för inkommande data får ett avbrott från sin adapter så hämtar den antingen en sparad protokollbuffert eller skapar en ny. Den bör ha två eller fler som är allokerade redan innan den registreras. När protokollen är inlästa skickas protokollsignalen till IP4DSP och drivrutinen är klar med del ett. Drivrutinen väntar nu på att IP4DSP ska analysera protokollhuvudena och hitta en buffertsignal att fylla med resterande data i paketet. Antingen får drivrutinen en buffertsignal och läser in resten av paketet i den eller så får den tillbaka sin protokollsignal och ska kasta resten av det inkommande paketet. Dessutom kan det vara så att drivrutinen ska läsa in ytterligare 64 bytes av paketet för att skicka tillbaka i ett ICMP felmeddelande. Om paketet skulle läsas in så görs det och buffertsignalen skickas tillbaka till IP4DSP för att checksummor och annat ska valideras. Buffertsignalen skickas sedan vidare till applikationen och protokollsignalen återsänds till drivrutinen för att kunna återanvändas för något nytt paket. Det kan vara bra att ha en två protokollsignaler redo eftersom den ena är upplåst av IP4DSP tills buffertsignalen är redo att skickas till applikationen. Det tar en liten stund från dess att drivrutinen har läst hela paketet och protokollsignalen återvänder från IP4DSP och även då ska drivrutinen kunna ta emot paket. För en drivrutin för utgående data så är det lite enklare. Den väntar på något att sända. Först kommer en buffertsignal och sedan dess protokollsignal. När väl protokollsignalen har kommit sätter drivrutinen igång och påbörjar skrivning till adaptern av protokolldata. Data skrivs
RAPPORT
22(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
vanligen till adaptern lite i taget och sedan får den ett avbrott från adaptern när den är redo att ta emot mer data. Där protokolldatat tar slut fortsätter drivrutinen från buffertsignalen applikationsdata. Medan drivrutinen håller på och skriver till adaptern kan det inkomma ytterligare buffertsignaler följt av protokollsignaler för att skrivas på nätverket. För att kunna hantera dessa så måste drivrutinen ha ett kösystem där par av buffert- och protokollsignaler köas efter varandra. Det finns inte någon gräns inbyggt för hur många buffertar som får köas upp utan det är upp till applikationerna att se till att de inte använder allt data för att skicka till en långsam adapter. 3.9
Konfiguration Hur drivrutiner konfigureras ingår inte i IP4DSP. Alla drivrutiner antas vara korrekt konfigurerade och initierade när de registrerar sig hos IP4DSP. Så fort de är registrerade kan de börja användas. Även alla transportprotokoll måste registrera sig hos IP4DSP för att vara brukbara protokoll. De transportprotokoll som inte har registrerats resulterar i ett ICMP-felmeddelande för inkommande paket. IP4DSP behöver ha en prioritetsprocess för kärnan (ip4dsp) och en för lokal återkoppling. Sedan tillkommer det avbrottsprocesser för alla drivrutiner som används och prioritetsprocesser för alla applikationer. Systempoolens poolstorlekar bör anpassas efter storleken på vissa signaler och buffertar som förekommer ofta i IP4DSP. Till exempel allokeras alltid 92 bytes för att ta emot ett inkommande pakets protokollhuvuden. Det är den storlek som behövs för att kunna skicka tillbaka ett ICMPfelmeddelande baserat på det inkommande paketet. För utgående paket allokeras 28 bytes för protokollhuvuden i IP4DSP.
RAPPORT
23(23)
Utfärdare
Datum
Klassificering
Stefan Lindblad
2000-11-19 20:26
Öppet
Godkännes
Dokumentbeteckning
Utgåva
Ulf Bilting, Fredrik Markström & Fredrik Orava
rapp/ip4dsp-004
P1.2
4
Epilog Det är alltid svårt att förutse alla problem som uppkommer i ett projekt, speciellt om det gäller något som är nytt och obeprövat. Att skriva en prototyp ger en mycket bättre överblick över de problem som måste lösas och hur bra en viss lösning blir i praktiken, vilket även inkluderar hur applikationerna i slutänden använder prototypen. Det har under prototypens livstid framkommit olika svagheter och styrkor hos prototypen. Den är till exempel väldigt minnessnål, men tyvärr allt för ofta på bekostnad av prestanda. Det har visat sig att den nog inte var någon bra idé att dela på protokollhuvudsdata och applikationsdata av två anledningar. För det första så går det inte praktiskt att använda DMA eftersom protokolldata och applikationsdata ska lagras på två olika ställen i minnet. För att använda Ethernet media är det i stort sett ett krav att använda DMA för att skyffla data mellan IP4DSP och adaptern. För det andra så innebär det en väntan från att protokolldata är inläst till dess att resterande data kan läsas, eftersom protokoll informationen måste analyseras i IP4DSP innan den kan bestämma vilken socket det gäller och hämta en lagrad buffertsignal från den. Dessutom krävs det två kontextbyten i operativsystemet för att åstadkomma detta och på vissa DSP arkitekturer kan ett kontextbyte ta 200 cykler. Sedan kanske det finns andra processer på högre prioritet än IP4DSP som då får en chans att köra. Det finns en bra lösning på de här två problemen som inte tar bort flödeskontrollen. Låt buffertsignalen innehålla både protokolldata och applikationsdata, vilket möjliggör DMA. Låt inte applikationerna själva allokera sina buffertar utan den måste be IP4DSP att göra det och de buffertar som den allokerar får storleken av MTU hos adaptern. Alltså måste först en socket ha skapats och knutits till en viss adapter. Alla buffertar som applikationen begärt för mottagning av data lagras i adapterns drivrutin och den får då snabbt tag på en buffert. Finns det ingen buffert när den behöver en så måste det paketet kastas. När ett paket är inläst så skickas det till IP4DSP för validering och sedan kontrolleras om det finns någon socket som lyssnar på ett sådant paket och finns det så kontrolleras hur många buffertar den applikationen har i adaptern. Har applikationen minst en buffert så dras en buffert av och buffertsignalen skickas till applikationen. Skulle det inte finnas någon buffert i socketen, eller inte någon socket, eller att paketet är felaktigt så skickas bufferten tillbaka till drivrutinen. De buffertar som applikationen begärt för sändning skickas till den av IP4DSP.
