Prekodet MIP daemon

For kandidater som ?nsker ? teste sin rutingserver uavhengig av egen MIP-daemon tilbyr vi en prekompilert daemon.

Dersom man f?ler at MIP-daemonen fra den obligatoriske oppgaver har store mangler og ?nsker ? utvikle og teste sin rutingserverimplementasjon mot en kjent fungerende MIP-daemon, kan man laste ned v?r prekompilerte daemon her.

 

NB: dersom du velger ? kun teste mot denne utleverte koden og ikke leverer en utvidet utgave av egen MIP-daemon, vil du tape omtrent 20 av 100 poeng p? hjemmeeksamen 1. Vi anbefaler ? bruke prekoden som et hjelpemiddel for ? ferdigstille rutingserveren, f?r man evt. forbedrer egen MIP-daemon.

 

V?r MIP-daemon f?lger alle krav som spesifisert i oppgavetekstene til den obligatoriske oppgaven og hjemmeeksamen 1. Ved feilformattert input fra enten nettverket eller over IPC vil det normalt gis en noenlunde beskrivende feilmelding.

 

Oppdateringer

- Fredag 23.03 kl. 15:19

Oppdatert versjon av MIP-daemonen lagt ut. Retter en feil i lengdeberegningen av rutinginformasjonsmeldinger. Takk til den ?rv?kne studenten som oppdaget dette!

Denne versjonen identifiserer seg som versjon h1.1.1 ved oppstart. Den opprinnelige versjonen hadde ikke noen versjonsutskrift.

- Mandag 02.04 kl. 22:50 (tidligere tilgjengelig p? Piazza)

Ny versjon av MIP-daemonen lagt ut. Retter nok en feil med lengdeberegning, denne gang gjelder det meldinger fra ?vre lag. Takk til den som rapporterte dette.

Denne versjonen identifiserer seg som versjon h1.1.2 ved oppstart.

S?regenheter:

  • Vi har implementert en kringkastingsfunksjon for rutinginformasjon. Rutingserveren kan adressere meldinger til adresse 255 for ? benytte denne.
  • Siden addresse 255 er reservert som kringkastingsadresse, m? denne ikke benyttes ellers. Ved ruteoppslag kan rutingserveren svare med 255 som neste hopp dersom det ikke finnes noen rute som svarer til oppslaget.
  • Det m? eksistere ruter for alle direkte tilkoblede nabonoder. Dette fordi MIP ikke tilbyr noen à priori m?te ? avgj?re om en adresse er p? samme lokale nettverk (kringkastingsdomene). Mao. hvis en node A er koblet direkte til B og C, m? rutingserveren p? A ha installert rutene (B via neste hopp B, C via neste hopp C). Rutingserveren kan oppdage direkte naboer vha. kringkastingsfunksjonen beskrevet over.

IPC-grensesnitt:

Mot applikasjon/?vre lag:

Som spesifisert i den obligatoriske oppgaven. Se ogs? nedenfor. NB: det vil ikke fungere riktig ? koble til mer enn én applikasjon ad gangen.

Mot rutingserveren, for ruteoppslag:

MIP-daemon sender meldinger ad 1 byte som inneholder en MIP-destinasjonsadresse som skal sl?s opp.

Rutingserveren svarer med en 1 byte lang melding som inneholder MIP-adressen til neste hopp. Verdien 255 betyr intet oppslag.

Ruteoppslag m? betjenes i ankomstrekkef?lge.

Mot rutingserveren, for utveksling av ruteinformasjon:

Rutingserveren kan ved behov sende en MIP-nyttelast (data) prefikset av 1 byte som angir destinasjonsadressen. Destinasjonsadresse 255 angir lokal kringkasting over Ethernet, som vil n? direkte tilkoblede naboer.

Ved gyldig innkommende rutingdata (R-bit satt i MIP-headeren) sender MIP-daemon nyttelasten prefikset med 1 byte som angir kildeadressen.

Legg merke til at grensesnittet samsvarer med det for applikasjonen, med tillegg av kringkastingsfunksjonen. De samme restriksjonene ang?ende lengden p? nyttelast gjelder her ogs?.

Alle IPC-socketene er UNIX-domene sockets i SOCK_SEQPACKET modus.

 

Kommandolinjegrensesnitt:

Usage: ./mipdaemon [-d] <Socket_application> <Socket_Route> <Socket_forwarding> <Number of Interfaces> [MIP addresses ...]

Flagget -d angir at man ?nsker ekstra debugutskrifter underveis. Ellers vil man hovedsaklig kun f? evt. feilmeldinger.

<Socket_application> angir stien til UNIX-socketen som applikasjonsen kobler seg p?.

<Socket_route> angir stien til UNIX-socketen som rutingserveren benytter for ? utveklse ruteinformasjon med andre rutingservere i nettverket, formidlet av MIP-daemon.

<Socket_forwarding> angir stien til UNIX-socketen som benyttes til ruteoppslag.

<Number of interfaces> er antall nettverksgrensesnitt ("kort" evt. "porter") som skal kobles opp med MIP adressene som angis til slutt. NB: det kan forekomme at rekkef?lgen p? disse ikke samsvarer mellom kj?ringer av MIP-daemon. Hvilken interface som er tilordnet hvilken adresse skrives ut n?r daemonen starter; hvis dette ikke gir ?nsket topologi kan man pr?ve ? starte daemonen p? nytt.

MIP-daemon oppretter alle sockets som angis og vil normalt rydde opp etter seg. Ved evt. kr?sj eller annen plutselig stopp kan MIP-daemon startes to ganger for ? komme forbi feilmeldinger om eksisterende filer.

Eksempel:

$ ./mipdaemon -d /tmp/a_mip_ipc /tmp/a_mip_rti /tmp/a_mip_rtr 2 10 20

MIP-daemon startes her i debugmodus. Applikasjon kobles p? /tmp/a_mip_ipc, ruteoppslag kobles p? /tmp/a_mip_rtr og ruteutveksling kobles p? /tmp/a_mip_rti. Noden f?r koblet opp to nettverksgrensesnitt som tilordnes adressene 10 og 20 hhv.

Sp?rsm?l, defekter osv.

Sp?rsm?l om bruk og evt. rapporter om defekter el. kan postes p? Piazza. MIP-daemon skal normalt ikke kr?sje, selv ved feil input, men meldinger kan bli "hengende fast" i k?ene ved feil ruting osv. Dette vil ikke hindre nye meldinger i ? ekspederes. Rapporter evt. kr?sj eller andre feil p? Piazza.

OBS: den utleverte programkoden er kompilert for og testet p? VMen vi har delt ut. Det vil antageligvis ikke fungere ? kj?re dette i andre milj?er (egen installasjon av Linux, OS X, osv.) og vi vil ikke tilby assistanse med ? f? det til ? fungere utenfor VMen.

Publisert 20. mars 2018 05:58 - Sist endret 2. apr. 2018 22:52