-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathmariannatenker.txt
53 lines (46 loc) · 2.84 KB
/
mariannatenker.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
In which rotehuet Marianna skriver ned ting hun kommer på når hun faktisk er i gang med å tenke heis.
03.03.16
connection-modulen sånn den er nå funker kanskje, men kan ha problemer pga korte nodenavn.
Cookies var litt knotete.
Men! world_list/1 tar en liste med hosts.
Dvs at vi kan ta inn en host-fil, hente ut alt som svarer ok på names og kjøre world_list på det.
Burde bli mindre knot.
(eller i alle fall mindre kode/mer elegant iom at den andre allerede er laget)
Marianna gjør forsøk på å være Ingvild og lage oversikt:
Moduler:
- Driver (kokes med mindre vi får tid til å skrive egen?)
- FSM
- Connector
- Kø-"objekt" (list_builder-style)
- (denne burde kanskje ha lov til å snakke med distributøren direkte/være del av den)
- Nei! Da kan FSM-manager spørre kø-objektets manager direkte om det er en ordre i etasjen
- det er denne som må flette etter nettverksbrudd
- Kostfunksjon/ordredistributør
- 1001 managere
- Hvordan adresserer vi prosesser på andre noder? Heaven help.
- Én sambands-offisér, dvs hver node har en manager som kun sender til de andre sambands-managerene kanskje?
Ordredistributør, tanker:
Får forespørsel fra stående heis med etasje og last dir.
Sjekker etetr ordre i samme retning, nærmest først, deretter i motsatt retning.
Hvis det er ordre som bør tas, sjekker om det finnes en heis i bevegelse på vei dit.
(burde kanskje få inn alle heisers status samtidig)
Hvis ingen andre heiser er på vei, gi beskjed om å få ræva i gir.
--- 03.04.16 ---
Vedrørende ordrehåndteringen skrevet midnatt fredag:
To heiser bør ikke gå løs på samme ordre
fordi den heisen som ender opp med å ikke få ordren kommer til å kjøre helt til en endeetasje
Det må derfor innføres tiebreaking, f.eks. på PIDs?
Bare et eller annet som identifiserer prosessen som kan brukes til entydig tildeling
f.eks. at den med lavest pid får ordren og den andre leter etter ny ordre
Stopping ved endeetasjer bør uansett implementeres, da ordren en heis er på vei mot kan forsvinne pga fiksing av nettverksbrudd
(hvis ordren som skal håndteres ble håndtert av en annen heis under bruddet)
Evt. stoppe alle heiser på første etasje de kommer til etter nettverksbrudd, og så tildele ordre
(tenker at ordretildelingen kjøres hver gang en heis havner i idle)
Gjenstår: håndtere heiser som ikke kommer frem!
F.eks. en heis som stoppes på vei ned mellom 2. og 1. vil effektivt blokke de andre fra å håndtere 1.
fordi den alltid scorer lavest kost
med mindre det bestilles med command
Timeout-parameter som gir høy kostnad legges til?
En heis som slippes løs vil da potensielt kjøre til endeetasje hvis den ikke finner bestillinger på veien
Heiser bør forøvrig alltid lete etter command-ordre først
Ordrekøen kan sorteres slik at command-puljen kommer først?