RFC (Sun SPOT)

RFC står for Request For Comments og er den gængse metode til at beskrivelse internet protokoller og teknologier. F.eks. AODV.

Denne artikel er spørgsmål, som vi skal huske at drøfte.

Rapport

Baggrund

1. Vi har skrevet, at netværkslagene for Sun SPOT'en skal beskrives under analysen. Men burde den slags konkrete ting ikke være under baggrund, hvor vi beskriver teknologien bag Sun SPOTs? Eller skal API beskrivelser generelt være i analysen?
   • Det skal stå i analyse afsnittet som det gør nu, da det omhandler en konkret undersøgelse af Sun SPOT'ens API.
2. Sektionen omkring AODV er næsten afskrivning fra det papir, som Hans Henrik har udleveret til os. Er det ok, eller skal vi droppe at gå i detaljer med det?
   • Afventer svar fra Hans Henrik efter mødet den 12. juni

Kravsspecifikation

1. Hvornår køres routing algoritmerne? (Afsnit omkring basisstationen)

Design

1. Jeg synes ikke, design pattern skal have et selvstændigt afsnit. Det virker unaturligt ved nærmere eftertanke. I stedet skal vi indføre design patterns de relevante steder.
   • Forslag vedtaget. Det bliver skrevet ind de steder, det er relevant i design- og implementeringsfasen

Uden afsnit

1. Hvor skal netværk defineres, og skal det overhovedet gøres?
   • I indledningen
2. Hvor skal vi beskrive et netværk som en graf, en rute som en sti og en mængde af ruter som et træ?
   • I design afsnittet der hvor vi har skrevet, det skal beskrives.
3. Må jeg godt gå i seng nu?
   • Ja
   • Ved diskussion af problemstillingen, er der opnået en vis uenighed...

Program

Graf

• IGraph er vel som udgangspunkt en orienteret graf. Men vi tegner dog sensor netværket som en ikke-orienteret graf (efter diskussion i starten af projektet, I admit). Er dette noget, vi kan nå at lave om igen? Så der kommer en pil på, hvis der kun kan kommunikeres i én retning men ingen pil, hvis der kan kommunikeres i begge? Det er mest korrekt, eftersom vi kan justere på sendestyrken på alle Sun SPOTs.