RFC (Sun SPOT): Forskelle mellem versioner
Fra DAMNWiki
Spring til navigationSpring til søgning
David (diskussion | bidrag) No edit summary |
David (diskussion | bidrag) No edit summary |
||
| (5 mellemliggende versioner af 2 andre brugere ikke vist) | |||
| Linje 6: | Linje 6: | ||
=== Baggrund === | === Baggrund === | ||
# 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? | # 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. | |||
# 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? | # 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 === | |||
# Hvornår køres routing algoritmerne? (Afsnit omkring basisstationen) | |||
=== Design === | === Design === | ||
# 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. | # 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 === | === Uden afsnit === | ||
# Hvor skal ''netværk'' defineres, og skal det overhovedet gøres? | # Hvor skal ''netværk'' defineres, og skal det overhovedet gøres? | ||
#* I indledningen | |||
# Hvor skal vi beskrive et netværk som en graf, en rute som en sti og en mængde af ruter som et træ? | # 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. | |||
# Må jeg godt gå i seng nu? | # Må jeg godt gå i seng nu? | ||
#* Ja | #* 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. | |||
[[Category:Sun SPOT]] | [[Category:Sun SPOT]] | ||
[[Category:Rapport (Sun SPOT)]] | [[Category:Rapport (Sun SPOT)]] | ||
Nuværende version fra 12. jun. 2008, 23:01
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
- 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.
- 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
- Hvornår køres routing algoritmerne? (Afsnit omkring basisstationen)
Design
- 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
- Hvor skal netværk defineres, og skal det overhovedet gøres?
- I indledningen
- 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.
- 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.
