-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.txt
100 lines (77 loc) · 11.2 KB
/
README.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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
ΒΑΣΙΛΑΚΗΣ ΒΑΣΙΛΕΙΟΣ ΑΜ : 1115201800018
ΕΝΤΟΛΗ ΕΚΤΕΛΕΣΗΣ :
=====================================
Για την δημιουργία του input_dir :
Στο bash:
./create_infiles.sh inputFile.txt input_dir numFilesPerDirectory
όπου inputFile.txt ένα αρχείο εγγραφών όπως προκύπτει από το script της πρώτης εργασίας.
όπου numFilesPerDirectory ο αριθμός των αρχείων που θα φτιαχτούν σε κάθε subdirectory
όπου input_dir το όνομα του καταλόγου που θα έχει σαν υποκαταλόγους τις χώρες
Για την δημιουργία του εκτελέσιμου :
make travelMonitor
make Monitor
./travelMonitor -m numMonitors -b bufferSize -s sizeOfBloom -i input_dir
όπου numMonitors, ο αριθμός των child Monitor processes, bufferSize το μέγεθος του buffer των pipes,
sizeOfBloom το μέγεθος του bloom filter (τυπικά 100000) και input_dir ο κατάλογος όπως προέκυψε από το script
ΠΕΡΙΓΡΑΦΗ ΑΡΧΕΙΩΝ :
======================================
Τα παρακάτω αρχεία είναι όμοια με την πρώτη εργασία και έχουν ακριβώς την ίδια λειτουργικότητα :
Στα bloom.h, bloom.c υλοποιείται η δομή του bloom filter.
Στα list.h, list.c, υλοποιείται η δομή μιας απλής linked list, και κάποιων χρήσιμων συναρτήσεων σε λίστες.
Στα hash.h, hash.c υλοποιείται η δομής του hash-table, ως ενός πίνακα από λίστες.
Στα skip_list.c, skip_list.h, υλοποιείται η δομή της skip list και οι βασικές συναρτήσεις της.
Στα input_check.h, input_check.c, υλοποιούνται συναρτήσεις που κάνουν έλεγχο για τα command line arguments,
τόσο στην εντολή εκτέλεσης, όσο και στα διάφορα queries που κάνει ο χρήστης.
Στα date.h, date.c, υλοποιούνται χρήσιμες utility functions που κάνουν date handling και σύγκριση ημερομηνιών.
Όσα αρχεία έχουν πρόθεμα m (monitor), αναφέρονται στα Monitor child processes.
Όσα αρχεία έχουν πρόθεμα tm (travelMonitor), αναφέρονται στο travelMonitor parent process.
Στα m_items.h, m_items.c ορίζονται κάποια βασικά structs που χρησιμοποιεί ο Monitor, όπως ένα struct με
την πληροφορία ενός πολίτη , ένα struct με την πληροφορία ενός ιου (δλδ το bloom filter, και τα skip lists που σχετίζονται με τον ιο),
και ένα struct με την πληροφορία μιας χώρας.
Στα tm_items.h, tm_items.c ορίζονται κάποια βασικά structs που χρησιμοποιεί ο travelMonitor, όπως ένα struct με
την πληροφορία ενός ιου (όνομα ιού και bloom filter) , ένα struct με την πληροφορία ενός travelRequest (ημερομηνία, ιός που ελέγχθηκε, accepted/rejected),
και ένα struct με την πληροφορία μιας χώρας ( όνομα, ποιο Monitor την διαχειρίζεται, μια λίστα από travelRequests προς αυτήν τη χώρα).
Σχετικά με τις δομές, οι δομές που κρατάει ο Monitor είναι αντίστοιχες με αυτές που κρατούσε ο monitor της πρώτης εργασίας,
δηλαδή, ένα hash-table με πληροφορίες πολιτών, ένα hash-table με πληροφορίες ιών, και ένα hash-table με πληροφορίες χωρών.
Ο travelMonitor, κρατάει ένα hash-table με πληροφορίες χωρών (όνομα, ποιο Monitor την διαχειρίζεται, μια λίστα από travelRequests προς αυτήν τη χώρα),
και για κάθε Monitor child process κρατάει: (pid, read_fd του pipe, write_fd του pipe και ένα hash-table με πληροφορίες ιών σχετικά με το set χωρών που
διαχειρίζεται ο συγκεκριμένος Monitor).
Στα tm_helper.c, tm_helper.h, υλοποιούνται όλες οι συναρτήσεις που χρειάστηκαν από την πλευρά του travelMonitor,
για να απαντηθούν τα ερωτήματα της εργασίας.
Στα m_helper.c, m_helper.h, υλοποιούνται όλες οι συναρτήσεις που χρειάστηκαν από την πλευρά του Monitor,
για να απαντηθούν τα ερωτήματα της εργασίας.
Στα messages.h, messages.c βρίσκονται συναρτήσεις διαχείρισης των μηνυμάτων, ορίζεται το πρωτόκολλο επικοινωνία κοκ.
Στα m_signals.h, m_signals.c, βρίσκονται συναρτήσεις διαχείρισης των signals για τα Monitor child processes.
Στα tm_signals.h, tm_signals.c, βρίσκονται συναρτήσεις διαχείρισης των signals για τον travelMonitor.
Στο travelMonitor.c είναι η main του travelMonitor. Στο Monitor.c είναι η main του Monitor.
ΕΠΕΞΗΓΗΣΕΙΣ ΥΛΟΠΟΙΗΣΗΣ / ΠΑΡΑΔΟΧΕΣ :
=====================================
Pipes : Το read/write end στον πατέρα (travelMonitor) είναι non-blocking , ενώ στο παιδί (Monitor) μόνο η read είναι blocking.
Με αυτόν τον τρόπο, το παιδί μπλοκάρεται όταν δεν υπάρχει κάτι να διαβάσει, και περιμένει τον πατέρα να του στείλει εντολή.
Ο πατέρας δεν μπλοκάρεται, αλλά πάντα εξασφαλίζει (μέσω loop στη write/read από pipe) ότι γράφεται/διαβάζεται όλο το μήνυμα.
Αυτό συμβαίνει και στο παιδί. 'Ετσι εξασφαλίζεται και η σωστή επικοινωνία, όταν το bufferSize είναι αρκετά μικρότερο από το μήνυμα.
Να τονίσουμε εδώ ότι το bufferSize το θεωρούμε τουλάχιστον sizeof(int) bytes.
Κάθε φορά που ο πατέρας, αναμένει να διαβάσει κάτι από πολλά Monitor child processes, το κάνει μέσω της select, ώστε αν κάποιος
Monitor αργεί, να μην τον περιμένει, αλλά να προχωρήσει στους άλλους πρώτα.
Signals : Ο travelMonitor χειρίζεται τα SIGINT/SIGQUIT/SIGCHLD, μέσω boolean flags. Κάθε φορά που δέχεται ένα από αυτά, ο signal
handler θέτει το αντίστοιχο boolean flag σε 1. Όλα τα άλλα σήματα μπλοκάρονται όταν διαχειρίζεται ένα από τα 3 αυτά σήματα, αλλά και
τα 3 αυτά σήματα μπλοκάρονται όταν ο travelMonitor διαχειρίζεται εντολές, ώστε να μην έχουμε ασυνεπή καταστάσεις. Όταν δεν
διαχειρίζεται εντολές, τα σήματα ξεμπλοκάρονται, και μετά ελέγχεται αν έχουν ληφθεί (boolean flag set to 1) ή όχι (boolean flag set to 0)
και πράττει αναλόγως. Ακριβώς ίδια λογική και στον Monitor, μόνο που διαχειρίζεται τα SIGINT/SIGQUIT/SIGUSR1.
ΤΟΝΙΖΟΥΜΕ ΤΑ ΕΞΗΣ : Υποθέτουμε ότι μόνο ο πατέρας travelMonitor στέλνει SIGUSR1 στα Monitors μέσω της εντολής /addVaccinationRecords.
Αυτό έχει προταθεί και από τον κ.Ντούλα στο piazza στο thread signal.
Σε περίπτωση που δεχθεί SIGQUIT/SIGINT ένα παιδί, δεν κάνει exit, απλά γράφει στο Logfile και συνεχίζει.
Όταν κάποιο παιδί δέχεται SIGKILL, δεδομένου ότι δεν μπορεί να αγνοηθεί, αν βρίσκεται σε κατάσταση επεξεργασίας εντολών, το σύστημα,
μπορεί να βρεθεί σε ασυνεπή κατάσταση. Γιαυτό υποθέτουμε ότι, δέχεται SIGKILL μόνο σε idle καταστάσεις (πχ οταν περιμένει για εντολή),
κάτι που προτάθηκε και από τον κ.Ντούλα στο piazza στο thread signal handlers.
ΓΕΝΙΚΑ ΤΑ ΣΗΜΑΤΑ ΝΑ ΤΑ ΣΤΕΛΝΕΤΕ ΑΠΟ ΕΝΑ ΑΛΛΟ TERMINAL ΓΙΑ ΝΑ ΣΥΓΚΕΚΡΙΜΕΝΟΠΟΙΗΣΕΤΕ ΠΟΙΑ ΔΙΕΡΓΑΣΙΑ ΘΑ ΤΑ ΔΕΧΕΤΑΙ
Πρωτόκολλο επικοινωνίας : Για το πρωτόκολλο επικοινωνίας, έχουν ορισθεί εξαρχής, όλα τα πιθανά μηνύματα μεταξύ travelMonitor, Monitor,
και τους έχει ανατεθεί ένας μοναδικός αναγνωριστικός αριθμός message descriptor (msgd). Κάθε είδος μηνύματος έχει συγκεκριμένο μέγεθος σε
bytes, ενώ έχει και συγκεκριμένη δομή, ώστε να ξέρουν και travelMonitor και Monitor πως να αποκωδικοποιήσουν αυτό που διαβάζουν. Επίσης έχουμε
ένα ειδικό μήνυμα (DONE) που υποδηλώνει το τέλος της επικοινωνίας, και λειτουργεί σαν ACK μήνυμα. ΟΛΑ αυτά
βρίσκονται στα αρχεία messages.h, messages.c Για να έχει κάθε είδος μηνύματος προκαθορισμένο σταθερό μέγεθος, κάναμε κάποιες παραδοχές
σχετικά με το μέγιστο μήκος κάποιων strings. Συγκεκριμένα το μέγεθος του ονόματος ενός subdirectory είναι το πολύ 29, ενός ιού το πολύ 19,
μιας χώρας το πολύ 29, ενός ονόματος, επιθέτου το πολύ 12, και το citizenID το πολύ 5. Οι επιλογές αυτές δεν είναι αυθαίρετες, αλλά είναι οι
περιορισμοί που υπήρχαν και στην εκφώνηση του script της πρώτης εργασίας.
Τέλος να τονίσουμε ότι για δική σας διευκόλυνση, ανάμεσα στις εκτελέσεις, να διαγράφετε τα logfile της προηγούμενης εκτέλεσης.
Επίσης, Η είσοδος κάθε συμβολοσειράς για τα queries γίνεται μετά το : "Waiting for command/task >> "