Κατανεµηµένα Συστήµατα Ι Μάθηµα Βασικής Επιλογής, Χειµερινού Εξαµήνου Τοµέας Εφαρµογών και Θεµελιώσεων. Ποιος είναι ο σκοπός του εργαστηρίου

Transcript

1 Κατανεµηµένα Συστήµατα Ι Μάθηµα Βασικής Επιλογής, Χειµερινού Εξαµήνου Τοµέας Εφαρµογών και Θεµελιώσεων Γιώργος Μυλωνάς Παρασκευή, 7 Νοεµβρίου 2008 Αίθουσα Β3 Προηγούµενο ϕροντιστήριο Tasks: get the job done Ελεγχος παραλληλίας Ειδικά ϑέµατα Active Messages Το περιβάλλον του TinyOS Εισαγωγή στον TOSSIM Command line interface Το γραφικό περιβάλλον TinyViz Στο προηγούµενο ϕροντιστήριο... Ποιος είναι ο σκοπός του εργαστηρίου Είπαµε ότι στο εργαστήριο του µαθήµατος ϑα χρησιµοποιήσουµε το TinyOS Είδαµε κάποιες ϐασικές έννοιες της nesc, της γλώσσας προγραµµατισµού στο TinyOS Βασικές έννοιες: components, modules, configurations, interfaces,... Σύντοµη επανάληψη και πρακτικά ϑέµατα Στο εργαστήριο ϑα υλοποιήσουµε κάποιους απλούς κατανεµηµένους αλγόριθµους Επίσης, ϑέλουµε να µελετήσουµε κάποιες πλευρές της λειτουργίας των κατανεµηµένων συστηµάτων, όπως: 1. Αξιόπιστη και αναξιόπιστη ανταλλαγή µηνυµάτων 2. Κόµβοι που παθαίνουν ϐλάβες κατά τη λειτουργία του συστήµατος 3. Γενικά, συνθήκες που µεταβάλλονται Το TinyOS και η nesc µας προσφέρουν µία ϐάση για να προγραµµατίσουµε

2 TinyOS nesc Πολύ µικρό σε µέγεθος (και απαιτήσεις) Σχεδιασµένο ειδικά για συστήµατα µε λιγοστούς πόρους και προσανατολισµένο στην εξοικονόµηση ενέργειας (ασύρµατα δίκτυα αισθητήρων) Μπορεί να χρησιµοποιηθεί για τη δηµιουργία κατανεµηµένων συστηµάτων (ειδικού) σκοπού Παρέχει ένα σύνολο από υπηρεσίες στο χρήστη (ασύρµατη και σειριακή επικοινωνία, κτλ), οι οποίες ϑα µας ϕανούν χρήσιµες για την υλοποίηση κατανεµηµένων αλγορίθµων Το προγραµµατιστικό µοντέλο του TinyOS ονοµάζεται nesc nesc = network embedded system C Βασίζεται στη C Το TinyOS και οι ϐιβλιοθήκες του είναι γραµµένες σε nesc Εννοιες: component, interface, module, configuration, command, event (µια πρώτη επαφή στο πρώτο ϕροντιστήριο), task (ϑα τα δούµε σήµερα) Components Interfaces Κάθε εφαρµογή στο TinyOS στην ουσία είναι ένα γράφηµα από components Τα components µοιάζουν µε τα αντικείµενα της c++ Υπάρχει όµως ακόµα πιο αυστηρός διαχωρισµός υλοποίησης και διασύνδεσης απ ότι στα αντικείµενα της C++ Μια ϐασική διαφορά είναι ότι στη nesc έχουµε µόνο τοπικό και όχι καθολικό χώρο ονοµάτων Μπορούµε να τα δούµε ως µαύρο κουτί µε καθορισµένες εισόδους/εξόδους Υπάρχει ένας scheduler ο οποίος ϱυθµίζει τη ϱοή ελέγχου σε αυτό το γράφηµα των components Τα components επικοινωνούν µεταξύ τους µόνο µε τη χρήση κάποιων interface (ακµές του γραφήµατος) Είναι διπλής κατεύθυνσης: 1. µε τα command απαιτούµε να εκτελεστεί κάποια λειτουργία από το component, καλούµε από ένα component να εκτελεστεί µια συνάρτηση ενός άλλου component 2. µε τα event το component µας γνωστοποιεί κάποιο συµβάν, µας έρχεται ειδοποίηση ότι τελέστηκε κάποια λειτουργία Ενα interface περιέχει µόνο τη δήλωση command και event (δηλαδή τη δήλωση κάποιων συναρτήσεων) Ενα interface µπορεί, ενδεχοµένως, να περιλαµβάνει µόνο commands

3 Components Υπάρχουν δύο είδη components, τα modules και τα configurations Ενα component µπορεί να παρέχει κάποιο interface. Σε αυτή την περίπτωση πρέπει να υλοποιεί τις εντολές (command) που ορίζει το αντίστοιχο interface Ενα component µπορεί να χρησιµοποιεί κάποιο interface. Σε αυτή την περίπτωση πρέπει να ορίσουµε τί γίνεται όταν έρθει κάποιο event µετά τη χρήση κάποιας εντολής του interface Modules Παρέχουν και χρησιµοποιούν interface για να επικοινωνήσουν µε άλλα component Περιέχουν κώδικα σε C για την υλοποίηση λειτουργίας Μοιάζουν µε hardware component Configurations Ορίζουν ένα πλήθος από components ως οµάδα Ορίζουν τον τρόπο που επικοινωνούν µεταξύ τους αντιστοιχίζοντας εισόδους και εξόδους ανάµεσά τους Μοιάζουν µε τη διασύνδεση των chip σε µια πλακέτα Modules Modules (2) ηλώνουµε ποια interface χρησιµοποιούµε και ποια παρέχουµε µε δυο λίστες uses{... και provides{... ηλώνουµε µεταβλητές που είναι ορατές στο component (frame) Ορίζουµε τις λειτουργίες του component σε κώδικα C Ορίζουµε τις λειτουργίες που αναφέρονται στα interface που παρέχουµε Ορίζουµε τι γίνεται αν µας έρθει µήνυµα (event) µετά από command που χρησιµοποιήσαµε Μπορούµε να χρησιµοποιούµε και να παρέχουµε πολλά interface Κάθε interface µπορεί να προσφέρει διαφορετικό πλήθος λειτουργιών

4 Παράδειγµα interface Παράδειγµα module StdControl interface StdControl { command result_t init(); command result_t start(); command result_t stop(); SendSomething interface SendSomething { command result_t send(tos_msg* m); event result_t senddone();... Configurations Παράδειγµα configuration Περιγράφουν τον τρόπο που διασύνδεονται µεταξύ τους άλλα components (modules ή άλλα configuration) Αν ένα component χρησιµοποιεί το interface A, το οποίο παρέχεται από το component B αυτό πρέπει να δηλωθεί Τρεις δηλώσεις διασύνδεσης: 1. endpoint1 = endpoint2 2. endpoint1 endpoint2 3. endpoint1 endpoint2 (που είναι ίδιο µε το endpoint2 endpoint1 ) configuration D { provides interface X; implementation { components C1, C2; X = C1.X; X = C2.X;

5 Γενική άποψη µιας εφαρµογής σε nesc Παράδειγµα εφαρµογής: Blink Blink.nc Κάθε εφαρµογή σε nesc έχει ένα top-level configuration που: 1. καθορίζει τα components που απαρτίζουν την εφαρµογή 2. πώς διασυνδέονται configuration Blink { implementation { components Main, BlinkM, ClockC, LedsC; Main.StdControl->BlinkM.StdControl; BlinkM.Clock->ClockC; BlinkM.Leds->LedsC; Χρήση µνήµης στο TinyOS Προηγούµενο ϕροντιστήριο Η χρήση των interface για την επικοινωνία των component έχει ως αποτέλεσµα να είναι εντελώς στατική η διασύνδεσή τους Ο µεταγλωττιστής ξέρει ακριβώς ποια component χρειάζονται και τελικά χρησιµοποιεί µόνον αυτά Οι µεταβλητές επίσης καταλαµβάνουν στατικά χώρο στη µνήµη εν υπάρχει malloc ή new κ.ο.κ. Tasks: get the job done Ελεγχος παραλληλίας Ειδικά ϑέµατα Active Messages Το περιβάλλον του TinyOS Εισαγωγή στον TOSSIM Command line interface Το γραφικό περιβάλλον TinyViz

6 Tasks Λογική χρήσης των task Τα task είναι ουσιαστικά µια light µορφή thread Τα χρησιµοποιούµε για να εκτελέσουµε τον κύριο όγκο δουλειάς στο πρόγραµµά µας Τα task έχουν πρόσβαση στις µεταβλητές του component τους Η χρήση task επιβάλλεται σε περιπτώσεις που χρησιµοποιούµε event, γιατί δεν µπορούµε να στείλουµε event από τον κώδικα που υλοποιεί κάποιο command. Πρέπει να ϕτιάξουµε ένα task για να στείλουµε το event. 1. Το component A ϑέλει να εκτελέσει κάποιο command του component B 2. Αρχίζει να εκτελείται το command στο Β, κάνει κάποια σύντοµη εργασία και µετά καλεί ένα task για να εκτελέσει το υπόλοιπο της εργασίας 3. Αυτό το task µπαίνει σε µια ουρά από task 4. Ο scheduler του συστήµατος σε κάποια ϕάση ϑα το εκτελέσει 5. Το task µπορεί να στείλει ένα event πίσω στο component A 6. Το Α ϑα ειδοποιηθεί για το event και ϑα εκτελέσει τον αντίστοιχο κώδικα Μια άλλη οπτική γωνία Παραλληλία και preemption στο TinyOS Μπορούµε να σκεφτούµε µια εφαρµογή TinyOS σαν ένα αυτόµατο Οι µεταβάσεις από τη µια κατάσταση στην άλλη γίνονται µε τη χρήση των command και των event Οι υπολογισµοί σε κάθε κατάσταση (ιδανικά) γίνονται µε τη χρήση των task Αφού τα command και τα event εξυπηρετούν στην µετάβαση από τη µια κατάσταση στην άλλη ϑέλουµε να είναι σύντοµα Τα task ϕροντίζουν για την εκτέλεση των περισσότερων υπολογισµών Ενας scheduler επιβλέπει την εκτέλεση των command, event, task, hardware interrupts Υπάρχουν απλοί κανόνες και προτεραιότητες Τα task είναι ίσα µεταξύ τους: όταν αρχίσει να εκτελείται ένα, δε µπορεί να διακοπεί από άλλο Τα task εκτελούνται µε FIFO τρόπο από µια ουρά Τα event, αντίθετα, έχουν µεγαλύτερη προτεραιότητα από τα task: µπορούν να διακόψουν την εκτέλεσή ενός task Ενα event µπορεί να διακόψει επίσης την εκτέλεση ενός άλλου event

7 Σύνταξη κλήσης command, event, task Παράδειγµα χρήσης task call commandx(...) : καλείται η εντολή commmandx signal eventy(...) : στέλνεται το eventy post taskxy(...) : το taskxy µπαίνει στην ουρά προς εκτέλεση Τα command και τα event εκτελούνται άµεσα Περιµένουµε να πάρουµε κάποιο µήνυµα στείλε τους γείτονές σου και κατάσταση Οταν συµβεί αυτό, στέλνουµε αντίστοιχο µήνυµα event result_t ReceiveMessage.Received(...) {... post sendreply(); return SUCCESS; task sendreply() {... set up a message and then send it... Scheduler Atomic Οταν µεταγλωττίζουµε την εφαρµογή µας, ο compiler ϐάζει το scheduler στον κώδικά µας. Είναι ένας απλός ϐρόχος Αφού η εκτέλεση των task µπορεί να διακοπεί και να παρεµβληθεί άλλος κώδικας, ενδεχοµένως έχουµε συνθήκες ανταγωνισµού Αυτό σηµαίνει ότι προσπαθούµε να έχουµε πρόσβαση π.χ. σε κάποια µεταβλητή ταυτόχρονα από δύο µέρη του κώδικά µας Για να αποφύγουµε αυτές τις καταστάσεις, χρησιµοποιούµε το keyword atomic Ο κώδικας που χαρακτηρίζεται atomic δεν µπορεί να σταµατήσει να εκτελείται αφού έχει ξεκινήσει η εκτέλεσή του από άλλο µέρος του κώδικα Καλό είναι να µην χρησιµοποιούµε συνέχεια το atomic, γιατί καθυστερεί η εκτέλεση του υπόλοιπου κώδικα της εφαρµογής

8 Ανίχνευση συνθηκών ανταγωνισµού Προηγούµενο ϕροντιστήριο Είπαµε ότι η διασύνδεση των component κατά τη διάρκεια της µεταγλώττισης του κώδικα γίνεται στατικά Αυτό επιτρέπει να ανακαλύψει ο µεταγλωττιστής συνθήκες ανταγωνισµού, οπότε µας προειδοποιεί σχετικά Μερικές ϕορές οι προειδοποιήσεις αυτές δεν είναι απόλυτα σωστές Μπορούµε να καθορίσουµε ότι δεν υπάρχει τέτοιο ϑέµα χρησιµοποιώντας το keyword norace Tasks: get the job done Ελεγχος παραλληλίας Ειδικά ϑέµατα Active Messages Το περιβάλλον του TinyOS Εισαγωγή στον TOSSIM Command line interface Το γραφικό περιβάλλον TinyViz Παραµετροποιηµένα interfaces και µετονοµασία Παράδειγµα µετονοµασίας interfaces Χρησιµοποιούνται όταν ένα component επιθυµεί να χρησιµοποιήσει ή να προσφέρει πολλές ϕορές το ίδιο interface Ενα παραµετροποιηµένο interface επιτρέπει την χρήση του από πολλά components, όπου ο χρήστης δίνει µια παράµετρο, π.χ. ένα integer Παραδείγµατα είναι η χρήση timer και η ανάθεση AM handlers Ενα component µπορεί επίσης να προσφέρει ή να χρησιµοποιεί πολλές ϕορές το ίδιο interface δίνοντας του διαφορετικό όνοµα (µετονοµασία) Εστω ότι χρησιµοποιούµε το StdControl για να ελέγξουµε ένα αισθητήρα για ένταση ϕωτός και έναν για ϑερµοκρασία uses { interface StdControl as PhotoControl; interface StdControl as TempControl; Οι δύο παρακάτω δηλώσεις σηµαίνουν ακριβώς το ίδιο: interface ADC; interface ADC as ADC;

9 Παράδειγµα παραµετροποιηµένων interfaces Συµβάσεις ονοµασίας αρχείων Το interface timer έχει ως παράµετρο ένα unsigned 8-bit integer Προσφέρει 256 διαφορετικά στιγµιότυπα του timer για κάθε component που ϑέλει να χρησιµοποιήσει έναν timer configuration ADemo { implementation{ components Main, TimerC, ADemoM.QueryTimer1 -> TimerC.Timer[unique("Timer")];... Αρχεία που περιέχουν κώδικα σε nesc έχουν κατάληξη.nc Το αρχείο που περιέχει τον ορισµό ενός interface, π.χ. του MouseInterface, ϑα έχει όνοµα MouseInterface.nc Το αρχείο που περιέχει το Configuration για το module Mouse ϑα έχει το όνοµα MouseC.nc Το αρχείο που ορίζουµε την υλοποίηση του Mouse ϑα έχει το όνοµα MouseM.nc Για το top-level configuration της εφαρµογής µας δεν προσθέτουµε το C στο όνοµά του Active Messages Active Message Handlers Τα Active Messages είναι ένας µηχανισµός για επικοινωνία παράλληλων και κατανεµηµένων συστηµάτων, ο οποίος ϐασίζεται στην ανταλλαγή µηνυµάτων Τα Active Messages επελέγησαν ως τρόπος επικοινωνίας µεταξύ κόµβων που τρέχουν TinyOS Μέσω του µηχανισµού αυτού µπορούµε να υλοποιήσουµε διάφορους αλγόριθµους για κατανεµηµένα συστήµατα που ϑα δούµε στο µάθηµα Κάθε µήνυµα στον header του περιέχει το όνοµα ενός handler, ο οποίος καλείται από το σύστηµα για να διαχειριστεί το µήνυµα Μοιάζει µε τον αριθµό στα TCP port, π.χ. 80 για το http Ο προγραµµατιστής καθορίζει τον αριθµό του AM handler, υποθέτουµε ότι όλοι οι κόµβοι ξέρουν πώς να χειριστούν τον αριθµό αυτό Στο πρόγραµµά µας καθορίζουµε ποιο κοµµάτι του κώδικα αναλαµβάνει να επεξεργαστεί το µήνυµα µε ΑΜ αριθµό Χ Οταν ϕτάσει ένα µήνυµα µε αριθµό ΑΜ 25, ο scheduler καλεί προς εκτέλεση τον αντίστοιχο κώδικα ιαβάζουµε το payload του µηνύµατος, κάνουµε επεξεργασία και αν χρειάζεται στέλνουµε µήνυµα (προφανώς ανάλογα µε τον αλγόριθµο) Πάνω σε αυτή τη λογική µπορούµε να χτίσουµε τον κατανεµηµένο αλγόριθµό µας

10 ID και ειδικές διευθύνσεις Λογική αποστολής και λήψης µηνυµάτων Κάθε κόµβος του συστήµατος έχει ένα ID αριθµό (τον αναθέτουµε εµείς) Η επικοινωνία µε τους άλλους κόµβους γίνεται µε τη χρήση του αριθµού αυτού Υπάρχουν και µερικές ειδικές διευθύνσεις που µπορούµε να χρησιµοποιήσουµε, όπως η Broadcast διεύθυνση, δηλ. µετάδοση προς όλους τους κόµβους που µας ακούνε Πρέπει να υπάρχει κάποιο πρωτόκολλο δροµολόγησης για multihop επικοινωνία, αλλιώς µιλάµε για 1-hop επικοινωνία Αποστολέας: 1. Εχουµε δεσµεύσει ένα buffer, τον οποίο χρησιµοποιούµε για να αποθηκεύσουµε τα δεδοµένα που ϑα στείλουµε 2. Αποφασίζουµε ποιον AM handler χρησιµοποιούµε (το port του άλλου κόµβου στο οποίο ϑα πάει το µήνυµα) 3. Στέλνουµε το µήνυµα Παραλήπτης: 1. Λαµβάνει το µήνυµα και διαβάζει τον AM handler 2. Καλεί το αντίστοιχο κοµµάτι του κώδικα για να χειριστεί το µήνυµα Παράδειγµα κώδικα για αποστολή µηνύµατος Παράδειγµα κώδικα για λήψη µηνύµατος Εστω ότι ϑέλουµε να στείλουµε ένα Hello µήνυµα στους γείτονές µας. Ορίζουµε στο configuration µας τον ΑΜ handler για το interface SendHelloMsg που ϑέλουµε να χρησιµοποιήσουµε ADemo.SendHelloMsg -> WirelessComm.Send[AM_HELLOMSG]; Ορίζουµε ποιος ϑα είναι ο handler όταν έρθει µήνυµα µε ΑΜ αριθµό Χ AeolusDemoM.AcknowledgeMsg -> WirelessComm.Receive[AM_ACKMSG]; Ορίζουµε τον κώδικα για την αποστολή του µηνύµατος Ορίζουµε τι γίνεται σε αυτή την περίπτωση event TOS_MsgPtr AcknowledgeMsg.receive(TOS_MsgPtr m) { task sendhello() { AckMsg *message = (AckMsg *)m->data; HelloMsg *message = (HelloMsg *)data.data; return m; if (call SendHelloMsg.send(TOS_BCAST_ADDR, sizeof(hellomsg), &data)) return SUCCESS;...

11 Το περιβάλλον που ϑα χρησιµοποιήσουµε Προηγούµενο ϕροντιστήριο Tasks: get the job done Ελεγχος παραλληλίας Ειδικά ϑέµατα Active Messages Το περιβάλλον του TinyOS Εισαγωγή στον TOSSIM Command line interface Το γραφικό περιβάλλον TinyViz Το TinyOS είναι διαθέσιµο για Windows και Linux Το περιβάλλον που ϑα χρησιµοποιήσουµε περιλαµβάνει: τις ϐιβλιοθήκες του TinyOS ενα µεταγλωττιστή (ncc) για κώδικα nesc, ο οποίος ϐγάζει εκτελέσιµο κώδικα για διάφορες πλατφόρµες διάφορα εργαλεία για την ανάπτυξη εφαρµογών TinyOS και άλλα πολλά... :) Μεταγλώττιση κώδικα nesc Εστω ότι έχουµε µια εφαρµογή γραµµένη σε nesc και ϑέλουµε να τη µεταγλωττίσουµε Το σύστηµα προσφέρει µια σειρά από makefile που κάνουν αυτόµατη τη διασύνδεση µε ϐιβλιοθήκες, κτλ. Γενικά, εµείς απλά δηµιουργούµε ένα τοπικό Makefile για να δηλώσουµε ποιο είναι το top component της εφαρµογής µας Μπορούµε να κάνουµε compile για διάφορες πλατφόρµες make <platform> ιαθέσιµες είναι οι πλατφόρµες pc, mica, mica2, micaz. Μας ενδιαφέρει η πρώτη

12 TOSSIM Πλεονεκτήµατα Ο TOSSIM µας προσφέρει ένα ελεγχόµενο εικονικό περιβάλλον για να τρέξουµε τον κώδικά µας Χρησιµεύει στην εξοµοίωση εφαρµογών TinyOS, οι οποίες στην πράξη εκτελούνται σε network embedded συσκευές Ο ίδιος κώδικας χρησιµοποιείται στην εξοµοίωση και στην πραγµατική εφαρµογή Είναι µέρος της διανοµής του TinyOS Είναι ένας discrete-event εξοµοιωτής Μας παρέχει ένα περιβάλλον στο οποίο µπορούµε να ελέγξουµε κάποιες παραµέτρους δυναµικά Μπορούµε να επαναλάβουµε πειράµατα Μπορούµε να τρέξουµε ένα πείραµα µε πολλούς κόµβους Μας δίνεται η δυνατότητα να επικοινωνήσουµε µε αυτό το σύστηµα, στέλνοντας µηνύµατα από κάποια άλλη εφαρµογή Γραφικό περιβάλλον (επόµενη ενότητα) Στην πράξη... Μοντέλο δικτύου (1) Οταν κάνουµε compile δίνοντας make pc, δηµιουργείται ένα εκτελέσιµο αρχείο σε κάποιο υποκατάλογο (/build/pc) Αυτό το αρχείο περιέχει την εφαρµογή µας (ειδικά µεταγλωττισµένη) µαζί µε τον TOSSIM Η εξοµοίωση γίνεται ανάλογα µε τα ορίσµατα που δίνουµε από τη γραµµή εντολών σε αυτό το εκτελέσιµο Με απλά λόγια, ο εξοµοιωτής δηµιουργεί πολλαπλά αντίγραφα της εφαρµογής µας και επιβλέπει την εκτελέση και την επικοινωνία µεταξύ τους ηλαδή, µόνο µία εφαρµογή τρέχει στον εξοµοιωτή Θεωρούµε ότι έχουµε ένα δίκτυο από συσκευές που τρέχουν τον ίδιο κώδικα και επικοινωνούν ανταλλάσοντας µηνύµατα ασύρµατα Αυτές οι συσκευές είναι µέρος ενός κατευθυνόµενου γραφήµατος, όπου οι κόµβοι είναι οι συσκευές Οι ακµές είναι της µορφής (u, v, p), δηλαδή µεταξύ δύο κόµβων u και v έχουµε πιθανότητα p να στείλει ο u ένα bit στον v και να χαθεί Ο εξοµοιωτής παραδίδει τα µηνύµατα στους κόµβους που είναι µέσα στην εµβέλεια µετάδοσης του µεταδότη Τα λάθη στις µεταδόσεις είναι ανεξάρτητα µεταξύ τους Μπορούµε να έχουµε ασυµµετρικές συνδέσεις (p (u,v) p (v,u) )

13 Μοντέλο δικτύου (2) ιαθέσιµες επιλογές Υπάρχουν κάποιες επιλογές όσον αφορά τις πιθανότητες αυτές: 1. Ολα τα bit ϕθάνουν σωστά (κανένα λάθος µετάδοσης) 2. Μπορούµε εµείς να καθορίσουµε τις πιθανότητες αυτές ξεχωριστά την καθεµιά 3. Με ϐάση ένα εµπειρικό µοντέλο ο εξοµοιωτής υπολογίζει τις πιθανότητες αυτές Εστω ότι είµαστε στα Windows και έχουµε το εκτελέσιµο main.exe ίνουµε main.exe [επιλογές] #κόµβων Το πλήθος κόµβων µπορεί να είναι αρκετά µεγάλο Οι κόµβοι πάιρνουν ID από 0 έως n 1 (n=#κόµβων) Μπορούµε να επιλέξουµε µοντέλο δικτύου Μπορούµε να επιλέξουµε ϱυθµό εκτέλεσης της εξοµοίωσης ιαθέσιµες επιλογές (2) Debugging interface Ο συνολικός χρόνος που ϑέλουµε να τρέξουµε την εφαρµογή µπορεί επίσης να καθοριστεί (πιο αργά / γρήγορα) Μπορούµε να ορίσουµε αρχείο που προσδιορίζει τις συνδέσεις µεταξύ των κόµβων του συστήµατος Μπορούµε να ορίσουµε ένα χρονικό διάστηµα, κατά τη διάρκεια του οποίου οι κόµβοι του συστήµατος ξεκινούν τη λειτουργία τους επιλέγοντας οµοιόµορφα κάποια χρονική στιγµή σε αυτό το διάστηµα Κάποιες από αυτές τις παραµέτρους µπορούν να άλλάξουν δυναµικά χρησιµοποιώντας το γραφικό περιβάλλον Υπάρχει κάτι ανάλογο της printf Χρησιµοποιώντας ένα σύνολο από debug flags µπορούµε να εµφανίσουµε τα µηνύµατα κατάστασης που µας ενδιαφέρουν κάθε ϕορά Π.χ. υπάρχουν τα flag usr1, usr2, usr3. Εστω ότι κάπου στον κώδικά µας έχουµε: dbg(dbg_usr1, Greetings from CEID. Fatal error ) Αν έχουµε ενεργοποιηµένο το αντίστοιχο flag (usr1) ϑα εµφανίστει σε κάποια ϕάση το µήνυµα αυτό στη γραµµή εντόλών όταν τρέξουµε το εκτελέσιµο αρχείο

14 Debugging interface (2) Debugging interface (3) Αν είµαστε σε bash shell και ϑέλουµε να ενεργοποιήσουµε το flag usr1 δίνουµε στη γραµµη εντολών export DBG=usr1 Μπορούµε να έχουµε πολλά flag ενεργοποιηµένα ταυτόχρονα Οι ϐιβλιοθήκες του συστήµατος έχουν σε πολλά σηµεία τέτοιες δηλώσεις By default είναι όλα τα flag ενεργοποιηµένα Είναι αρκετά χρήσιµο να µπορούµε να ορίσουµε ποια debug µηνύµατα ϑέλουµε να ϐλέπουµε Παραδείγµατα διαθέσιµων debugging καναλιών: all: όλα τα διαθέσιµα debugging µηνύµατα boot: αρχικοποίηση εξόµοιωσης και StdControl led: τα led της συσκευής am: µετάδοση/λήψη ΑΜ µηνυµάτων crc: CRC έλεγχος µηνυµάτων packet: µετάδοση/λήψη µηνυµάτων uart: serial ϑύρα time: Timers usr1, usr2, usr3: User output mode 1, 2, 3 Καθορισµός επικοινωνίας µεταξύ κόµβων του συστήµατος TinyViz ηµιουργούµε ένα αρχείο κείµενου που περιέχει εγγραφές της µορφής: <mote ID>:<mote ID>:bit error rate ίνουµε π.χ. 0:1: :0: :2: :1: :2: :0: Το TinyViz είναι µια εφαρµογή σε Java που χρησιµοποιείται και ως γραφικό interface για τον TOSSIM Μας παρέχει ένα πλήθος από δυνατότητες ελέγχου των παραµέτρων και της ϱοής της εξοµοίωσης Μας δίνει µια οπτική εικόνα του τί συµβαίνει στη διάρκεια της εξοµοίωσης Οταν χρησιµοποιούµε τον TOSSIM µπορούµε να ορίσουµε ότι ϑα χρησιµοποιήσουµε το TinyViz (-gui) Είναι και αυτό µέρος της διανοµής του TinyOS

15 Παράδειγµα Μια πολύ χρήσιµη δυνατότητα που προσφέρει ο TOSSIM είναι ότι µπορούµε να ενεργοποιήσουµε ή απενεργοποίησουµε τους κόµβους του συστήµατος όπως ϑέλουµε Θεωρούµε αρχικά ότι το σύστηµα µας τοποθετείται σε ένα χώρο Μπορούµε να αλλάξουµε τη ϑέση των κόµβων επηρεάζοντας την τοπολογία του συστήµατος Μπορούµε επίσης να ορίσουµε ένα αρχείο που να περιγράφει την τοπολόγια του συστήµατος, κτλ. TinyViz plugins Παράδειγµα Η λειτουργικότητα του TinyViz υλοποιείται µε τη µορφή plugin, τα οποία µπορούµε δυναµικά να ενεργοποιήσουµε ή απενεργοποίησουµε κατά τη διάρκεια της εξοµοίωσης Τα plugin αυτά π.χ µας επιτρέπουν να ϐλέπουµε αν κάποιος κόµβος (ή από συγκεκριµένους κόµβους) µεταδίδει κάποιο µήνυµα και τα περιεχόµενά του Μπορούµε να ϐλέπουµε τα debug µηνύµατα της εφαρµογής µας (από κάθε κόµβο ή από συγκεκριµένους) Μπορούµε επίσης να καθορίσουµε το µοντέλο δικτύου που χρησιµοποιούµε

16 Εχουµε τις εξής επιλογές όσον αφορά το µοντέλο δικτύου (µέσω του διαθέσιµου TinyViz plugin) 1. fixed radius 10, 100 ή 1000 (και υποδιαιρέσεις ή πολλαπλάσια) 2. εµπειρικό µοντέλο Μπορούµε να χρησιµοποιήσουµε ένα δικό µας αρχείο, όπως είπαµε προηγουµένως για να ορίσουµε την τοπολογία του δικτύου Μπορούµε να δούµε τις πιθανότητες σωστής µετάδοσης µεταξύ κόµβων (αν έχουµε επιλέξει το radio model plugin) π.χ.ιστην εικόνα δίπλα έχουµε επιλέξει το εµπειρικό µοντέλο