ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΠΡΟΣΟΜΟΙΩΣΗ ΕΝΟΣ ΔΙΚΤΥΟΥ ΠΑΡΑΔΟΣΗΣ ΠΕΡΙΕΧΟΜΕΝΩΝ (CDNsim: A CONTENT DELIVERY NETWORK SIMULATOR) Διπλωματική Εργασία του ΣΤΑΜΟΥ ΚΩΝΣΤΑΝΤΙΝΟΥ Επιβλέπουσα καθηγήτρια Βακάλη Αθηνά, Επίκουρη Καθηγήτρια, Τμήμα Πληροφορικής Α.Π.Θ. Ιούνιος 2005 Θεσσαλονίκη

2 Περιεχόμενα 1. Εισαγωγή Τοπολογία δικτύου Κόμβοι Links Βήμα προς Βήμα κατασκευή Διαχείριση αντικειμένων Κεντρική δομή Διαπροσωπία (interface) σκληρών δίσκων BLOOM filters Πρωτόκολλο IP Περιγραφή πρωτοκόλλου Βασικές αρχές λειτουργίας Υλοποίηση πρωτοκόλλου Router Tables Κατασκευή των Router Tables Πρωτόκολλο TCP Περιγραφή πρωτοκόλλου Βασικές αρχές λειτουργίας Υλοποίηση πρωτοκόλλου Διεργασίες (Tasks) Ορισμός των tasks Μοντελοποίηση των ports Μοντελοποίηση των κόμβων Μελέτη περιπτώσεων Ρύθμιση αριθμού των tasks Πολιτική Σύνοψη Βιβλιογραφία...67 ΠΑΡΑΡΤΗΜΑ Α Ρυθμίσεις Ε/Ε...69 ΠΑΡΑΡΤΗΜΑ Β Εγκατάσταση - Εκτέλεση...87 ΠΑΡΑΡΤΗΜΑ Γ Γραφικό περιβάλλον...90 ΠΑΡΑΡΤΗΜΑ Δ Ορολογία

3 Κατάλογος εικόνων Εικόνα 1 Σχηματική Αναπαράσταση CDN...7 Εικόνα 2 Κατασκευή και σύνδεση των Routers (R)...15 Εικόνα 3 Κατασκευή και σύνδεση των Origins (O)...16 Εικόνα 4 Κατασκευή και σύνδεση των Surrogates (SS)...16 Εικόνα 5 Κατασκευή και σύνδεση των Client Groups ( C )...17 Εικόνα 6 Αρχιτεκτονική bloom filters...21 Εικόνα 7 Οπτική αναπαράσταση του τελικού μηνύματος...32 Εικόνα 8 Παράδειγμα task Εικόνα 9 Παράδειγμα task Εικόνα 10 Παράδειγμα node...40 Εικόνα 11 Διαδικασία ικανοποίησης αίτησης...48 Εικόνα 12Αφαιρετική αναπαράσταση του μοντέλου...54 Εικόνα 13 Κύρια οθόνη GUI...91 Εικόνα 14 General Options Tab...93 Εικόνα 15 Output Options Tab...94 Εικόνα 16 Parsol Options Tab...94 Εικόνα 17 Network-Topology Options Tab...95 Εικόνα 18 Surrogate Options Tab...96 Εικόνα 19 Origins Options Tab...97 Εικόνα 20 RoutersOptions Tab...97 Εικόνα 21 Clients Options Tab...98 Εικόνα 22 Placemment Options Tab...99 Εικόνα 23 Data sets Options Tab Κατάλογος πινάκων Πίνακας 1 Διαδικασία εγκατάστασης σύνδεσης...33 Πίνακας 2 Παράδειγμα στοιχειώδους TASK...37 Πίνακας 3 Παράδειγμα TASK σε συνεχή κατάσταση RECEIVING...38 Πίνακας 4 Παράδειγμα TASK συνεχή κατάσταση SENDING...39 Πίνακας 5 Παράδειγμα trace file...42 Πίνακας 6 Παράδειγμα trace file με αντίστοιχες εντολές ps_sleep...42 Πίνακας 7 Το Client Group δεν έχει διαθέσιμο Fetch Master task...43 Πίνακας 8 Το Client Group έχει διαθέσιμο Fetch Master task...44 Πίνακας 9 RQTask...44 Πίνακας 10 cl_fathertask...44 Πίνακας 11 cl_fetchmastertask...45 Πίνακας 12 Όχι διαθέσιμο Push Master Task...45 Πίνακας 13 Υπάρχει διαθέσιμο Push Master Task...47 Πίνακας 14 cl_fetchmastertask...49 Πίνακας 15 su_fathertask...49 Πίνακας 16 su_pushmastertask...50 Πίνακας 17 su_simplepushertask...50 Πίνακας 18 su_pushmastertask...55 Πίνακας 19 su_pullmastertask...56 Πίνακας 20 su_simplepushertask...56 Πίνακας 21 or_pushmastertask...57 Πίνακας 22 or_simplepushertask...57 Πίνακας 23 ro_fathertask

4 Πίνακας 24 ro_routehmastertask...59 Πίνακας 25 Αλλαγή αριθμού RQ...60 Πίνακας 27 Αλλαγή αριθμού clt_fetchmaster...60 Πίνακας 28 Αλλαγή αριθμού sut_father...60 Πίνακας 29 Αλλαγή αριθμού sut_pushmaster...61 Πίνακας 30 αλλαγή αριθμού sut_simplepusher...61 Πίνακας 31 Αλλαγή αριθμού sut_pullmaster...62 Πίνακας 32 Αλλαγή αριθμού ort_father...62 Πίνακας 33 αλλαγή αριθμού ort_pushmaster...63 Πίνακας 34 Αλλαγή αριθμού rot_father...63 Πίνακας 35 Αλλαγή αριθμού rot_routemaster...64 Πίνακας 36 Παράδειγμα αρχείου ρυθμίσεων...70 Πίνακας 37 παράδειγμα αρχείου placement...72 Πίνακας 38 Παράδειγμα αρχείου placement (επεξηγημένο...72 Πίνακας 39 Παράδειγμα αρχείου αντικειμένων για αρχείο placement...73 Πίνακας 40 Παράδειγμα αρχείου Router Tables...75 Πίνακας 41 Παράδειγμα αρχείου Router Tables (επεξηγημένο...76 Πίνακας 42 Παράδειγμα αρχείου γράφου για Routers...77 Πίνακας 43 Παράδειγμα αρχείου trace...79 Πίνακας 44 Παράδειγμα αρχείου αντικειμένων...80 Πίνακας 45 Παράδειγμα αρχείου cooked trace file...80 Πίνακας 46 Παράδειγμα αρχείου στατιστικών...84 Πίνακας 47 Παράδειγμα αρχείου sessions

5 1. Εισαγωγή Αν παρατηρήσουμε την εξέλιξη του internet κάθε χρόνο θα διαπιστώσουμε ότι ο ρυθμός αύξησης της πληροφορίας σε αυτό είναι πολύ μεγάλος. Νέες σελίδες προστίθενται συνεχώς στις ήδη υπάρχουσες τοποθεσίες και νέες τοποθεσίες προσθέτονται στην ήδη τεράστια δομή του internet. Η δομή internet μπορεί να αναπαρασταθεί ως ένας γιγαντιαίων διαστάσεων γράφος όπου οι κόμβοι του είναι οι διάφορες τοποθεσίες (web sites), ενδιάμεσοι σταθμοί (Routers, Bridges, DNS Servers), χρήστες και οι ακμές του είναι τα κανάλια επικοινωνίας που συνδέουν τους κόμβους. Η πληροφορία αναπαριστάται από δεδομένα σε μορφή κειμένου (text) ή σε πολυμεσική μορφή (video, audio, images). Τα πολυμεσικά δεδομένα έχουν πολύ μεγαλύτερες απαιτήσεις σε αποθηκευτικό χώρο και χρόνο μεταφοράς μέσω καναλιών επικοινωνίας. Η τάση είναι να «γεμίζουν» οι σελίδες με όλο και περισσότερα πολυμεσικά δεδομένα, για να γίνουν πιο ελκυστικές ή για να προσφέρουν βελτιωμένη αναπαράσταση πληροφορίας στους χρήστες. Τα δεδομένα με τη σειρά τους οργανώνονται σε δομές προσπελάσιμες από τους χρήστες (hyperlinks). Οι χρήστες συνεχώς αυξάνονται όπως και οι απαιτήσεις τους σε υπηρεσίες μεταφοράς των δεδομένων. Οι επιχειρήσεις, που στηρίζονται σε υπηρεσίες μέσω internet, έχουν αυξηθεί και αυτές σε αριθμό προσπαθώντας να προωθηθούν στην νέα μορφή ηλεκτρονικής αγοράς. Χαρακτηριστικό των επιχειρήσεων δεν είναι μόνο η αύξηση του αριθμού τους, αλλά και οι αύξηση τους αριθμού των υπηρεσιών που προσφέρουν σε συνδυασμό με την αυξημένη αξιοπιστία και ποιότητα τους. Όλα τα παραπάνω εκτυλίσσονται σε επίπεδα υψηλότερα του δικτύου και αφορούν κυρίως θέματα λογισμικού. Η βελτίωση της ταχύτητας των καναλιών επικοινωνίας δεν γίνεται όμως με τον ίδιο ρυθμό και είναι πεπερασμένη. Επίσης η δυναμικότητα (η οποία είναι πεπερασμένη) των ενδιάμεσων σταθμών-κόμβων δεν ακολουθεί τους ίδιους εξελικτικούς ρυθμούς με αυτούς των απαιτήσεων. Από τα παραπάνω προκύπτει τελικά το πρόβλημα μεταφοράς όσο το δυνατόν περισσοτέρων δεδομένων, το γρηγορότερο δυνατό, με την μεγαλύτερη αξιοπιστία και ποιότητα στον τελικό χρήστη από τις αρχικές τοποθεσίες. Για την αντιμετώπιση του παραπάνω προβλήματος υπάρχουν δυο προσεγγίσεις: Συνεχής βελτίωση του δικτύου. Τοποθέτηση των δεδομένων πιο «κοντά στον χρήστη» Στην πρώτη προσέγγιση προβλέπεται η συνεχής αύξηση της ταχύτητας μεταφοράς δεδομένων των καναλιών επικοινωνίας και η βελτίωση των ενδιάμεσων κόμβων-σταθμών. Στην περίπτωση καναλιών που η λειτουργία τους βασίζεται σε κάποιο μέσο η ταχύτητα είναι πεπερασμένη ακόμη και αν γίνει χρήση βέλτιστης κωδικοποίησης μηνυμάτων. Στην περίπτωση των ασύρματων δικτύων η ταχύτητα είναι θεωρητικά άπειρη αλλά εισάγονται άλλοι περιορισμοί, όπως ζητήματα διαχωρισμού ζωνών συχνοτήτων, μοναδικής χρήσης σε κάθε μετάδοση του καναλιού συχνότητας και περιορισμένης δυναμικότητας πομπών και δεκτών. Αναφορικά με τη 5

6 βελτίωση των ενδιάμεσων σταθμών επικοινωνίας, και αυτή η μέθοδος είναι πεπερασμένη, αφού από ένα σημείο και μετά δεν έχει επίδραση στην απόδοση εφόσον φθάσουμε τα όρια μεταφοράς δεδομένων των καναλιών επικοινωνίας. Δηλαδή, αν και θα έχουμε πολύ δυνατούς ενδιάμεσους σταθμούς επικοινωνίας αυτοί θα παραμένουν αναξιοποίητοι, αφού θα έχουν περιορισμένο φόρτο εργασίας λόγο περιορισμένων ταχυτήτων στα κανάλια επικοινωνίας. Στην δεύτερη προσέγγιση εισάγονται δυο έννοιες, αυτή των Proxy caches και αυτή των CDNs (Content Delivery Networks). Οι παροχείς internet (ISPs) για να βελτιώσουν την ποιότητα υπηρεσιών που παρέχουν, υποστηρίζουν ένα μηχανισμό διατήρησης των αντικειμένων κοντά στο χρήστη. Εξετάζουν ποια αντικείμενα ζητούνται ποιο συχνά και τα αποθηκεύουν σε Proxy caches. Όταν ο χρήστης απαιτήσει ένα αντικείμενο, τότε γίνεται έλεγχος αν υπάρχει στην cache του Proxy Server καθώς επίσης και ένας γρήγορος έλεγχος στην αρχική τοποθεσία του αντικείμενου (Origin Server) για να εξασφαλισθεί ότι αυτό δεν έχει αλλάξει. Τελικά αν ικανοποιηθούν οι έλεγχοι το αντικείμενο μεταφέρεται στο χρήστη από την cache, ειδάλλως από την αρχική τοποθεσία Με αυτό το μηχανισμό ο χρόνος ικανοποίησης του χρήστη βελτιώνεται σημαντικά. Ένα μειονέκτημα στην όλη διαδικασία είναι ο κίνδυνος να παραλάβει ο χρήστης παλιά δεδομένα, δηλαδή τα αποθηκευμένα δεδομένα στnν cache να έχουν παλαιότερη ημερομηνία σε σχέση με αυτά στον origin Server. Το πρόβλημα αντιμετωπίζεται με την εφαρμογή κάποιας πολιτικής ανανέωσης των δεδομένων της cache (π.χ. LRU, LFU κτλ.) και με τον έλεγχο κάθε φορά που γίνεται αίτηση για κάποιο δεδομένο αν η έκδοση του στην cache είναι η ίδια με αυτή στον origin. Η όλη διαδικασία προσθέτει επιπλέον χρόνο στον χρόνο ικανοποίησης του χρήστη. Η λύση των Proxy Server δεν είναι βαθμωτή, δηλαδή δεν μπορεί να αντεπεξέλθει στην συνεχή αύξηση των χρηστών και των αντικειμένων. Το σημαντικότερο μειονέκτημα χρήσης Proxy caches είναι η αδυναμία αντιμετώπισης των flash crowd events, δηλαδή απότομες μαζικές αιτήσεις χρηστών. Το φαινόμενο αυτό παρουσιάστηκε στα γεγονότα του Σεπτεμβρίου 2001, όπου μεγάλα sites ειδήσεων παρουσίασαν denial of service (άρνηση εξυπηρέτησης) ή βλάβες, λόγο μαζικής παγκόσμιας ζήτησης σελίδων από αυτά. Λύση στο παραπάνω πρόβλημα δίνει η χρήση των CDNs (Content Delivery Networks, Δίκτυα Παροχής Περιεχομένου). Ο ρόλος αυτών των δικτύων είναι να φέρουν το «περιεχόμενο» κοντύτερα στους χρήστες. Με τον όρο «περιεχόμενο» ορίζουμε κάθε μορφή δεδομένων η οποία διακινείται το Internet και μπορεί να αποθηκευτεί και να αποσταλεί σε όποιον το ζητήσει. Σύμφωνα με την προσέγγιση αυτή, τα CDNs αποτελούνται από ένα σύνολο από βοηθητικούς Servers (ευρέως γνωστοί ως Surrogate Servers) οι οποίοι προ-αποθηκεύουν τα περιεχόμενα των Origin Servers στην τοπική cache τους. 6

7 Εικόνα 1 Σχηματική Αναπαράσταση CDN Όταν κάποιος χρήστης απαιτεί κάποιο αντικείμενο τότε αυτό αποστέλλεται από τον καταλληλότερο Surrogate Server. Δηλαδή η λογική βασίζεται στην τοποθέτηση Surrogate Servers ως ένα ακόμη επίπεδο δικτύου αφιερωμένο στην διακίνηση δεδομένων. Στην εικόνα 1 απεικονίζεται η σχέση μεταξύ των πελατών, Surrogate Servers, Origin Server και ενδιάμεσων σταθμών (πχ. Routers). Στο πλαίσιο αυτό, υπάρχουν κάποια ζητήματα που πρέπει να επιλύονται κάθε φορά που ένα CDN αναλαμβάνει τη διακίνηση δεδομένων: Επιλογή του συνόλου των αντικειμένων. Αν όλα τα αντικείμενα χωρούν στους Surrogates τότε δεν υπάρχει πρόβλημα. Λαμβάνοντας όμως υπόψη ότι κάθε CDN εξυπηρετεί περισσότερους από έναν Origin servers, το μέγεθος της cache στους Surrogates είναι πολύ μικρό για να μπορέσει να «φιλοξενήσει» όλα τα αντικείμενα.. Σε αυτό το πλαίσιο, θα πρέπει να γίνει μία επιλογή των αντικειμένων που θα εξυπηρετούνται από το εκάστοτε CDN. Υποθέτουμε ότι ο Origin Server περιέχει το σύνολο όλων των αντικειμένων Ο και ότι μόνο ένα 7

8 υποσύνολο αυτών Ο μπορούν να αποθηκευτούν. Τα υπόλοιπα Ο Ο δεν μπορούν να αποθηκευτούν γιατί είναι δυναμικό περιεχόμενο (π.χ. φόρμες). Άρα πρέπει να επιλεχθούν τα αντικείμενα από το σύνολο Ο τα οποία θέλουμε να μοιρασθούν στους Surrogates. Συνήθως επιλέγονται τα πιο δημοφιλή με το μεγαλύτερο κόστος μεταφοράς (π.χ. μεγάλο μέγεθος) αλλά αυτό είναι συνήθως ευθύνη του διαχειριστή του Origin. Τοποθέτηση των αντικειμένων. Αφού επιλεχθούν τα αντικείμενα, πρέπει να τοποθετηθούν με βάση κάποια λογική στους Surrogates, με τέτοιο τρόπο ώστε να ελαχιστοποιείται ο χρόνος μεταφοράς στον τελικό χρήστη (τόσο στην περίπτωση κατά την οποία ένα αντικείμενο ζητείται και υπάρχει στην τοπική cache (cache hit) όσο και στην περίπτωση όπου ένα αντικείμενο ζητείται και δεν υπάρχει στην τοπική cache (cache miss) οπότε πρέπει να ανακτηθεί αλλιώς). Υπάρχουν δύο κύριες πολιτικές αντιμετώπισης των cache misses: o Uncooperative Pull based, κατά την οποία αν ένας Surrogate δεχτεί μια αίτηση για ένα αντικείμενο το οποίο δεν υπάρχει, τότε ο πελάτης ανακατευθύνεται προς τον Origin Server ή προς κάποιο άλλο Surrogate από όπου λαμβάνει ο αντικείμενο. o Cooperative Push based κατά την οποία οι Surrogates συνεργάζονται για την αντιμετώπιση των cache misses. Ο κάθε Surrogate γνωρίζει τα περιεχόμενα του κάθε άλλου και επιλέγει τον καλύτερο απ όπου παίρνει το αντικείμενο που λείπει. Ευρηστικοί αλγόριθμοι όπως ο Greedy Global [9] προσπαθούν να επιλύσουν το πρόβλημα της τοποθέτησης των αντικειμένων. Τοποθέτηση των Surrogate Servers. Οι Surrogate Servers πρέπει να είναι τοποθετημένοι στρατηγικά στο δίκτυο έτσι ώστε να διευκολύνεται η πιθανή συνεργασία τους αλλά και να βρίσκονται κοντινότερα στους τελικούς χρήστες. Υπάρχουν διάφοροι αλγόριθμοι που πετυχαίνουν την επίλυση του προβλήματος τοποθέτησης M Surrogate Servers ανάμεσα σε T τοποθεσίες (T > Μ). Παραδείγματα αυτών των αλγορίθμων είναι οι tree-based, Greedy και Hot Spot [15]. Επιλογή του καλύτερου Surrogate Server. Υποθέτοντας ότι έχουν ικανοποιηθεί τα όλα παραπάνω προβλήματα, μένει το ζήτημα δρομολόγησης των αιτήσεων στους Surrogates που πιθανώς εξυπηρετούν βέλτιστα κάθε αίτηση. Σε αυτό το σημείο, τίθεται το ζήτημα εντοπισμού του Surrogate που βρίσκεται πιο κοντά στον χρήστη. Με τον όρο «κοντά» δεν δίνουμε απαραίτητα γεωγραφική ερμηνεία. Παράγοντες όπως η ταχύτητα του δικτύου, η αξιοπιστία του και το κόστος αποστολής δεδομένων παίζουν αποφασιστικό ρόλο στην επιλογή της θέσης. Επίσης οι αιτήσεις πρέπει να μοιράζονται με τέτοιο τρόπο ώστε να αποφεύγεται η υπερφόρτωση των Surrogates και να αποφεύγεται η ύπαρξη ανενεργών (idle) Surrogates. 8

9 Εικόνα 2. Δημοφιλή παροχείς CDNs Τα CDNs υπόσχονται λύσεις στα προβλήματα που προαναφέρθηκαν, γι αυτό υπάρχει αρκετό ερευνητικό ενδιαφέρον. Ένα σημαντικό ζήτημα που εμφανίζεται είναι η μοντελοποίηση ενός CDN για τον υπολογισμό των διαφόρων μετρικών του για διαφορετικές παραμέτρους όπως ο αριθμός των Surrogates και διαφορετικές τοπολογίες. Η μαθηματική προσέγγιση είναι πολύ περίπλοκη ή και αδύνατη αφού δεν μπορούν όλες οι διεργασίες να εκφραστούν με εξισώσεις. Επίσης είναι σύστημα το οποίο λειτουργεί παράλληλα και τυχαία γεγονότα μπορούν να συμβούν (π.χ. καταστροφή κάποιου Surrogate). Η προσομοίωση είναι η μόνη λύση στην αδυναμία μαθηματικής μοντελοποίησης. Στα πλαίσια αυτής της εργασίας παρουσιάζεται ένα λογισμικό προσομοίωσης για τα CDNs, το CDNsim, που αναπτύχθηκε για να καλύψει τα ζητήματα που αναφέρθηκαν παραπάνω. Η προσομοίωση βασίζεται στην βιβλιοθήκη ParaSol 1 ή οποία είναι σχεδιασμένη για να παρέχει μεθόδους προσομοίωσης παράλληλων συστημάτων επεξεργασίας και επικοινωνίας, βοηθώντας στην εύκολη μοντελοποίηση τους. Το CDNsim προσομοιώνει μία τοπολογία δικτύου (Routers, Origins, Surrogates, Clients), παρέχει αποδοτικές δομές cache για τους Servers, διαχείριση αντικειμένων, πρωτόκολλα επικοινωνίας δικτύου, μηχανισμούς εξυπηρέτησης πελατών και πολιτικές «Uncooperative Pull based» και «Cooperative Push based». Επίσης προσομοιώνεται η συμπεριφορά του δικτύου, όπως καθυστερήσεις και bottlenecks. Η ανάπτυξη είναι αρθρωτή και επιδέχεται μετατροπές για μελλοντική χρήση (π.χ. υλοποίηση διαφορετικών πολιτικών διαχείρισης cache)

10 Στις εργασίες [9, 10] προτείνονται εναλλακτικοί μέθοδοι της πλήρους προσομοίωσης. Αυτοί οι μέθοδοι απλουστεύουν τη διαδικασία θεωρώντας σταθερές τιμές κόστους επικοινωνίας μεταξύ κόμβων και λαμβάνοντας μόνο αυτές υπ όψιν. Αδιαφορούν για τις αλληλεπιδράσεις των κόμβων του δικτύου, την περιορισμένη δυναμικότητα των Servers και δεν προβλέπουν πραγματικές καθυστερήσεις στην μετάδοση, απώλεια μηνυμάτων, ανακατεύθυνση μηνυμάτων και bottlenecks. Με την το CDNsim αποφεύγεται η δημιουργία ενός εξ ιδανικευμένου περιβάλλοντος εκτέλεσης που μπορεί να οδηγήσει σε λάθος συμπεράσματα. Με την προσομοίωση τα μοντέλα εκτέλεσης γίνονται πιο ρεαλιστικά και πιο παραμετροποιήσιμα. Στη συνέχεια παρουσιάζονται αναλυτικά οι ενότητες «Τοπολογία δικτύου», «Διαχείριση αντικειμένων», «Πρωτόκολλο IP», «Router Tables», «Πρωτόκολλο TCP», «Διεργασίες (Tasks)». Στην ενότητα «Τοπολογία δικτύου» γίνεται παρουσίαση της αρχιτεκτονικής της τοπολογίας δικτύου, δηλαδή με ποιο τρόπο αυτή κατασκευάζεται (κόμβοι, σύνδεσμοι), πως τοποθετούνται σε αυτή οι Surrogate Servers και ποίες είναι αρχές λειτουργίας της. Στην ενότητα «Διαχείριση αντικειμένων» παρουσιάζεται η οργάνωση των αντικειμένων στις caches των Servers και ποιες λειτουργίες μπορούν να εφαρμοστούν. Στην ενότητα «Πρωτόκολλο IP» περιγράφεται ο τρόπος με τον οποίο λειτουργεί το δίκτυο και ποιοι κανόνες διέπουν την επικοινωνία μεταξύ κόμβων. Στην ενότητα «Router Tables» παρουσιάζονται μέθοδοι πλοήγησης στο δίκτυο και εύρεσης καλύτερων διαδρομών επικοινωνίας μεταξύ κόμβων. Στην ενότητα «Πρωτόκολλο TCP» αναλύεται η διαδικασία σύνδεσης και αποκατάστασης επικοινωνίας μεταξύ κόμβων για την ικανοποίηση αιτήσεων. Τέλος, στην ενότητα «Διεργασίες (Tasks)» παρουσιάζονται και επεξήγονται τα δομικά συστατικά της προσομοίωσης, οι διεργασίες, και πως αυτά επηρεάζουν την πορεία των προσομοιώσεων. 10

11 2 Τοπολογία δικτύου Τα θεμέλια πάνω στα οποία «πατάει» ένας προσομοιωτής δικτύου είναι αναμφισβήτητα η αρχιτεκτονική της τοπολογίας δικτύου. Στην προκειμένη περίπτωση το CDNsim δεν αποτελεί εξαίρεση. Τα στοιχειώδη συστατικά της τοπολογίας που κατασκευάζεται στην αρχή της προσομοίωσης είναι οι κόμβοι (nodes) και οι σύνδεσμοι (Links) [4, 5, 18]. Κάθε κόμβος είναι συνδεδεμένος με έναν ή περισσότερους κόμβους (κατά περίπτωση) μέσω συνδέσμων διπλής κατεύθυνσης, δηλαδή αν ο κόμβος «Α» είναι συνδεδεμένος με τον «Β» μέσω του συνδέσμου «Σ1» τότε και ο «Β» είναι συνδεμένος με τον «Α» μέσω ενός συνδέσμου «Σ2» διαφορετικού από τον «Σ1» αλλά ίδιων χαρακτηριστικών (π.χ. ταχύτητα μετάδοσης δεδομένων). Οι ιδιότητες των κόμβων και των συνδέσμων είναι παραμετροποιήσιμες ανάλογα με τις απαιτήσεις του χρήστη. Υπάρχουν τέσσερις κατηγορίες κόμβων στην τοπολογία: Οι Πρωταρχικοί εξυπηρέτες (Origin Servers ή Origins) Οι Αναπληρωτές εξυπηρέτες (Surrogate Servers ή Surrogates) Οι Δρομολογητές (Routers) Οι Ομάδες χρηστών (Client Groups). Οι σύνδεσμοι δεν χωρίζονται σε κατηγορίες αλλά κατά την δημιουργία τους τα χαρακτηριστικά τους εξαρτώνται από τους κόμβους που συνδέουν. Η τοπολογία κατασκευάζεται στην αρχή της προσομοίωσης και παραμένει αμετάβλητη (στατική) μέχρι το τέλος της προσομοίωσης. Με τον όρο στατική εννοούμε ότι δεν δημιουργείται / καταστρέφεται δυναμικά κατά την εκτέλεση της προσομοίωσης κανένας κόμβος / σύνδεσμος (Build-once Destroy-Once). Οι δομές αποθήκευσης των δεδομένων είναι αποδοτικές από πλευράς μνήμης για να υποστηρίζονται μεγάλες τοπολογίες (εξαρτάται μόνο από περιορισμούς μνήμης). Από τον χρήστη απαιτούνται ρυθμίσεις των χαρακτηριστικών του δικτύου αλλά και ένα αρχείο γράφου (graph file) που χρησιμοποιείται για την κατασκευή της τοπολογίας. 2.1 Κόμβοι Στην εισαγωγή αναφέρθηκαν τέσσερις κατηγορίες κόμβων που χρησιμοποιούνται στο δίκτυο. Ας δούμε αναλυτικά τι είναι ο καθένας, πως κατασκευάζεται, με τι δομή αποθηκεύεται, τι υπευθυνότητες και ιδιαίτερα χαρακτηριστικά έχει και τι απαιτείται από τον χρήστη, σε ότι αφορά την προσομοίωση. Ένας κόμβος κατασκευάζεται με την ακόλουθη εντολή PARASOL : ps_build_node(name, ncpus, speed, quantum, discipline, stat_flags) που επιστρέφει ένα μοναδικό αριθμό χαρακτηριστικό του κόμβου (unique node ID), το οποίο αποθηκεύεται στις ιδιότητες του τρέχοντος κόμβου. Όπου: 11

12 name είναι το όνομα του κόμβου. ncpus είναι ο αριθμός των επεξεργαστών που τρέχουν παράλληλα στον κόμβο. peed είναι η ταχύτητα των επεξεργαστών. quantum είναι τα κβάντα χρόνου εκτέλεσης. discipline είναι ο αλγόριθμος δρομολόγησης διεργασιών στον κόμβο. stat_flags είναι να κρατούνται στατιστικά για τον κόμβο ή όχι. Όλες οι τιμές μας είναι αδιάφορες και δεν επηρεάζουν τα αποτελέσματα της προσομοίωσης γιατί αυτό που μετράμε είναι η απόδοση του δικτύου CDN, αφού όλες οι διεργασίες στους κόμβους δεν απαιτούν καθόλου χρόνο ιδεατού επεξεργαστή ανά κόμβο. Όλοι οι κόμβοι αποθηκεύονται σε δομές δυναμικού πίνακα για γρήγορη προσπέλαση των ιδιοτήτων τους που είναι αποθηκευμένες. Διαδικασίες αναζήτησης χρειάζονται χρόνο: όπου: T nodeseek = log 2 (N) Ν είναι ο αριθμός των κόμβων της τρέχουσας κατηγορίας. T nodeseek είναι ο χρόνος αναζήτησης κάποιου κόμβου, σε μονάδες πολυπλοκότητας. Υποστηρίζονται μέθοδοι ταξινόμησης, ανάκτησης χαρακτηριστικών του κάθε κόμβου και καταστροφής. Origin Servers Ο Origin Server περιέχει όλα τα αντικείμενα ενός web site (διαδικτυακού τόπου) σε μία δομή σκληρού. Ο ρόλος του είναι να δέχεται αιτήσεις για μεταφορά αντικειμένων. Οποιαδήποτε αίτηση για ένα αντικείμενο είναι πάντα επιτυχής (cache hit, το αντικείμενο βρίσκεται στην cache) γιατί προφανώς περιέχει όλα τα αντικείμενα. Υποστηρίζονται [1...οο) Origin Servers σε μία τοπολογία. Ο ακριβής αριθμός τους καθορίζεται από το χρήστη. Surrogate Servers Ο Surrogate Server περιέχει υποσύνολο των αντικειμένων του web site σε μία δομή σκληρού δίσκου. Υπευθυνότητα του είναι να δέχεται αιτήσεις για μεταφορά αντικειμένων. Οποιαδήποτε αίτηση για ένα αντικείμενο μπορεί να είναι επιτυχής (cache hit) ή ανεπιτυχής (cache miss, το αντικείμενο δεν βρίσκεται στην cache) γιατί περιέχει υποσύνολο των αντικειμένων. Χαρακτηριστικό τους γνώρισμα είναι η ικανότητα συνεργασίας. Αν κάποιος Surrogate έχει cache miss τότε ικανοποιεί την αίτηση μέσω κάποιου άλλου Surrogate ή μέσω του Origin. Η μέθοδος αντιμετώπισης ενός cache miss εξαρτάται από την εκάστοτε πολιτική. Υποστηρίζονται [1...οο) Surrogate Servers σε μία τοπολογία. Ο ακριβής αριθμός τους απαιτείται από τον χρήστη. 12

13 Routers Ένα σύνολο από Routers αποτελεί την κορμό του δικτύου, δηλαδή είναι ενδιάμεσοι κόμβοι μεταξύ των Servers (Origins και Surrogates) οι οποίοι προσομοιώνουν το traffic (κίνηση του δικτύου). Πιο ειδικά, ένας Router το μόνο που κάνει είναι να μεταφέρει IP πακέτα, τα οποία είναι μηνύματα πακεταρισμένα, που στέλνονται από Servers προς άλλους Servers. Κανένας Server δεν μπορεί να επικοινωνήσει με άλλο χωρίς τη μεσολάβηση των Routers. Προφανώς η μεσολάβηση Routers και η ύπαρξη Links περιορισμένης ταχύτητας προκαλούν καθυστερήσεις στην επικοινωνία των Servers. Υπευθυνότητα των Routers είναι να αναμεταδίδουν πακέτα στον άμεσα επόμενο κόμβο σύμφωνα με ένα καθορισμένο μονοπάτι αλλά σε περιπτώσεις υψηλού traffic να κατασκευάζουν σε πραγματικό χρόνο (realtime) καινούριο μονοπάτι (re-routing) ή αν το traffic είναι πάρα πολύ υψηλό να τα καταστρέφουν προκαλώντας αναμετάδοση. Υποστηρίζονται [1...οο) Routers. Απαιτείται από τον χρήστη να δώσει ένα αρχείο που θα περιέχει τον γράφο που αντιστοιχεί στην δομή των Routers. Ο αριθμός τους εντοπίζεται αυτόματα από το αρχείο. Client Groups Ένα Client Group είναι ένας κόμβος ο οποίος παίζει το ρόλο ενός συνόλου από χρήστες με πεπερασμένη χωρητικότητα. Κάθε χρήστης αντιπροσωπεύεται από μια διεργασία η οποία αναλαμβάνει να στέλνει αιτήσεις σε γειτονικό Surrogate. Πρακτικά ένας Client Group κόμβος πακετάρει πολλούς πελάτες σε ένα κόμβο όπου τρέχουν παράλληλα και κάνουν αιτήσεις στο γειτονικό Surrogate Server. Υποστηρίζονται [1...οο) Client Groups και ο αριθμός τους είναι ίσος με αυτό των Surrogates αφού σε κάθε Surrogate αντιστοιχεί ένα Client Group. Η φιλοσοφία των Client Group έρχεται σε αντιστοιχία με την ιδέα του γειτονικού Server σε μια μεγάλη ομάδα χρηστών με κοινά (συνήθως τοπολογικά) χαρακτηριστικά (π.χ. Ένας Surrogate για την Ελλάδα). Κόμβος 0 Για λεπτομέρειες σχετικά με το κόμβο 0 ανατρέξτε στο documentation της PARASOL. Απλά ο κόμβος 0 φιλοξενεί μια διεργασία που παράγει αιτήσεις αντικειμένων οι οποίες διαβάζονται από ένα trace file (αρχείο κίνησης χρηστών) και τις κάνει διαθέσιμες στα Client Groups. Η επιλογή του κόμβου 0 δεν έχει κάποια ιδιαίτερη σημασία, θα μπορούσε να είχε δημιουργηθεί ένας καινούριος κόμβος που να φιλοξενεί την παραπάνω διεργασία. 2.2 Links Στην εισαγωγή αναφέρθηκε η έννοια του Link (συνδέσμου), τώρα θα δούμε αναλυτικά τι συμβαίνει ακριβώς με τα χαρακτηριστικά των Links, πως κατασκευάζονται και σε τι επηρεάζουν την προσομοίωση. Ένα Link κατασκευάζεται με την ακόλουθη PARASOL εντολή: ps_build_link(name, source, destination, rate, stat_flags) 13

14 από την οποία επιστρέφεται ένας αριθμός που χαρακτηρίζει μοναδικά (unique Link ID) κάθε Link και αποθηκεύεται στη δομή που αφορά το τρέχον Link. Όπου: name είναι το όνομα του. source είναι το ID του κόμβου από όπου ξεκινάει το Link. destination είναι το ID του κόμβου στο άλλο άκρο του Link. rate είναι ο ρυθμός μετάδοσης δεδομένων σε bytes/parasol time. stat_flags να κρατούνται στατιστικά για το Link ή όχι. Από τις παραπάνω παραμέτρους δεν μας ενδιαφέρουν οι name, stat_flags. Όλα τα Links αποθηκεύονται σε δομές δυναμικού πίνακα για γρήγορη προσπέλαση των ιδιοτήτων τους που είναι αποθηκευμένες. Διαδικασίες αναζήτησης χρειάζονται χρόνο T linkseek = log 2 (L) όπου : L είναι ο αριθμός των Links. T linkseek είναι ο χρόνος αναζήτησης ενός Link με βάση τον κόμβο πηγή του. Υποστηρίζονται μέθοδοι ταξινόμησης, ανάκτησης χαρακτηριστικών του κάθε Link και καταστροφής. Δεν συνίσταται η χρήση δομής adjacency matrix (πίνακα γειτνίασης) για αποθήκευση των Links (για άμεση προσπέλαση) γιατί η ποσότητα μνήμης που απαιτείται για την αποθήκευση ενός τέτοιού πίνακα στη μνήμη είναι τεράστια, π.χ. AS τοπολογία nodes, x x 20(bytes της δομής) = 596 MB μνήμης απαιτούνται για την αποθήκευση ενός γράφου ανεξαρτήτως αν είναι αραιός ή πυκνός ενώ για το συγκεκριμένο παράδειγμα έχουμε 2 x x 20 = 3.7 MB μνήμης, όπου είναι ο αριθμός των Links του ίδιου γράφου. Συνεπώς καλύτερα να έχουμε log 2 (L) κόστος αναζήτησης του κάθε Link παρά να έχουμε στενότητα μνήμης. Ο συνολικός αριθμός των Links (άνω όριο) προκύπτει από τον τύπο: NoOfLinksUpperBound = 2 x [ noofsurrogates + nooforigins + noofclientgroups + (noofmaxextraconnectionstorouters x noofsurrogates) + noofrouterslinks ] όπου: NoOfLinksUpperBound είναι ο μέγιστος αριθμός των Links noofsurrogates ο αριθμός των Surrogates nooforigins ο αριθμός των Origins noofclientgroups ο αριθμός των Client Groups noofmaxextraconnectionstorouters ο μέγιστος αριθμός επιπλέον συνδέσεων ανά Surrogate με Routers (θα εξηγηθεί παρακάτω στο Βήμα προς Βήμα κατασκευή ). noofrouterslinks ο αριθμός των Links στο γράφο των Routers. Τα Links αποτελούν τον μοναδικό μέσο μεταφοράς αντικειμένων στο CDNsim. Από τη στιγμή που έχουν πεπερασμένο rate (ταχύτητα μεταφοράς 14

15 δεδομένων) έχουμε και τις αντίστοιχες καθυστερήσεις στην μεταφορά των αρχείων, δουλειά την οποία αναλαμβάνει η PARASOL αυτόματα. Τα Links και οι Routers δρουν σαν λαιμοί μπουκαλιών (bottlenecks) όπου μεγάλος φόρτος δεδομένων προσπαθεί να περάσει από πεπερασμένης χωρητικότητας δίοδο, προκαλώντας επιθυμητά προβλήματα απόδοσης στο δίκτυο. 2.3 Βήμα προς Βήμα κατασκευή Υπάρχει μία τυποποιημένη βήμα προς βήμα διαδικασία κατασκευής της τοπολογίας. 1) Εντοπίζεται ο αριθμός των Routers και των Links και γίνονται οι κατάλληλες αρχικοποιήσεις και αιτήσεις μνήμης για τους κόμβους και τα Links. Ο αριθμός των Routers προκύπτει από ανάλυση του γράφου των Routers με την εξής μέθοδο: Διαβάζονται διαδοχικά όλα τα Links (κόμβος πηγή, προορισμός) και οι κόμβοι πηγή, προορισμός εισάγονται σε ένα AVL δένδρο, αν η εισαγωγή αποτύχει για κάποιο από τα δυο σημαίνει ότι υπάρχει είδη, δηλαδή ο αριθμός των Routers αυξάνεται με κάθε επιτυχημένη εισαγωγή. Στο τέλος το δένδρο καταστρέφεται. Ο αριθμός των Links προκύπτει από τον τύπο υπολογισμού του NoOfLinksUpperBound. 2) Κατασκευάζονται με διαδοχικές εντολές PARASOL και εισαγωγές στην δομή των Routers τόσοι Routers όσοι υπολογίστηκαν στο βήμα (1). 3) Ξαναδιαβάζεται ο γράφος των Routers και για κάθε ζεύγος (from-to) με διαδοχικές εντολές PARASOL και εισαγωγές στην δομή των Links κατασκευάζονται τα Links (from-to) και (to-from) με ίδια rates. Τα rate προκύπτουν από τις επιλογές του χρήστη για τη σύνδεση Router-Router. Σε αυτό το βήμα όπως και σε κάθε κατασκευή Links υπάρχει η δυνατότητα για τυχαιότητα στα rates καθορίζοντας ένα άνω όριο επιπλέον bytes ανά Link. Εικόνα 2 Κατασκευή και σύνδεση των Routers (R) 4) Κατασκευάζονται με διαδοχικές εντολές PARASOL και εισαγωγές στην δομή των Origins τόσοι Origins όσοι ορίστηκαν από τον χρήστη. 5) Συνδέονται με τυχαίο τρόπο με κάποιο Router και σύμφωνα με τις επιλογές του χρήστη. Ένας Origin συνδέεται μόνο με ένα Router. 15

16 Εικόνα 3 Κατασκευή και σύνδεση των Origins (O) 6) Κατασκευάζονται με διαδοχικές εντολές PARASOL και εισαγωγές στην δομή των Surrogates τόσοι Surrogates όσοι ορίστηκαν από τον χρήστη. 7) Συνδέονται με τυχαίο τρόπο με κάποιο Router και σύμφωνα με τις επιλογές του χρήστη. Ένας Surrogate συνδέεται με ένα Router. Επίσης υπάρχει η δυνατότητα για σύνδεση με ένα τυχαίο επιπλέον αριθμό από Routers, έτσι ώστε να αποφεύγονται τα παράλογα bottlenecks γύρο από τους Surrogates.. Εικόνα 4 Κατασκευή και σύνδεση των Surrogates (SS) 8) Κατασκευάζονται με διαδοχικές εντολές PARASOL και εισαγωγές στην δομή των Client Groups τόσα Client Groups όσος είναι ο αριθμός των Surrogates. 9) Συνδέεται κάθε Client Group μόνο με ένα Surrogate. Ένας Surrogate δεν μπορεί να είναι συνδεμένος με περισσότερα από ένα Client Groups. 16

17 Εικόνα 5 Κατασκευή και σύνδεση των Client Groups ( C ) 10) Μετά το τέλος της προσομοίωσης τα πάντα καταστρέφονται. Το κόστος κατασκευής και καταστροφής είναι γραμμικό και εξαρτάται από τον αριθμό των κόμβων και από τον αριθμό των Links. Μετά την κατασκευή τα πάντα ταξινομούνται (QuickSort για τα Links και τους Routers, InsertionSort για τους άλλους κόμβους) με βάση τα Ids για τους κόμβους και με βάση τον κόμβο πηγή για τα Links. Επεκτασιμότητα Προφανώς η αρχιτεκτονική της τοπολογίας επιδέχεται αρκετές βελτιώσεις ως προς την αποδοτικότητά της αλλά και ως προς την εισαγωγή νέων χαρακτηριστικών. Ως προς την αποδοτικότητα στόχος είναι η ελάττωση της απαιτούμενης ποσότητας μνήμης (αν και βρίσκεται σε λογικά πλαίσια) και η υλοποίηση δομών αποθήκευσης που οδηγούν σε γρηγορότερες αναζητήσεις (π.χ. Β+ tree). Στα νέα χαρακτηριστικά ανήκει η υλοποίηση αλγορίθμων τοποθέτησης των κόμβων (εκτός των Routers) με κάποια λογική (π.χ. Hot-spot). Επειδή μία τοπολογία δεν αποτελείται αποκλειστικά από τέσσερα είδη κόμβων αλλά από μία πληθώρα ανομοιογενών κόμβων και συνδέσμων, θα ήταν ιδανικό να εισάγονταν κι άλλες κατηγορίες (π.χ. DNS Servers). 17

18 3 Διαχείριση αντικειμένων Ίσως η μεγαλύτερη πρόκληση στην υλοποίηση ενός προσομοιωτή CDN είναι η αρχιτεκτονική των σκληρών δίσκων (caches) των Servers. Την λειτουργία των σκληρών δίσκων βοηθά μια κεντρική δομή όπου αποθηκεύονται όλα τα αντικείμενα, με όλο το σύνολο των πληροφοριών που αφορούν το κάθε αντικείμενο. Το μοντέλο υποστηρίζει μεγάλο αριθμό (εκατομμύρια) αντικειμένων στη μνήμη χάρις στον αποδοτικό τρόπο υλοποίησης των σκληρών δίσκων των Servers 3.1 Κεντρική δομή Πριν ξεκινήσει η προσομοίωση φορτώνονται όλα τα αντικείμενα σε μία κεντρική δομή όπου αποθηκεύονται πλήρως όλες οι πληροφορίες που τα αφορούν. Η δομή αυτή παίζει το ρόλο αναφοράς στις αποθηκευμένες ιδιότητες των αντικείμένων. Αποτελεί υλοποίηση ενός δένδρου AVL (ισοζυγισμένο δυαδικό δένδρο αναζήτησης) όπου κάθε κόμβος έχει ένα objectid, που τον χαρακτηρίζει μοναδικά, και επιπλέον πληροφορίες για το αντικείμενο (μέγεθος σε bytes). Το objectid και το μέγεθος σε bytes διαβάζονται από αρχείο στην αρχή της προσομοίωσης και παραμένουν αμετάβλητα μέχρι το τέλος (δηλαδή δεν δημιουργούνται / καταστρέφονται αντικείμενα κατά την διάρκεια της προσομοίωσης). Επίσης, υποστηρίζονται διαδικασίες αναζήτησης, εισαγωγής και ανάκτησης πληροφορίας από αυτή τη δομή. Το κόστος κατασκευής είναι : objectsreferencestructure Construction = O x log 2 (O) όπου: O είναι ο αριθμός των αντικειμένων. objectsreferencestructure Construction είναι ο χρόνος κατασκευής της δομής. Το κόστος αναζήτησης είναι: objectsreferencestructure Seek = log 2 (O) όπου: είναι ο αριθμός των αντικειμένων. objectsreferencestructure Seek είναι ο χρόνος αναζήτησης ενός αντικειμένου. Η αναζήτηση γίνεται με βάση το objectid. Οι απαιτήσεις σε μνήμη της δομής είναι σχετικά μικρές, ας υποθέσουμε ότι Ο = τότε x 20(bytes του κάθε κόμβου AVL) = 9.5 MBs. Η επιλογή του AVL tree έγινε γιατί είναι εύκολα υλοποιήσιμη και αρκετά αποδοτική από πλευράς χρόνου αναζήτησης, για Ο = , αριθμός βημάτων αναζήτησης (συγκρίσεις) = 20 στην χειρότερη περίπτωση. Πρέπει να είναι διαθέσιμη καθολικά, δηλαδή να μην χρειάζεται να αποθηκεύουμε όλες τις πληροφορίες των αντικείμενων σε όλους 18

19 τους Servers ξανά, αλλά να αποθηκεύουμε δείκτες στην δομή γλιτώνοντας έτσι μνήμη αφού οι πληροφορίες είναι πάντοτε διαθέσιμες. 3.2 Διαπροσωπία (interface) σκληρών δίσκων Ανεξαρτήτως υλοποίησης πρέπει να υποστηρίζονται ορισμένες λειτουργίες που αφορούν το περιεχόμενο των σκληρών δίσκων. Πρέπει να υποστηρίζονται ερωτήματα της μορφής «Αντικείμενο Χ υπάρχει στη cache του Server Y;», «Ποιο είναι το μέγεθος σε bytes του Αντικειμένου Χ;» και ενέργειες της μορφής «Εισήγαγε το Αντικείμενο Χ στον Server Y», «Διέγραψε το Αντικείμενο Χ από τον Server Y». Από τις προηγούμενες απαιτήσεις η ενέργεια της διαγραφής στο μοντέλο δεν υποστηρίζεται γιατί η τρέχουσα προσέγγιση εστιάζεται σε στατική cache, δηλαδή το περιεχόμενο της παραμένει αμετάβλητο. Οι προδιαγραφές αυτές αποτελούν το interface της λειτουργίας των σκληρών δίσκων. Η υλοποίηση τους γίνεται με βάση τα bloom filters, τα οποία και θα εξεταστούν στο επόμενο κεφάλαιο. 3.3 BLOOM filters Στην προηγούμενη παράγραφο αναφέραμε τις προδιαγραφές λειτουργίας των σκληρών δίσκων. Η υλοποίηση (implementation) έχει ως βάση τα bloom filters [1, 2]. Ας δούμε αρχικά γιατί πρέπει να γίνει η χρήση τους. Έστω ότι έχουμε ένα σύνολο από αντικείμενα και αυτό που μας ενδιαφέρει είναι να τα εισάγουμε σε μια cache και αργότερα να κάνουμε ερωτήματα για το αν υπάρχει κάποιο αντικείμενο στη cache και ποιο είναι το μέγεθός του σε bytes. Η μία προσέγγιση είναι να κατασκευάσουμε μια δομή (π.χ. AVL tree) η οποία θα αποθηκεύει τα αντικείμενα σε ωμή μορφή, οπότε αν κατά μέσο όρο αποθηκεύουμε αντικείμενα και έχουμε 100 Servers τότε οι απαιτήσεις σε μνήμη είναι x 20 x 100 = 381 MBs. Εναλλακτική προσέγγιση είναι να γίνεται αποθήκευση πληροφορίας για το αν υπάρχει ή δεν υπάρχει κάποιο αντικείμενο στη cache και για το μέγεθος του σε byte να ανατρέχουμε σε μία δομή όπου είναι αποθηκευμένα τα αντικείμενα με όλες τις πληροφορίες τους. Αν υποθέσουμε ότι έχουμε αντικείμενα και ένα διάνυσμα bits για κάθε Server χρειαζόμαστε μέχρι στιγμής x 100 = 12MBs. Κάθε διάνυσμα αναπαριστά την cache του κάθε Server ως εξής: αν το iστο στοιχείο ενός διανύσματος είναι «1» τότε το αντικείμενο με objectid = i υπάρχει στη cache, αλλιώς αν το iστο στοιχείο ενός διανύσματος είναι «0» τότε το αντικείμενο με objectid = i δεν υπάρχει στη cache. Με αυτό τον τρόπο αποθηκεύσαμε πληροφορία για το αν υπάρχει / δεν υπάρχει ένα αντικείμενο. Την επιπλέον πληροφορία για το μέγεθος σε bytes την έχουμε αποθηκευμένη σε μία κεντρική δομή όπου είναι αποθηκευμένα όλα τα αντικείμενα και οι πληροφορίες τους, με απαιτήσεις σε μνήμη στην προκειμένη περίπτωση 19MBs. Με την 2 η μέθοδο έχουμε πολύ μεγάλη βελτίωση από πλευράς απαιτήσεων μνήμης. Η 2 η μέθοδος φαίνεται ότι αποδίδει καλά, αλλά αν ο αριθμός των αντικειμένων είναι τότε για 100 Servers χρειαζόμαστε x 100 = 12 GBs μνήμης (αν κάθε διάνυσμα έχει bits), ενώ για την πρώτη υλοποίηση το νούμερο είναι απλά τεράστιο. Τη λύση στο πρόβλημα δίνει η χρήση των bloom filters. Ας δώσουμε αρχικά τον 19

20 ορισμό τους. Ένα bloom filter είναι μία δομή που αποτελείται από α) ένα διάνυσμα από bits β) ένα σύνολο hash functions (συναρτήσεις κατακερματισμού). Το διάνυσμα είναι όμοιο με αυτό της 2 ης μεθόδου, αλλά με τη διαφορά πως δεν χρειάζεται το μέγεθος του να ισούται με το τον αριθμό των αντικειμένων και μάλιστα στόχος είναι να είναι κατά πολύ μικρότερο. Οι συναρτήσεις κατακερματισμού παίρνουν σαν είσοδο ένα αντικείμενο και σαν έξοδο έχουν μία θέση στο διάνυσμα. Προφανώς διαφορετικές hash functions δίνουν διαφορετική θέση για το ίδιο αντικείμενο, αλλά για το ίδιο αντικείμενο δίνουν πάντα τις ίδιες θέσεις. Το ανάποδο δεν ισχύει, δηλαδή για διαφορετικά αντικείμενα σαν είσοδο μπορεί να έχουμε την ίδια απόκριση σε κάποια hash function. Ας δούμε πως γίνονται οι διαδικασίες εισαγωγής, διαγραφής και ανάκτησης αντικειμένων: Για την εισαγωγή ενός αντικειμένου στη cache ενός Server πρέπει να ενεργοποιηθούν ( 1) όλα τα bits στο διάνυσμα τα οποία είναι έξοδοι των hash functions για αυτό το αντικείμενο Για την διαγραφή γίνεται η ίδια διαδικασία με την εισαγωγή με μόνη διαφορά ότι τα bits απενεργοποιούνται ( 0) Για την ανάκτηση παίρνουμε διαδοχικά τις θέσεις-εξόδους των hash functions και εξετάζουμε αν όλα τα bits = 1. Αν έστω και 1 bit = 0 τότε το αντικείμενο δεν υπάρχει στη cache. Αν όλα τα bits = 1 τότε το αντικείμενο υπάρχει και γίνεται ανάκτηση από την κεντρική δομή. Μειονεκτήματα Η χρήση των bloom filters προσφέρει πολύ σημαντική μείωση στις απαιτήσεις μνήμης αλλά έχει και πολύ σημαντικά μειονεκτήματα τα οποία πρέπει να ληφθούν υπόψη ώστε τα αποτελέσματα της προσομοίωσης να είναι ορθά. Αυτά είναι: 1. Θετική απάντηση σε ερώτηση για το αν υπάρχει ένα αντικείμενο στη cache, ενώ αυτό δεν υπάρχει. Το φαινόμενο (ονομάζεται false positive) και εμφανίζεται εξ αιτίας της φύσης των hash functions οι οποίες μπορεί να έχουν την ίδια έξοδο για διαφορετικά αντικείμενα. Για παράδειγμα, έστω το αντικείμενο Χ είναι στη cache και κατά την εισαγωγή του έχουν ενεργοποιηθεί τα bits 1, 3, 1004, τότε είναι πιθανό ένα αντικείμενο Υ, το οποίο δεν εισαχθεί από εμάς, να ζητηθεί και να προκύψει ότι υπάρχει επειδή οι hash functions επέστρεψαν 1, 3, 1004 και γι αυτό. Η χρήση περισσότερων του ενός hash function περιορίζει την πιθανότητα του φαινομένου. Η πιθανότητα προκύπτει από τον τύπο: όπου: P falsepositive = [ 1 (1-1/m) k x O ] k (1 e k x O / m ) k m ο αριθμός των bits του διανύσματος. K ο αριθμός των hash functions. Ο αριθμός των αποθηκευμένων αντικειμένων. 20

21 Οπότε αρκεί να βρεθεί τα ελάχιστο της συνάρτησης πιθανότητας ώστε να ελαχιστοποιηθεί το φαινόμενο με την προϋπόθεση ότι οι hash functions που χρησιμοποιήθηκαν είναι «καλές». 2. Αρνητική απάντηση σε ερώτηση για το αν υπάρχει ένα αντικείμενο στη cache, ενώ αυτό θα έπρεπε να υπάρχει αφού δεν έγινε ρητά διαγραφή. Το φαινόμενο (ονομάζεται false negative) και εμφανίζεται εξ αιτίας της φύσης των hash functions οι οποίες μπορεί να έχουν την ίδια έξοδο για διαφορετικά αντικείμενα. Για παράδειγμα, έστω το αντικείμενο Χ είναι στη cache, κατά την διαγραφή του έχουν απενεργοποιηθεί τα bit 1, 3, 1004, τότε είναι πιθανό ένα αντικείμενο Υ, το οποίο είχε εισαχθεί από εμάς πριν τη διαγραφή του X, να ζητηθεί και να προκύψει ότι δεν υπάρχει επειδή οι hash functions επέστρεψαν 1, 12, 199 όπου το bit στη θέση 1 = 0. Η χρήση περισσότερων του ενός hash functions περιορίζει την πιθανότητα του φαινομένου. Προφανώς το πρόβλημα αυτό δεν υπάρχει στο μοντέλο αφού δεν υπάρχουν διαγραφές αντικειμένων. 3. Η αφαίρεση πληροφορίας. Τα bloom filters μπορούν να δώσουν απαντήσεις σε ερωτήσεις ύπαρξης αντικειμένου αλλά όχι για ερωτήσεις που αφορούν τις ιδιότητες του. Για παράδειγμα αν μας ενδιαφέρει να βρούμε ποιο είναι το πιο παλιό (ορίζουμε την ιδιότητα παλαιότητα για τα αντικείμενα), κάτι το οποίο είναι μεταβλητό, η χρήση των bloom filters δεν είναι εφαρμόσιμη. Αρχιτεκτονική Η υλοποίηση της δομής και λειτουργίας των bloom filters γίνεται με την λογική «από το γενικό στο πιο ειδικό». Υπάρχει ένα στρώμα συναρτήσεων που γενικά αποθηκεύουν, διαγράφουν και ελέγχουν για ύπαρξη αντικειμένων. Στο επόμενο επίπεδο γίνεται το hashing (εκτέλεση των hash functions) και τελικά γίνεται ενεργοποίηση, απενεργοποίηση ή έλεγχος των bit. Έτσι πολύ εύκολα υποστηρίζονται διαφορετικές hash functions και γίνονται αλλαγές χωρίς να χαλάει το μοντέλο (εικόνα 6). Εικόνα 6 Αρχιτεκτονική bloom filters Χαρακτηριστικά, αν ο αριθμός των αντικειμένων το επιτρέπει, μπορεί να γίνει απενεργοποίηση των hash functions και να χρησιμοποιηθεί απλή αντιστοίχηση (bitmapping) «objectid θέση στο διάνυσμα», δηλαδή όπως στην δεύτερη προσέγγιση που είδαμε πιο πάνω. Μας δίνεται έτσι η δυνατότητα να έχουμε πιο γρήγορες προσομοιώσεις, αφού δεν είμαστε υποχρεωμένοι να κάνουμε συνεχές hashing και επίσης μηδενίζει την πιθανότητα για false positive. Η πολυπλοκότητα εξαρτάται μόνο από τον 21

22 αριθμό των hash συναρτήσεων και από το κόστος hashing της κάθε hash function. Επεκτασιμότητα Προφανώς όλα τα παραπάνω αποτελούν μια προσέγγιση που επιδέχεται βελτιώσεις τροποποιήσεις και επεκτάσεις. Ξεκινώντας από την κεντρική δομή αποθήκευσης αντικειμένων, το AVL tree θα μπορούσε να αντικατασταθεί από ένα Β+ tree το οποίο στα φύλλα θα είχε δείκτες σε θέσεις αρχείου ώστε να υποστηρίζονται αριθμοί αντικειμένων της τάξης των δισεκατομμυρίων μειώνοντας παράλληλα τις απαιτήσεις σε μνήμη. Τα bloom filters θα μπορούσαν να αντικατασταθούν με Β+ trees όπως πριν, έτσι ώστε να μπορούν να αποθηκευτούν μεταβλητές πληροφορίες. Αν και όλες αυτές οι πιθανές αλλαγές προσφέρουν ευελιξία και δραματική μείωση των απαιτήσεων σε μνήμη, αυξάνουν τον αριθμό των προσπελάσεων στη cache δίσκο του υπολογιστή όπου τρέχει η προσομοίωση αυξάνοντας τον χρόνο εκτέλεσης. 22

23 4 Πρωτόκολλο IP Στα πλαίσια προσομοίωσης ενός δικτύου CDN ανήκει η υλοποίηση ενός πρωτοκόλλου επικοινωνίας των κόμβων για την ανταλλαγή αρχείων. Όπως στο internet έτσι και εδώ έχει υλοποιηθεί ένα πρωτόκολλο επικοινωνίας μεταξύ ανομοιογενών κόμβων αποκλειστικά για την μεταφορά δεδομένων. Ο ρόλος ενός τέτοιου πρωτοκόλλου είναι αυτός του στρώματος επικοινωνίας, το οποίο διευκολύνει την επικοινωνία διεργασιών που εκτελούνται σε διαφορετικούς κόμβους, αποκρύπτοντας το τι συμβαίνει με την τοπολογία δικτύου, όσων αφορά την ανομοιογένεια και την δομή του. Το IP είναι ένα πρωτόκολλο το οποίο πληροί την παραπάνω ανάγκη και γι αυτό το λόγο έχει υλοποιηθεί ως ένα βαθμό στο μοντέλο. Το IP υποστηρίζει πάρα πολλές λειτουργίες και υπηρεσίες, οι οποίες δεν χρειάζονται σε ένα μοντέλο προσομοίωσης. Η υλοποίηση του πρωτοκόλλου έχει περιοριστεί στις στοιχειώδεις λειτουργίες που αφορούν την μεταφορά αρχείων. 4.1 Περιγραφή πρωτοκόλλου Αρχικά ας περιγράψουμε το τι πρέπει να υποστηρίζεται και τι δυνατότητες θα πρέπει να μας παρέχονται από το πρωτόκολλο. 1. Επικοινωνία (ανταλλαγή μηνυμάτων) μεταξύ δύο οποιοδήποτε κόμβων λαμβάνοντας υπ όψιν τους ενδιάμεσους κόμβους. Θα πρέπει να υποστηρίζεται η κατάλληλη διαδικασία για την δημιουργία σύνδεσης και αποστολής πακέτων. 2. Ασφαλή επικοινωνία, με την έννοια να μην έχουμε απώλειες μηνυμάτων ή τουλάχιστο χωρίς προειδοποίηση. 3. Αποστολή μηνυμάτων με αποδοτικό τρόπο, λαμβάνοντας υπ όψιν την δομή του δικτύου. 4. Υποστήριξη κάθε τύπου δεδομένων για μεταφορά με ενθυλάκωση. 5. Ορισμός διάρκειας ζωής του κάθε μηνύματος έτσι ώστε να μην υπάρχουν μηνύματα στο δίκτυο τα οποία το επιβαρύνουν χωρίς αυτά να βρίσκουν τελικά τον προορισμό τους. 6. Αποφυγή συνωστισμού στο δίκτυο αλλάζοντας πιθανές διαδρομές μετάδοσης. 7. Υποστήριξη πεδίου checksum (ακολουθία ελέγχου) για εντοπισμό λαθών στα μηνύματα. Όλες οι παραπάνω απαιτήσεις έχουν ληφθεί υπ όψιν και έχουν υλοποιηθεί με αποδοτικό τρόπο. 4.2 Βασικές αρχές λειτουργίας Πριν προχωρήσουμε ας περιγράψουμε σύντομα τις βασικές αρχές λειτουργίας του δικτύου. Η βασική και ελάχιστη μονάδα μετάδοσης είναι το ipdatagram. Ένα ipdatagram ορίζεται ως μία αυτόνομη μονάδα η οποία περιέχει τι απαραίτητες πληροφορίες γα να μπορεί να μεταδοθεί στο δίκτυο. Ορίζουμε τις εξής δυνατές αμφίδρομες επικοινωνίες μεταξύ κόμβων : Surrogate [Router1 Router2 - - RouterN] Surrogate Client Group neighbor Surrogate 23

24 Origin [Router1 Router2 - - RouterN] Surrogate Επικοινωνία Client Groups με μη γειτονικούς Surrogate Servers δεν επιτρέπεται, αφού έρχεται σε αντίθεση με την λογική «ένας Surrogate για ένα Client Group». Παρατηρούμε ότι συνεργασία Surrogates με άλλους Surrogates και Origins υποστηρίζεται μόνο μέσω Routers που σημαίνει επιπλέον επικοινωνιακό κόστος. Οι Routers παίζουν το ρόλο του αναμεταδότη των μηνυμάτων φροντίζοντας την ελάττωση του φόρτου δικτύου και την προώθηση των ipdatagrams στους τελικούς κόμβους-στόχους. Από προγραμματιστικής πλευράς ορίζουμε δυο τύπους μηνυμάτων: Μηνύματα τα οποία «ταξιδεύουν» μέσω των Links προκαλώντας τις απαραίτητες καθυστερήσεις Μηνύματα που για την μετάδοση τους δεν χρησιμοποιούνται Links αλλά άμεση αποστολή χωρίς καθυστερήσεις. Ο 1 ος τύπος μηνυμάτων χρησιμοποιείται για τη μετάδοση δεδομένων, ενώ ο 2 ος για την μετάδοση μηνυμάτων τύπου ack ή nack (θετική απάντηση ή αρνητική απάντηση). Αυτό γίνεται γιατί το μοντέλο δικτύου προβλέπει την αποτυχημένη μετάδοση μηνυμάτων. Επομένως πρέπει να υποστηρίζεται ένας μηχανισμός ενημέρωσης του αποστολέα του μηνύματος ότι η αποστολή ήταν ανεπιτυχής. Ο αποστολέας αναμένει ένα μήνυμα επαλήθευσης (ack, nack για επιτυχημένη και αποτυχημένη μετάδοση) έτσι ώστε να συνεχίσει την μετάδοση κι άλλων μηνυμάτων ή να προκαλέσει αναμετάδοση. Αν αυτό το μήνυμα επαλήθευσης αποσταλεί μέσω δικτύου υπάρχει κίνδυνος να χαθεί προκαλώντας μόνιμο μπλοκάρισμα του αρχικού αποστολέα και όλη η προσομοίωση αποτυχαίνει. Γι αυτό το λόγο αυτά τα μηνύματα επαλήθευσης δεν αποστέλλονται μέσω δικτύου αλλά άμεσα στον κόμβο που αναμένει την λήψη τους ακαριαία και με μηδενικό κόστος δικτύου και μηδενικής προόδου του χρόνου. Η εισαγωγή αυτών των μηνυμάτων δεν ακυρώνει την ορθότητα του μοντέλου, αλλά το κάνει πιο στιβαρό. Αυτό εξηγείται από το γεγονός ότι ο αρχικός αποστολέας είναι υπεύθυνος για την καταστροφή του μηνύματος και την απελευθέρωση μνήμης μετά από επιτυχημένη αποστολή. Προφανώς δεν γίνεται αντιγραφή του αρχικού μηνύματος σε κάθε μετάδοση μεταξύ κόμβων γιατί αυτό είναι μη αποδοτικό και οδηγεί σε σπατάλη μνήμης. Για μια τυπική προσομοίωση ο αριθμός των μηνυμάτων μπορεί να ανέρχεται σε εκατοντάδες εκατομμύρια. Αυτό που γίνεται είναι η μετάδοση όχι του πραγματικού μηνύματος αλλά ενός δείκτη στο αρχικό μήνυμα, προσέγγιση η οποία είναι αποδοτική και ταχύτατη. Για της αποστολές μηνυμάτων μέσω Links χρησιμοποιείται η εντολή Parasol ps_link_send ενώ για τις απευθείας αποστολές χρησιμοποιείται η εντολή ps_send. 4.3 Υλοποίηση πρωτοκόλλου Ένα ipdatagram περιέχει τα εξής πεδία: 1. srcnode, είναι ο κόμβος που στέλνει το μήνυμα και συγκεκριμένα το ID του. 2. destnode, ο τελικός κόμβος που πρόκειται να λάβει το μήνυμα και συγκεκριμένα το ID του. 24

25 3. timestamp είναι η χρονική στιγμή που κατασκευάστηκε το μήνυμα. Στο μοντέλο ενώ υποστηρίζεται δεν χρησιμοποιείται. 4. ttl, ο χρόνος για τον οποίο το μήνυμα επιτρέπεται να κυκλοφορεί στο δίκτυο πριν να καταστραφεί ή φθάσει στον τελικό κόμβο-στόχο. Στο μοντέλο ενώ υποστηρίζεται δεν χρησιμοποιείται. 5. hopttl, ο μέγιστος αριθμός φορών που επιτρέπεται ένα μήνυμα να σταλεί από κόμβο σε κόμβο πριν να καταστραφεί ή πριν να φτάσει στον τελικό κόμβο-στόχο. Σε κάθε μετάβαση του μηνύματος από κόμβο σε κόμβο το hopttl ελαττώνεται κατά 1. Όταν hopttl = 0 και δεν έχει φθάσει στον τελικό κόμβο τότε καταστρέφεται. Η χρησιμοποιούμενη τιμή είναι το διπλάσιο του μήκους του path. 6. OK, πεδίο Boolean το οποίο όταν είναι αληθές το μήνυμα είναι σωστό, σε αντίθετη περίπτωση το μήνυμα είναι λάθος και πρέπει να καταστραφεί. 7. path, το προτεινόμενο μονοπάτι που πρέπει να ακολουθήσει το μήνυμα έτσι ώστε να φθάσει γρηγορότερα στον τελικό προορισμό. Το μονοπάτι αυτό προέκυψε κατά την κατασκευή των Router tables. 8. size, το μέγεθος του μηνύματος σε bytes. Στο μοντέλο ο χρήστης ορίζει το μέγεθος του μηνύματος. Προφανώς μεγαλύτερες τιμές size προκαλούν μεγαλύτερες καθυστερήσεις στις μεταδόσεις του μηνύματος.. 9. data, είναι η καθαρή πληροφορία (payload) που ενδιαφέρει τον τελικό αποδέκτη. Οι Routers παίζουν το ρόλο του αναμεταδότη των μηνυμάτων όπως αναφέραμε πιο πάνω. Δεν μεταβάλουν καθόλου to payload. Αυτό που έχουν δικαίωμα να μεταβάλουν είναι το προτεινόμενο path και το hopttl. Το γεγονός ότι προτείνεται ένα μονοπάτι δεν σημαίνει απαραίτητα ότι θα φθάσει το μήνυμα το συντομότερο δυνατό. Αν το μήνυμα περάσει από περιοχή η οποία έχει μεγάλο φόρτο δικτύου τότε μεγαλύτερες καθυστερήσεις προκύπτουν. Ακόμη αν ο φόρτος είναι αρκετά μεγάλος τότε μπορεί ο τρέχον Router να κρίνει απαραίτητο να ακυρωθεί το προτεινόμενο μονοπάτι. Πιο συγκεκριμένα έχουμε την εξής πολιτική αναμετάδοσης μηνύματος από ένα Router: 1. Έλεγχος για το αν το τρέχον ipdatagram πρέπει να απορριφθεί, δηλαδή αν το ttl ή hopttl ή το OK είναι άκυρα. 2. Προσομοίωση ότι έχει πραγματοποιηθεί ένα hop. 3. Έλεγχος για το αν υπάρχει προτεινόμενο μονοπάτι μέσα στο ipdatagram. Αν υπάρχει τότε γίνεται συνέχεια στο βήμα 4. Σε αντίθεση περίπτωση γίνεται ανάκτηση του αποδοτικότερου μονοπατιού από τα Router tables με αρχικό κόμβο τον τρέχον Router και τελικό τον τελικό κόμβο που υποδεικνύεται από το ipdatagram. 4. Γίνεται προσπάθεια για αποστολή του μηνύματος στον επόμενο κόμβο τόσες φορές όσες ορίσει ο χρήστης. 5. Αν η αποστολή είναι επιτυχής γίνεται τότε δρομολογείται το επόμενο το ipdatagram με μετάβαση στο βήμα 1. Αλλιώς μετάβαση στο βήμα Καταστροφή του προτεινόμενου μονοπατιού και γίνεται αποστολή του ipdatagram σε ένα γειτονικό Router με τυχαίο τρόπο (αποφεύγοντας τον ίδιο που χρησιμοποιήθηκε στο βήμα 4). 7. Αν πάλι δεν είναι δυνατή η αποστολή τότε ενημερώνεται ο αρχικός αποστολέας για την αποτυχία μετάδοσης. 25

26 Σε κάθε μετάδοση μηνύματος κάθε κόμβος περιμένει ack ή nack από τον άμεσα επόμενο κόμβο. Ο αρχικός αποστολέας περιμένει ένα επιπλέον ack ή nack από τον τελικό κόμβο για επαλήθευση ενός μετάδοσης. Οι Surrogates και οι Origins συμπεριφέρονται όπως οι Routers όσων αφορά την προσπάθεια για αναμετάδοση με μόνη διαφορά ότι δεν σταματάνε αν δεν αποσταλεί το μήνυμα. Η φιλοσοφία της επικοινωνίας είναι ότι αν ξεκινήσει δεν σταματάει αν δεν επιτύχει πλήρως, δηλαδή αν ξεκινήσει η μεταφορά ενός αρχείου από έναν Surrogate δεν πρόκειται να σταματήσει αν δεν ολοκληρωθεί πλήρως η μετάδοση του. 26

27 5 Router Tables Στην περιγραφή του πρωτοκόλλου IP έγινε αναφορά στην έννοια Router tables (πίνακες δρομολόγησης). Η έννοια αυτή έρχεται σε αντιστοιχία με τα Router tables που έχουν στην πραγματικότητα οι Routers. Στο πλαίσιο αυτό, οι Router tables περιέχουν ένα σύνολο από δομές μονοπατιών των οποίων ο αριθμός ισούται με αυτό των συνολικών κόμβων. Μια δομή μονοπατιού περιέχει τα εξής: 1. Τον κόμβο πηγή. 2. Ένα διάνυσμα στο οποίο βρίσκονται πακεταρισμένες όλες οι συντομότερες διαδρομές από των κόμβο πηγή προς όλους τους άλλους. 3. Ένα διάνυσμα στο οποίο αποθηκεύονται τα κόστη επικοινωνίας των παραπάνω διαδρομών. Πριν προχωρήσουμε στην ανάλυση ας εξηγήσουμε κάποιες έννοιες που εισάγονται για πρώτη φορά. 1. Κόστος διαδρομής (μονοπατιού) i.j, όπου i είναι ο κόμβος πηγή και j ο τελικός κόμβος ορίζεται ως το άθροισμα το κόστους επικοινωνίας των Links που απαρτίζουν το μονοπάτι (π.χ. μονοπάτι: 1->2->3->4, Κόστος = κόστος(1->2) + κόστος(2->3) + κόστος(3->4) ). Το κόστος επικοινωνίας για δύο άμεσα γειτονικούς κόμβους ορίζεται από τον τύπο: CommunicationCost k,l = ( 1 LinkSpeed k,l / maxlinkspeed k,l ) όπου: CommunicationCost k,l είναι το κόστος επικοινωνίας μεταξύ των συνδεμένων κόμβων k, l. LinkSpeed k,l η ταχύτητα του Link με την οποία συνδέονται οι δύο κόμβοι. maxlinkspeed k,l είναι η μέγιστη ταχύτητα που μπορεί να έχει ένα Link η οποία ορίζεται από τον χρήστη και αποτελεί άνω όριο στις ταχύτητες των Links και λειτουργεί ως παράγοντας κανονικοποίησης στον τύπο ώστε το αποτέλεσμα να αναχθεί σε κλίμακα Το κόστος διαδρομής προκύπτεί από : PathCost ( i,j ) = ( allhopscommunicationcost ) όπου: PathCost ( i,j ) είναι το κόστος του μονοπατιού από τον κόμβο I στον κόμβο j. allhopscommunicationcost είναι το σύνολο των κοστών επικοινωνίας CommunicationCost όλων των Links που απαρτίζουν το μονοπάτι. 27

28 2. Συντομότερο μονοπάτι που ενώνει δύο κόμβους i, j είναι αυτό που προκύπτει από την εφαρμογή του αλγορίθμου Dijkstra στο δίκτυο για κόμβο πηγής τον i. Το συντομότερο μονοπάτι i -> -> j δεν συνεπάγεται ότι το ανάποδο μονοπάτι j -> -> i είναι το συντομότερο, λόγο διαφορετικότητας του δικτύου. Η ασφαλής προσέγγιση είναι να γίνει ξανά Dijkstra με κόμβο πηγή τον κόμβο j. Το συντομότερο μονοπάτι προκύπτει με το κριτήριο του κόστους διαδρομής που αναφέρθηκε πιο πάνω. 5.1 Κατασκευή των Router Tables Πριν παρουσιαστούν τα βήματα κατασκευής των Router tables ας δούμε πως έχει υλοποιηθεί ο αλγόριθμος Dijkstra. Η ρουτίνα που εφαρμόζει τον αλγόριθμο ορίζεται ως εξής: PATH Dijkstra(sourceNode, LINKSMANAGER, notselectablenodeids) Όπου: PATH είναι η δομή μονοπατιού η οποία επιστρέφεται από τον αλγόριθμο. sourcenode είναι ο κόμβος πηγή. LINKSMANAGER μια δομή που περιέχει όλα τα Links notselectablenodeids μια δομή που περιέχει τα IDs των κόμβων που δεν πρέπει να επιλεχθούν ως ενδιάμεσοι κόμβοι για την βελτιστοποίηση των μονοπατιών. Σε κάθε κλήση της ρουτίνας γίνεται υπολογισμός όλων των συντομότερων μονοπατιών και των κοστών τους από τον κόμβο-πηγή προς όλους τους άλλους κόμβους αποφεύγοντας την χρήση των notselectablenodeids σαν ενδιάμεσους κόμβους στα μονοπάτια. Όπου η δημιουργία μονοπατιού δεν είναι εφικτή λόγο μη συνδεσμικότητας του γράφου ή λόγο των notselectablenodeids το κόστος που θεωρείται είναι άπειρο (ΙΝΤ_ΜΑΧ). Η αποθήκευση όλων των μονοπατιών γίνεται ως εξής: Κατασκευάζεται ένα διάνυσμα από IDs κόμβων με μήκος όσος είναι ο αριθμός όλων των κόμβων. Θεωρούμε την αντιστοιχία «iοστη θέση του διανύσματος ID του οποίου η τιμή είναι i». Στο διάνυσμα στη θέση i = ID του sourcenode θέτουμε την τιμή sourcenode. Οι υπόλοιπες θέσεις του διανύσματος παίρνουν τιμές τέτοιες ώστε να μπορεί να γίνεται αναδρομικά η ανάκτηση μονοπατιών. Η ανάκτηση ενός μονοπατιού (sourcenode ->. -> destnode) γίνεται ως εξής o Ανατρέχουμε στη θέση destnode του διανύσματος. Η θέση αυτή περιέχει τo ID του προηγούμενου του destnode κόμβου στο μονοπάτι. Στη συνέχεια πηγαίνουμε στο διάνυσμα στη θέση που ισούται με το ID του προηγούμενου του destnode. Η διαδικασία συνεχίζεται αναδρομικά μέχρι να καταλήξουμε στο sourcenode οπότε έχει κατασκευασθεί και το μονοπάτι. 28

29 Η αποθήκευση των κοστών επικοινωνίας είναι απλή. Απλά όταν μας ενδιαφέρει το κόστος επικοινωνίας μεταξύ δυο κόμβων ανατρέχουμε στο διάνυσμα όπου αποθηκεύονται τα κόστη στη θέση του τελικού κόμβου και παίρνουμε την τιμή που έχει αποθηκευτεί. Στο διάνυσμα των κοστών υπάρχει η ίδια αντιστοιχία που περιγράφτηκε στο διάνυσμα των μονοπατιών. Στη βιβλιογραφία η πολυπλοκότητα του Dijkstra είναι Ν 2 όπου Ν είναι ο αριθμός των κόμβων. Στην προκείμενη περίπτωση η πολυπλοκότητα είναι : Dijkstra = Ν 2 x log 2 (N) λόγο της δομής όπου είναι αποθηκευμένα τα Links. Τα βήματα για την κατασκευή των Router tables είναι τα ακόλουθα: 1. Κατασκευή μονοπατιών χρησιμοποιώντας όλους τους Surrogates ως κόμβους-πηγή και εισαγωγή τους στα Router tables, μη χρησιμοποιώντας ως ενδιάμεσους κόμβους τους Origins, Surrogates και Client Groups. 2. Κατασκευή μονοπατιών χρησιμοποιώντας όλα τα Client Groups ως κόμβους-πηγή και εισαγωγή τους στα Router tables, μη χρησιμοποιώντας ως ενδιάμεσους κόμβους τους Origins, Surrogates, Routers και Client Groups. 3. Κατασκευή μονοπατιών χρησιμοποιώντας όλους τους Routers ως κόμβους-πηγή και εισαγωγή τους στα Router tables, μη χρησιμοποιώντας ως ενδιάμεσους κόμβους τους Origins, Surrogates, και Client Groups. 4. Κατασκευή μονοπατιών χρησιμοποιώντας όλους τους Origins ως κόμβους-πηγή και εισαγωγή τους στα Router tables, μη χρησιμοποιώντας ως ενδιάμεσους κόμβους τους Origins, Surrogates, και Client Groups. 5. Ταξινόμηση μονοπατιών με βάση τον κόμβο-πηγή. Τα Router tables είναι στατικά αφού μέσα στις προϋποθέσεις λειτουργίας της προσομοίωσης είναι να παραμένει αμετάβλητη η τοπολογία δικτύου. Το κόστος κατασκευής τους είναι: RouterTables = Ν 3 x log 2 (N) πολυπλοκότητα αρκετά μεγάλη αφού κατασκευάζουμε όλα τα μονοπάτια από όλους τους κόμβους σε όλους. Εναλλακτικός αλγόριθμος είναι αυτός του Floyd με πολυπλοκότητα N 3 αλλά με πολύ μεγάλες απαιτήσεις σε μνήμη λόγο adjacency matrix. Η κατασκευή των Router tables είναι χρονοβόρα και γι αυτό υπάρχει η δυνατότητα για αποθήκευση τους σε αρχείο για μελλοντική χρήση σε περίπτωση που η τοπολογία είναι ακριβώς η ίδια. Οι απαιτήσεις σε μνήμη είναι αρκετά μεγάλες, π.χ. για ένα δίκτυο 5000 κόμβων, 5000 x ( για τα δύο διανύσματα) x 6 (bytes για αποθήκευση ενός αριθμού) = 286 MBs. Επεκτασιμότητα Αν και η υλοποίηση δουλεύει ικανοποιητικά υπάρχει ακόμη περιθώριο για βελτίωση. Πολύ σημαντική είναι η επιτάχυνση της διαδικασίας κατασκευής των Router tables με τη χρήση πιο γρήγορων δομών όπως αυτής του σωρού μεγίστων για την εύρεση κάθε φορά του γρηγορότερου συνδέσμου στον αλγόριθμο του Dijkstra. Η αυτόματη επιλογή μεταξύ Dijkstra και Floyd, ο 2 ος να επιλέγεται όταν ο γράφος του δικτύου είναι μικρός και πυκνός, θα ήταν μια 29

30 μέθοδος για επιτάχυνση της διαδικασία κατασκευής. Επίσης θα μπορούσε να χρησιμοποιηθεί κάποια δομή B+ tree για την αποθήκευση και προσπέλαση των Router tables από το σκληρό δίσκο όπου εκτελείται η προσομοίωση ώστε να μειωθούν οι απαιτήσεις σε RAM. Όσων αφορά το IP μπορεί να βελτιωθεί η διαχείριση των ipdatagrams από τους Routers αναφορικά με την αναδρομολόγηση τους. Επίσης θα μπορούσαν να προστεθούν κι άλλα χαρακτηρίστηκα στο πρωτόκολλο σε περίπτωση που αλλάξουν οι απαιτήσεις (π.χ. υποστήριξη ασφάλειας δεδομένων). 30

31 6 Πρωτόκολλο TCP Είδαμε μέχρι στιγμής την περιγραφή του πρωτοκόλλου IP για την μεταφορά δεδομένων στο δίκτυο. Από μόνο του όμως δεν αρκεί για την υποστήριξη επικοινωνίας για ανταλλαγή αρχείων. Το IP μεταφέρει απλά δεδομένα χωρίς να έχει γνώση του είδους της πληροφορίας που μεταφέρει. Ερωτήματα όπως «μεταφέρθηκε όλο το αρχείο;», «σε πόσα κομμάτια πρέπει να σπάσει το αρχείο για να μεταφερθεί;» δεν ικανοποιούνται με τη χρήση αποκλειστικά του IP. Επομένως έρχεται το πρωτόκολλο TCP ένα επίπεδο πιο πάνω από το IP να αναλάβει την πλήρη επικοινωνία μεταξύ δύο peers σε δύο διαφορετικούς κόμβους αδιαφορώντας πλήρως για την τοπολογία δικτύου που βρίσκεται ανάμεσά τους. Στην πραγματικότητα τα δύο πρωτόκολλα δεν είναι ανεξάρτητα μεταξύ τους αλλά συμπληρώνει το ένα το άλλο παρέχοντας το ένα στο άλλο υπηρεσίες και πληροφορίες που είναι χρήσιμες για την επικοινωνία. Στο μοντέλο έχει γίνει μια αφαιρετική υλοποίηση του TCP και επειδή είναι εμπνευσμένο από αυτό θα αναφερόμαστε σε αυτό με το ίδιο όνομα. 6.1 Περιγραφή πρωτοκόλλου Αρχικά ας περιγράψουμε το τι πρέπει να υποστηρίζεται και τι δυνατότητες θα πρέπει να μας παρέχονται. Επικοινωνία χωρίς απώλεια δεδομένων, δηλαδή ανεκτικότητα σε σφάλματα. 1. Αποφυγή μπλοκαρίσματος του αποδέκτη και του αποστολέα με χρήση κανόνα χειραψίας (βλ στη συνέχεια). 2. Επικοινωνία μεταξύ peers αδιαφορώντας πλήρως για το δίκτυο που βρίσκεται ενδιάμεσα. 3. Μεταφορά παντός τύπου δεδομένων. Όλες οι παραπάνω απαιτήσεις έχουν ληφθεί υπ όψιν και έχουν υλοποιηθεί με αποδοτικό τρόπο. 6.2 Βασικές αρχές λειτουργίας Το IP σχεδιάστηκε για την μεταφορά δεδομένων μεταξύ ανομοιογενών κόμβων ενώ το TCP για επικοινωνία που αφορά μόνο τον αρχικό κόμβοαποστολέα και τον τελικό κόμβο παραλήπτη. Στο αντίστοιχο κεφάλαιο θα περιγραφεί η έννοια των tasks (διεργασίες). Εδώ δεν θα γίνει εκτενής αναφορά. Το μόνο χρειάζεται να γνωρίζουμε είναι ότι οι διεργασίες εκτελούνται σε κόμβους παράλληλα και έχουν την δυνατότητα να στέλνουν μηνύματα και να δέχονται μέσω των ports τους πόρτες επικοινωνίας). Ένας peer μπορεί να μοντελοποιηθεί με tasks. Άρα το πρόβλημα ανάγεται στην κατασκευή μιας δομής μηνύματος TCP η οποία θα περιέχει πληροφορίες απαραίτητες μόνο για τον αρχικό και τελικό peer. Η ελάχιστη μονάδα πληροφορίας στο TCP ονομάζεται tcpsegment. Όπως αναφέρθηκε και στην περιγραφή του πρωτοκόλλου IP ένα ή περισσότερα tcpsegments αποτελούν το payload (χρήσιμα δεδομένα) του ipdatagram. Αντίστοιχα το payload ενός tcpsegment είναι οποιαδήποτε πληροφορία. Στο μοντέλο ένα ipdatagram περιέχει μόνο ένα tcpsegment για λόγους ευκολίας υλοποίησης. Στο tcpsegment το payload περιέχει ή το ID ενός αντικειμένου το οποίο ζητείται ή 31

32 τίποτα. Πραγματική μετάδοση του αντικειμένου με την έννοια μεταφοράς πραγματικών bytes δεν γίνεται γιατί δεν έχει νόημα. Δεν έχει νόημα γιατί το μόνο που μας ενδιαφέρει είναι η καθυστέρηση του δικτύου που προκαλείται λόγο μεταφοράς (ικανοποιείται με το IP), και το πότε ξεκινάει και τελειώνει η μεταφορά, πράγμα το οποίο διαχειρίζεται το TCP. 6.3 Υλοποίηση πρωτοκόλλου Ένα tcpsegment περιέχει τα εξής πεδία: 1. srcport είναι το port του peer που στέλνει το μήνυμα και στο οποίο δέχεται απαντήσεις (acknowledgements ack ή nack ή δεδομένα). 2. destport είναι το port του peer που αποδέχεται το μήνυμα και στο οποίο δέχεται τα μηνύματα.. 3. ok πεδίο Boolean το οποίο όταν είναι αληθές το μήνυμα είναι σωστό, σε αντίθετη περίπτωση το μήνυμα είναι λάθος και πρέπει να αναμεταδοθεί. 4. data τα πραγματικά δεδομένα που μεταφέρει το μήνυμα. Εικόνα 7 Οπτική αναπαράσταση του τελικού μηνύματος Για να γίνει κατανοητή η λειτουργία μιας σύνδεσης ας δούμε πως δουλεύει σε βήματα. Χρόνος / Κατάσταση σύνδεσης Πελάτης Εξυπηρέτης έναρξη προσπάθειας σύνδεσης Κατασκευή μηνύματος αίτησης μεταφοράς αντικειμένου. Στο μήνυμα περιέχεται και το object ID Αποστολή του μηνύματος Αναμονή Αναμονή Αναμονή Λήψη του μηνύματος Έλεγχος αν μπορεί να ικανοποιηθεί η αίτηση. Τέλος (αποτυχία) Τέλος Αν όχι αποστολή nack Αναμονή Αν ναι αποστολή ack Λήψη ack Αποστολή ack για εκκίνηση αποστολής του αρχείου. Τέλος (επιτυχία) Αναμονή Λήψη ack για εκκίνηση αποστολής του αρχείου. Έναρξη αποστολής Αναμονή Σπάσιμο του αρχείου σε 32

33 του αρχείου Τέλος (επιτυχία) Έναρξη τερματισμού σύνδεσης Τέλος σύνδεσης Αναμονή Τα κομμάτια λαμβάνονται Αποκωδικοποιούνται και γίνεται έλεγχος για σφάλματα. Για κάθε μήνυμα στέλνεται ack ή nack αν είναι σωστό ή λάθος Αναμονή Επανάληψη μέχρι να ληφθούν όλα τα κομμάτια του αρχείου. Αναμονή Λήψη μηνύματος αίτησης τερματισμού σύνδεσης Αποστολή ack Αναμονή κομμάτια (μεγέθους ορισμένου από τον χρήστη ipdatagram size) Τα κομμάτια στέλλονται πακεταρισμένα σε ipdatagrams αφού έχουν πρώτα πακεταριστεί σε tcpsegments. Αναμονή Αναμονή Αναμονή Λαμβάνονται τα acks και nacks και γίνεται αναμετάδοση στην περίπτωση των nacks. Επανάληψη μέχρι να αποσταλούν όλα τα κομμάτια του αρχείου. Αποστολή μηνύματος αίτησης τερματισμού σύνδεσης Αναμονή Αναμονή Λήψη ack Αποστολή ack Αναμονή Λήψη ack Πίνακας 1 Διαδικασία εγκατάστασης σύνδεσης Κάθε διεργασία η οποία περιμένει να δεχθεί ένα μήνυμα στο port της μπλοκάρεται μέχρι να το δεχθεί (έτσι ορίστηκε στο μοντέλο). Επίσης, μπορεί να φθάνουν περισσότερα από ένα μηνύματα στο port τα οποία μπαίνουν αυτόματα σε ουρά προτεραιότητας. Όπως φαίνεται από τον πίνακα 1 ενδιαφέρον παρουσιάζεται στην διαδικασία έναρξης και τερματισμού της σύνδεσης. Η διαδικασία επιτυχούς έναρξης της σύνδεσης και ομαλού τερματισμού της γίνεται σε τρία βήματα και ονομάζεται three steps handshake (τριών βημάτων χειραψία). Η διαδικασία γίνεται για να μην μπλοκαρισθεί κανένας peer περιμένοντας κάποιο μήνυμα. Στην πραγματικότητα η διαδικασία αυτή υπάρχει αλλά εκεί εισάγεται και η έννοια του timeout (μέγιστο χρονικό διάστημα αναμονής μηνύματος) οπότε αν χαθεί κάποια απάντηση δεν μπλοκάρεται κανένας peer. Στο μοντέλο δεν χρησημοποιείται η έννοια του timeout για λόγους απλότητας. Για την ακρίβεια δεν χρειάζεται αφού τα 33

34 μηνύματα έναρξης και τερματισμού όπως και όλα τα acks και nacks δεν αποστέλλονται μέσω δικτύου αλλά άμεσα στο port του παραλήπτη χωρίς κίνδυνο να χαθούν. Επίσης δεν πρόκειται να μπλοκαρισθεί ο παραλήπτης γιατί όλα τα ipdatagrams έχουν hopttl οπότε πριν απορριφθούν από ένα Router ενημερώνεται ο αποστολέας στο port του με nack αφού γίνει αποκωδικοποίηση του ipdatagram και στη συνέχεια του tcpsegment για την εύρεση του port του αποστολέα. Είναι σημαντικό να επιλέγεται αρκετά μεγάλο hopttl έτσι ώστε να καταφέρνουν να φθάσουν τα ipdatagrams στον παραλήπτη. Διακρίνονται τρεις φάσεις κατά την διάρκεια της επικοινωνίας: 1. Έναρξη σύνδεσης. Κατά την φάση ένας πελάτης, Client Group στην απλή περίπτωση ή Surrogate Server σε περίπτωση συνεργατικών CDNs, στέλνει ένα μήνυμα τύπου «αίτηση σύνδεσης» στο οποίο περιέχεται το objectid του αντικειμένου που ζητείται για αποστολή. Η μέθοδος εισαγωγής επιπλέον πληροφορίας σε μια αίτηση σύνδεσης ονομάζεται piggybacking. Ο Surrogate ελέγχει αν ισχύουν οι προϋπόθεσης για τη μεταφορά αρχείου. Οι προϋποθέσεις μπορεί να είναι α)το αν είναι διαθέσιμο στον στη cache, β)αν μπορεί να γίνει διαθέσιμο με μεταφορά από άλλο Server και γ)αν δεν έχει φθάσει ο Server τον μέγιστο αριθμό συνδέσεων. Σε περίπτωση που μπορεί να γίνει σύνδεση αποστέλλεται μήνυμα τύπου «αποδοχή σύνδεσης». Σε αντίθετη περίπτωση αποστέλλεται μήνυμα τύπου «απόρριψη σύνδεσης» και η προσπάθεια σύνδεσης αποτυγχάνει και εγκαταλείπεται. Αν όλα πάνε καλά ο πελάτης στέλνει μήνυμα «έναρξη μετάδοσης» και αναμένει από εδώ και πέρα ipdatagrams που αφορούν το αρχείο που ζητήθηκε. 2. Αποστολή του αρχείου. Κατά την φάση αυτή υπολογίζεται ο αριθμός των ipdatagrams που αντιστοιχεί στο αντικείμενο που ζητήθηκε. Ο αριθμός υπολογίζεται από τον τύπο : noofipdatagrams = objectsizeinbytes / maxipdatagramsizeinbytes +1 (η διαίρεση είναι ακέραια και προσθέτουμε 1 για να αποφύγουμε μηδενική τιμή σε περίπτωση που objectsizeinbytes < maxipdatagramsizeinbytes ) όπου: noofipdatagrams είναι ο αριθμός των πακέτων. objectsizeinbytes είναι το μέγεθος του αρχείου σε bytes maxipdatagramsizeinbytes το μέγεθος του κάθε ipdatagram έτσι όπως έχει ορισθεί από τον χρήστη στις ρυθμίσεις. Τα ipdatagrams που αποστέλλονται δεν έχουν καμιά πληροφορία σχετικά με το αντικείμενο μιας και δεν ενδιαφέρει τον παραλήπτη. Δεν υπάρχει περίπτωση ο παραλήπτης να δεχθεί δυο φορές το ίδιο το ipdatagram γιατί ο αποστολέας μπλοκάρεται μέχρι να δεχθεί ack ή nack. Με αυτή τη λογική θα έπρεπε να στέλνονται ένα-ένα τα ipdatagrams. Αυτό όμως δεν ισχύει γιατί ο κόμβος που εξυπηρετεί τον πελάτη «επιστρατεύει» πολλά απλά tasks για την αποστολή των πακέτων. Ο αριθμός ταυτόχρονων αποστολών ipdatagrams ορίζεται από τον χρήστη. Πριν αναφέραμε ότι σε αυτή τη φάση οι απαντήσεις του παραλήπτη μπορεί να είναι ack ή nack. Ack αποστέλλεται όταν το πεδίο ok του tcpsegment είναι αληθές, όταν το πεδίο ok του ipdatagram είναι 34

35 αληθές, το ttl >= 0 και όταν το hopttl >= 0. Αν και το πρωτόκολλο υποστηρίζει σφάλματα μετάδοσης, στο μοντέλο δεν γίνεται παραγωγή λαθών. Οπότε αποστέλλονται μόνο σωστά ipdatagrams και ο μόνος λόγος για απόρριψη κάποιου ipdatagram (αποστολή nack) είναι το hopttl αφού το ttl δεν χρησιμοποιείται από το μοντέλο. 3. Τερματισμός σύνδεσης. Η φάση αυτή ξεκινάει όταν ο αποστολέας λάβει ack για το τελευταίο ipdatagram. Ο αποστολέας στέλνει μήνυμα τύπου «αίτηση τερματισμού σύνδεσης». Ο παραλήπτης αμέσως απαντά με μήνυμα τύπου «αποδοχή αίτησης τερματισμού σύνδεσης». Τέλος ο αποστολέας απαντά με μήνυμα τύπου «τέλος σύνδεσης» όπου τελειώνει και η επικοινωνία οριστικά και ομαλά. Από τα παραπάνω μπορούμε να κάνουμε τις εξής παρατηρήσεις: Αν ξεκινήσει επιτυχώς μια σύνδεση δεν τερματίζεται παρά μόνο όταν ολοκληρωθεί η μεταφορά του αρχείου. Δεν γίνεται επανάληψη προσπάθειας σύνδεσης σε περίπτωση απόρριψης. Επεκτασιμότητα Η υλοποίηση του πρωτοκόλλου στο μοντέλο ήταν στοιχειώδης και ικανοποιούσε την απλή απαίτηση για μετάδοση αντικειμένων. Η υλοποίηση αφήνεται ανοιχτή σε προτάσεις μιας και μπορεί να επεκταθεί σε πολύ εξεζητημένες λειτουργίες που ξεφεύγουν από τα πλαίσια της παρουσίασης. 35

36 7 Διεργασίες (Tasks) Σε προηγούμενες ενότητες έχει γίνει αναφορά στην έννοια των tasks. Εδώ θα γίνει εκτενής ανάλυση του τρόπου λειτουργίας τους στο μοντέλο. Επίσης θα παρουσιαστεί η εσωτερική λειτουργία του μοντέλου και το πώς έρχονται εις πέρας οι διάφορες ενέργειας σε θέματα που έχουν παρουσιαστεί σε προηγούμενες ενότητες. 7.1 Ορισμός των tasks Με τον όρο task στην Parasol ορίζουμε μία συνάρτηση που ανήκει σε ένα κόμβο και μπορεί να εκτελείται παράλληλα μαζί με άλλα tasks τα οποία ανήκουν στον ίδιο κόμβο. Τα tasks μπορεί να έχουν απαιτήσεις σε ιδεατό χρόνο επεξεργαστή και με βάση τις απαιτήσεις αυτές και κάποιο αλγόριθμο δρομολόγησης εκτελείται κάθε χρονική στιγμή το αντίστοιχο task. Δεν μας ενδιαφέρει στο μοντέλο η μετρική του χρόνου επεξεργασίας και γι αυτό κανένα task απαιτεί χρόνο ιδεατού επεξεργαστή του κόμβου που ανήκει. Η μη απαίτηση χρόνου επεξεργασίας δεν αυξάνει το ρολόι της προσομοίωσης και τα tasks εκτελούνται αμέσως. Η εντολή για την δημιουργία ενός task είναι: ps_create2(name, node, cpu, void(*class_code)(void), priority, stacksize) όπου: task το ID του καινούριου task που κατασκευάζεται. name το όνομα του task. node το ID του κόμβου στον οποίο θέλουμε να ανήκει το task. cpu το ID του επεξεργαστή του κόμβου αν θέλουμε να «τρέχει» σε συγκεκριμένο μόνο επεξεργαστή. Αν δεν μας ενδιαφέρει, η τιμή ANY_HOST χρησιμοποιείται. void (*class_code)(void) ένας δείκτης στη συνάρτηση που θα περιέχει τον κώδικα του task. Η συνάρτηση δεν επιτρέπεται να δέχεται ορίσματα αλλά ούτε και να επιστρέφει κάτι. Αν θέλουμε να κάνουμε κάτι γνωστό στη συνάρτηση χρησιμοποιούμε μηνύματα ή καθολικές μεταβλητές. priority η προτεραιότητα εκτέλεσης του task όταν πρέπει να εκτελεστούν πολλά tasks παράλληλα στον κόμβο. Χρησιμοποιείται από τον αλγόριθμο δρομολόγησης που ορίστηκε κατά την κατασκευή του node. stacksize ένας πραγματικός αριθμός που δηλώνει πόσες φορές περισσότερη μνήμη να δεσμευτεί, για το task, από την προεπιλεγμένη τιμή. Η τιμή πρέπει να είναι 1 τις περισσότερες φορές, εκτός και αν υπάρχουν πολλές αναδρομικές κλήσεις μέσα στη συνάρτηση. Η Parasol παρέχει τη διαγνωστική συνάρτηση ps_headroom() η οποία αν κληθεί μέσα από το task επιστρέφει τον αριθμό των bytes που απομένουν μέχρι να γίνει υπερχείλιση της μνήμης. Όλα τα IDs των tasks αποθηκεύονται στις δομές που περιγράφηκαν στην ενότητα των κόμβων ανάλογα με το σε ποιο κόμβο ανήκουν. 36

37 δομή: Έστω ότι ορίζουμε ένα task να χρησιμοποιηθεί έχει την παρακάτω void footask( void ) {return; Πίνακας 2 Παράδειγμα στοιχειώδους TASK Με μία κλήση στην ps_create2 κατασκευάζουμε ένα task το οποίο βρίσκεται στην κατάσταση SUSPENDED δηλαδή δεν εκτελείται. Με την εντολή ps_resume(taskid) το task συμμετέχει στην δρομολόγηση και εκτελείται. Στο παράδειγμα η εκτέλεση θα σταματήσει και το task θα καταστραφεί, αφού δεν έχουμε εισάγει κάποια εντολή που να απαιτεί ιδεατό επεξεργαστή κόμβου. Ακόμη και να είχαμε κάποια εντολή απαίτησης χρόνου επεξεργαστή το task θα καταστρεφόταν μετά το τέλος της εκτέλεσης. Η καταστροφή και η επαναδημιουργία tasks είναι ακριβή διαδικασία από πλευράς χρόνου και επικίνδυνη από πλευράς μοντελοποίησης, αφού θέλουμε να μοντελοποιήσουμε peers με tasks οι οποίοι να είναι γνωστοί καθολικά και αμετάβλητοι. Για τον λόγο αυτό δεν θέλουμε να καταστρέφονται τα tasks. Μια μέθοδος για την διατήρηση τους είναι να μπαίνουν σε ατέρμονα βρόχο. Ας δούμε τις παρακάτω εντολές: 7.2 Χρήσιμες εντολές Parasol ps_receive(port, timeout, type, timestamp, text, ack_port) Η εντολή λαμβάνει ένα μήνυμα που έχει σταλεί σε κάποιο port του task. Όπου: port είναι η θύρα επικοινωνίας στην οποία αναμένουμε μηνύματα, δηλαδή από την οποία θα παραλάβουμε το μήνυμα. Κάθε task έχει μια προεπιλεγμένη θύρα επικοινωνίας, αλλά μπορεί να έχει και περισσότερες με την χρήση της εντολής ps_allocate_port. timeout ο χρόνος για τον οποίο το task που καλεί την εντολή θα μπλοκαρισθεί περιμένοντας ένα μήνυμα. Με το που λάβει ένα μήνυμα η εκτέλεση του task συνεχίζεται. Στο μοντέλο χρησιμοποιείται η τιμή NEVER που σημαίνει ότι περιμένει συνεχώς μέχρι λάβει κάποιο μήνυμα. type εδώ αποθηκεύεται ο τύπος του μηνύματος. Οι τύποι ορίζονται από τον χρήστη. timestamp εδώ αποθηκεύεται η χρονική στιγμή κατά την οποία έγινε αποστολή του μηνύματος. text Η Parasol ορίζει το μήνυμα ως δείκτη σε δείκτη χαρακτήρων. Δεν υπάρχει πρόβλημα όμως να αδιαφορήσουμε για τον τύπο του δείκτη και να δείχνουμε π.χ. σε ένα ipdatagram. Αν δεν μας ενδιαφέρει να στείλουμε κάποιο μήνυμα, όπως στην περίπτωση του ack / nack τότε η τιμή NULL χρησιμοποιείται. ack_port με αυτή την παράμετρο ο αποστολέας κάνει γνωστή την θύρα από την οποία δέχεται μηνύματα και περιμένει απαντήσεις. 37

38 ps_link_send(link, port,, size, text, ack_port) Η εντολή αυτή στέλνει ένα μήνυμα σε μια θύρα μέσω ενός Link προσομοιώνοντας την καθυστέρηση μετάδοσης λαμβάνοντας υπ όψιν το μέγεθος του μηνύματος που έχει δηλωθεί. Η εντολή δεν μπλοκάρει την εκτέλεση του task, δηλαδή με τα την εκτέλεσή της η εκτέλεση του task συνεχίζει. Όπου: link είναι το ID του Link μέσω του οποίου θα γίνει η μετάδοση. port είναι το ID της θύρας στην οποία θα αποσταλεί το μήνυμα. Το task του στο οποίο ανήκει η θύρα θα πρέπει να βρίσκεται σε κόμβο οποίος να είναι συνδεμένος με κάποιο Link με τον κόμβο ο οποίος περιέχει το task που στέλνει το μήνυμα. type είναι ο τύπος του μηνύματος που στέλνει ο αποστολέας. Ο τύπος ορίζεται από τον προγραμματιστή. size είναι το μέγεθος σε bytes του μηνύματος. Προσοχή, δεν ταυτίζεται με το πραγματικό μέγεθος σε bytes που καταλαμβάνει το μήνυμα στη μνήμη, είναι το μέγεθος που θέλουμε να προσομοιώσει το Parasol στην μετάδοση προκαλώντας τις κατάλληλες καθυστερήσεις. ack_port είναι η θύρα στην οποία θέλουμε να απαντήσει ο παραλήπτης. ps_send(port, type, text, ack_port) Η εντολή αυτή είναι ακριβώς ίδια με την ps_link_send με μόνη διαφορά ότι η αποστολή του μηνύματος δεν γίνεται,μέσω Link αλλά απευθείας στην θύρα του παραλήπτη. Δεν υπάρχει καθυστέρηση στην μετάδοση, δηλαδή γίνεται ακαριαία. Με αυτή την μέθοδο γίνονται αποστολές μηνυμάτων ελέγχου (ack, nack, αιτήσεις για σύνδεση, αιτήσεις για αποσύνδεση, και απορρίψεις συνδέσεων) τα οποία είναι σημαντικό να μην χαθούν λόγο φόρτου δικτύου. δομή: Έστω ότι ορίζουμε ένα task να χρησιμοποιηθεί έχει την παρακάτω void footaskalwaysaliveandrecieving( void ) { for(;;) { ps_receive(port, NEVER, type, timestamp, text, ack_port); return; Πίνακας 3 Παράδειγμα TASK σε συνεχή κατάσταση RECEIVING Εδώ το task καταστρέφεται μόνο όταν τελειώσει η προσομοίωση. Βρίσκεται σε κατάσταση αναμονής περιμένοντας να δεχθεί ένα μήνυμα. Μόλις το δεχθεί περιμένει να δεχθεί τα επόμενο και η διαδικασία συνεχίζεται μέχρι το τέλος.. 38

39 Έστω ότι ορίζουμε ένα task να χρησιμοποιηθεί έχει την παρακάτω δομή: void footaskalwaysaliveandsending( void ){ for(;;) { ps_link_send(link, port, type, size, text, ack_port); return; Πίνακας 4 Παράδειγμα TASK συνεχή κατάσταση SENDING Εδώ το task καταστρέφεται μόνο όταν τελειώσει η προσομοίωση. Βρίσκεται σε συνεχώς σε κατάσταση εκτέλεσης στέλνοντας μηνύματα συνέχεια. Η εκτέλεση του δεν διακόπτεται καθόλου. Ας δούμε τις παρακάτω εντολές: Ps_suspend(task) Η εντολή αυτή μπλοκάρει έπ αόριστον το task με ID = task, δηλαδή μπαίνει στην κατάσταση SUSPENDED. Μόνο κάποιο άλλο task μπορεί με την χρήση της ps_resume(taskid) να ξεμπλοκάρει το task και να συνεχίσει την εκτέλεση του. Με αυτή την δυνατότητα μπορούμε να έχουμε μια συλλογή από tasks (pool) τα οποία θα γίνονται ps_resume από ένα άλλο task το οποίο το οποίο έχει διευθυντικό ρόλο. Τα tasks που ανήκουν στο pool εκτελούν την εργασία που έχουν αναλάβει και στη συνέχεια εκτελούν την ps_suspend(ps_myself), μπλοκάρονται και είναι έτοιμα ανά πάσα στιγμή να γίνουν διαθέσιμα για επόμενη εργασία. Με αυτό τον τρόπο, μπορούμε να κατασκευάζουμε περιορισμένης δυναμικότητας κόμβους ως προς τον φόρτο εργασίας. Το μέγεθος της pool χαρακτηρίζει την δυναμικότητα. Ps_sleep(duration) Η εντολή αυτή μπλοκάρει την εκτέλεση ενός του task που την καλεί για χρόνο duration. Μετά το χρονικό διάστημα η εκτέλεσή του συνεχίζεται κανονικά. Η εντολή δεν απαιτεί χρόνο ιδεατού επεξεργαστή, απλά μπλοκάρει την εκτέλεση για τον καθορισμένο χρόνο. Χρησιμοποιείται στο IP στην περίπτωση συνεχούς προσπάθειας μετάδοσης ενός ipdatagram σε ένα Router. Πριν δοκιμαστεί εναλλακτικός Router γίνεται ένας προκαθορισμένος αριθμός προσπαθειών με διαφορά χρόνου χρησιμοποιώντας την ps_sleep. 7.2 Μοντελοποίηση των ports Σε κάθε task κατασκευάζουμε στο μοντέλο μια επιπλέον θύρα (port) πέραν της προκατασκευασμένης. Από τις δυο θύρες η μια είναι αφιερωμένη για επικοινωνία με άλλα tasks μέσα στον ίδιο κόμβο και η άλλη για επικοινωνία με tasks διαφορετικών κόμβων. Σε κάποιες περιπτώσεις η ίδια θύρα χρησιμοποιείται και για ενδοεπικοινωνία και για επικοινωνία με άλλους κόμβους. 39

40 Εικόνα 8 Παράδειγμα task1 Με κόκκινο χρώμα συμβολίζουμε το port εξωτερικής επικοινωνίας και με μπλε αυτό της ενδοεπικοινωνίας. Εικόνα 9 Παράδειγμα task2 Με πράσινο συμβολίζουμε τα ports εξωτερικής επικοινωνίας και ενδοεπικοινωνίας. 7.3 Μοντελοποίηση των κόμβων Σε κάθε κόμβο ορίζουμε ένα σύνολο από tasks. Κάποια tasks παίζουν το ρόλο διαχειριστή, δηλαδή αναθέτουν σε άλλα tasks του ίδιου κόμβου κάποια εργασία. Εικόνα 10 Παράδειγμα node Όλα τα παραπάνω tasks βρίσκονται στον ίδιο κόμβο (κύκλος). Το task με την ονομασία Father έχει μόνο διευθυντικό ρόλο. Δέχεται αιτήσεις από άλλα tasks άμεσα στο port του και όχι μέσω κάποιου Link. Τα μηνύματα χωρίς επικοινωνιακό κόστος συμβολίζονται με διακεκομμένο βέλος. Στη συνέχεια ελέγχει αν κάποιο task με την ονομασία Master είναι διαθέσιμο και του αναθέτει την ικανοποίηση της αίτησης. Στην προκειμένη περίπτωση τα Master tasks έχουν και διευθυντικό και ρόλο εργάτη. Αφού κάνουν μια προεπεξεργασία της αίτησης αναθέτουν σε ένα σύνολο από worker (εργάτες) tasks την περάτωση της αίτησης. Για παράδειγμα μπορεί το Master task να υπολογίζει το σύνολο των κομματιών στα οποία πρέπει να τεμαχιστεί ένα 40

41 αντικείμενο και να αναθέσει την μεταφορά τους στα worker tasks μέσω Link. Από το σχήμα είναι ξεκάθαρή η πεπερασμένη δυναμικότητα του κόμβου σε ικανοποίηση αιτήσεων (τρεις ταυτόχρονες αιτήσεις). Τα Master tasks είναι δεσμευμένα μέχρι την περάτωση της εργασίας όλων των workers. Όταν κάποιο task δεν εκτελεί κάποια εργασία θέτει τον εαυτό του σε κατάσταση SUSPENDED. Έτσι ο διευθυντής του κάθε task γνωρίζει ποια δουλεύουν και ποια όχι, χρησιμοποιώντας την εντολή ps_task_state( taskid ). Με την προϋπόθεση ότι κάθε Master έχει ένα συγκεκριμένο αριθμό από workers που μπορεί να χρησιμοποιήσει, τότε ο μέγιστος αριθμός αιτήσεων που μπορούν να ικανοποιηθούν ταυτόχρονα ισούται με αυτό τον Masters. Μέχρι να ικανοποιηθεί πλήρως μια αίτηση το αντίστοιχο Master task παραμένει δεσμευμένο (κατάσταση RUNNING), δηλαδή εκτελείται. Ένα-ένα τα worker tasks τα οποία ολοκληρώνουν την εργασία τους θέτουν τον εαυτό τους σε κατάσταση SUSPENDED. Όταν τελειώσουν όλα τότε και ο αντίστοιχος Master θέτει τον εαυτό του σε κατάσταση SUSPENDED και είναι διαθέσιμος. Το Father task δεν μπλοκάρεται ποτέ και δέχεται συνεχώς μηνύματα. Στο σχήμα υπονοούνται τα μηνύματα ack τα οποία στέλνει το ένα task στο άλλο για να δηλώσει ότι παρέλαβε το μήνυμα ή ότι τελείωσε την εργασία (στην περίπτωση των workers). 7.4 Μελέτη περιπτώσεων Είναι σκόπιμη η παρουσίαση του μοντέλου με την περιγραφή των περιπτώσεων για τις οποίες έχει κατασκευασθεί, ώστε να γίνει πιο κατανοητή η λειτουργία του. Οι περιπτώσεις αυτές είναι οι εξής: 1. Αίτηση Client Group για μεταφορά αντικειμένου από το γειτονικό Surrogate ο οποίος το έχει ήδη στη cache του. 2. Αίτηση Client Group για μεταφορά αντικειμένου από το γειτονικό Surrogate ο οποίος δεν το έχει ήδη στη cache του και το ζητά από άλλο Surrogate Server. 3. Αίτηση Client Group για μεταφορά αντικειμένου από το γειτονικό Surrogate ο οποίος δεν το έχει ήδη στη cache του και το ζητά από τον Origin Server. Μελέτη περίπτωσης 1 Το πρώτο βήμα στην μοντελοποίηση ενός συστήματος είναι η εύρεση των οντοτήτων που υπάρχουν και ποια η αλληλεπίδραση μεταξύ τους. Από την περίπτωση παρατηρούμε ότι πρέπει να μοντελοποιήσουμε τις έννοιες Client Group, Surrogate, cache, αίτηση. Η μοντελοποίηση της cache έχει ήδη περιγραφεί όπως και η αίτηση στο TCP. Υπάρχει όμως και μία ακόμη κρυμμένη οντότητα. Οι αιτήσεις πρέπει κάπως να παράγονται, οπότε εισάγεται η έννοια του requests generator ή RQ (παραγωγός αιτήσεων). O RQ στο μοντέλο είναι ένα task το οποίο διαβάζει από ένα αρχείο αιτήσεων αιτήσεις της μορφής «χρονική_στιγμή Client_group objectid», κατασκευάζει ένα μήνυμα τύπου «αίτηση» και το αποστέλλει τη χρονική_στιγμή στο κατάλληλο Client Group. Το μήνυμα περιέχει το objectid του αντικειμένου που πρέπει να ζητήσει το Client Group από τον γειτονικό Surrogate. Ο RQ βρίσκεται στον κόμβο 0. Η επιλογή του κόμβου 0 έγινε για να μην κατασκευαστεί ένας επιπλέον ακόμη κόμβος για να φιλοξενήσει τον RQ. Ο κόμβος 0 υπάρχει ήδη από την έναρξη της προσομοίωσης οπότε δεν υπάρχει λόγος για την κατασκευή ενός επιπλέον κόμβου. 41

42 Το αρχείο στο οποίο βρίσκονται οι αιτήσεις πρέπει να είναι ταξινομημένο με βάση το χρόνο με αύξουσα διάταξη. Ο RQ εκτελεί την ps_sleep(request_time ps_now) όπου: request_time η χρονική στιγμή που πρέπει να υποβληθεί η αίτηση και διαβάζεται από το αρχείο ps_now είναι μια εντολή που επιστρέφει τον τρέχοντα χρόνο της προσομοίωσης. Με την εντολή προκαλείται μπλοκάρισμα του RQ για χρόνο όσος είναι η διαφορά χρόνου της τρέχοντος χρόνου και αυτού της αίτησης. Αν πολλές αιτήσεις πρέπει να γίνουν ταυτόχρονα, καθώς διαβάζεται το αρχείο σειριακά, τότε εκτελείται για την 1 η αίτηση η εντολή ενώ για τις επόμενες όχι, π.χ. Έστω το ένα τμήμα του αρχείου αιτήσεων (trace file): Πίνακας 5 Παράδειγμα trace file Οι αντίστοιχες εντολές που θα εκτελεστούν είναι: (γιατί αρχικά ps_now = 0) ps_sleep(1 ps_now) ps_sleep(3 ps_now) ps_sleep(22 ps_now) Πίνακας 6 Παράδειγμα trace file με αντίστοιχες εντολές ps_sleep Με αυτό τον τρόπο επιτυγχάνεται η συνεχείς μετάδοση μηνυμάτων χωρίς την πρόοδο του χρόνου αφού το task είναι υποχρεωμένο να εκτελείται χωρίς διακοπή. Οι αιτήσεις αποστέλλονται στα Client Groups άμεσα και συγκεκριμένα στο port του Father task του κάθε Client Group. Η μοντελοποίηση των Client Groups βασίζεται στην λογική που περιγράφηκε σχετικά με τα tasks διευθυντές και εργάτες. Σε κάθε Client Group αντιστοιχούμε ένα κόμβο, ο οποίος περιέχει δυο ειδών tasks 1)το Father task 2)και τα Fetch Master tasks. Το father task παίζει διευθυντικό ρόλο, λαμβάνει τις αιτήσεις από το RQ και αναζητά το πρώτο Fetch Master task το οποίο είναι διαθέσιμο και του αναθέτει την αίτηση μέσω ενδοεπικοινωνιακού μηνύματος. Αν δεν υπάρχει διαθέσιμο Fetch Master task τότε το father task στέλνει nack στο RQ. Σε αντίθετη περίπτωση το Fetch Master task γίνεται ps_resume από το father 42

43 task και από κατάσταση SUSPENDED πηγαίνει στη RUNNING. Μόλις το Fetch Master task παραλάβει το μήνυμα στέλνει ack στο father task, το οποίο στη συνέχεια στέλνει ack στο RQ. Η παραπάνω διαδικασία γίνεται χωρίς χρονική καθυστέρηση. Η περίπτωση του να δέχεται το RQ nacks από Client Groups δεν δηλώνει υγιή κατάσταση της προσομοίωσης. Κανονικά τα Client Groups πρέπει να είναι σε θέση να δεχθούν όλες τις αιτήσεις και να τις δρομολογήσουν. Αν όμως δεν συμβαίνει κάτι τέτοιο θα πρέπει να αυξηθεί ο αριθμός των Fetch Master tasks ανά Client Group αυξάνοντας έτσι τον αριθμό των ταυτόχρονων αιτήσεων. Αν και πάλι το πρόβλημα δεν λυθεί τότε σημαίνει ότι τα Fetch Master tasks δεν γίνονται SUSPENDED, λόγο λάθους στον κώδικα ή λόγο κακού δικτύου προκαλώντας τρομερές καθυστερήσεις στην μετάδοση των αρχείων και στην απελευθέρωση των Fetch Master tasks. βήμα RQ Client Group 1 Διάβασμα από αρχείο της επόμενης αίτησης, ps_sleep αν χρειάζεται, αποστολή της αίτησης στο αντίστοιχο Client Group Father task αναμονή Fetch Master tasks εκτέλεση. 1 αναμονή Παραλαβή της αίτησης, έλεγχος αν υπάρχουν διαθέσιμα, Fetch Master tasks, αποστολή nack γιατί κανένα δεν είναι διαθέσιμο 1 Παραλαβή nack και συνέχεια Πίνακας 7 Το Client Group δεν έχει διαθέσιμο Fetch Master task βήμα RQ Client Group 1 Διάβασμα από αρχείο της επόμενης αίτησης, ps_sleep αν χρειάζεται, αποστολή της αίτησης στο αντίστοιχο Client Group Father task αναμονή Fetch Master tasks εκτέλεση, αναμονή. 1 αναμονή Παραλαβή της αίτησης, έλεγχος αν υπάρχουν διαθέσιμα, Fetch Master tasks 2 αναμονή Ps_resume το Fetch Master task το οποίο ήταν διαθέσιμο και Αποστολή αίτησης 3 αναμονή Παραλαβή ack από το Fetch Master task 4 αναμονή Αποστολή ack στο RQ 4 Παραλαβή ack και συνέχεια 43

44 Πίνακας 8 Το Client Group έχει διαθέσιμο Fetch Master task Όλα τα παραπάνω βήματα γίνονται άμεσα με μηδενικές χρονικές καθυστερήσεις. Τα Fetch Master tasks μπορούμε να τα φανταστούμε σαν απλούς πελάτες οι οποίοι προσπαθούν να συνδεθούν στο γειτονικό Surrogate ζητώντας την μεταφορά ενός αρχείου. Το RQ έχει την παρακάτω δομή : void RQTask ( void ){ for(all requests) { Get request from file or RAM ps_send(request to appropriate Client Group) ps_recieve(ack ή nack) show progress (if selected) return; Πίνακας 9 RQTask Όπως φαίνεται υπάρχουν 4 RQ. Ένα διαβάζει αιτήσεις από αρχείο, άλλο από τη μνήμη και αντίστοιχα για τις 2 περιπτώσεις εμφανίζεται ο αριθμός των αιτήσεων που έχουν παραχθεί ή όχι. Χρησιμοποιείται το αντίστοιχο κάθε φορά ανάλογα, το οποίο είναι επιλογή του χρήστη. Το Father task του Client Group έχει την ακόλουθη δομή: void cl_fathertask ( void ){ for(;;) { ps_recieve(request) look for available Fetch Master Task if(success) { ps_resume(fetch Master Task) ps_send(request to Fetch Master Task) ps_recieve(ack from Fetch Master Task) ps_send(ack to RQ) if(failed) { ps_send(nack στο RQ) return; Πίνακας 10 cl_fathertask Το Fetch Master Task του Client Group έχει την ακόλουθη δομή: void cl_fetchmastertask ( void ){ for(;;) { 44

45 ps_recieve(request) ps_send(ack to FatherTask) try to establish connection and get object from neighbour Surrogate Server ps_suspend(myself) return; Πίνακας 11 cl_fetchmastertask Έστω ότι το Fetch Master Task έχει παραλάβει την αίτηση. Το επόμενο βήμα είναι η προσπάθεια εγκατάστασης επικοινωνίας με τον γειτονικό Surrogate Server. Η διαδικασία είναι ακριβώς αυτή που περιγράφηκε στο TCP πρωτόκολλο. Το Fetch Master Task στέλνει μια αίτηση για σύνδεση συμπεριλαμβάνοντας το αντικείμενο που ζητείται. Το μήνυμα στέλνεται άμεσα στο port του Father Task του Surrogate. Στη συνέχεια το Father Task αναζητεί κάποιο διαθέσιμο Push Master Task για να αναλάβει την μετάδοση του αντικειμένου. Σε περίπτωση που δεν υπάρχει διαθέσιμο το Father Task στέλνει nack στο αντίστοιχο Fetch Master του Client Group που έκανε την αίτηση: Βήμα Fetch Master Task του Surrogate Server Client Group 5 Προετοιμασία και αποστολή αίτησης Father Task αναμονή Push Master Tasks εκτέλεση 6 Λήψη ack παραλαβής Παραλαβή αίτησης, αποστολή ack παραλαβής και έλεγχος αν υπάρχει διαθέσιμο Push Master Task 7 αναμονή Αποστολή nack γιατί δεν βρέθηκε κανένα διαθέσιμο 7 Παραλαβή nack και εισαγωγή σε κατάσταση SUSPENDED Πίνακας 12 Όχι διαθέσιμο Push Master Task Father Task αναμονή Push Master Tasks εκτέλεση Στην αντίθετη περίπτωση το father task κάνει ps_resume το διαθέσιμο Push Master task και αποστέλλει την αίτηση αναμένοντας απάντηση από αυτό. Το Push Master task λαμβάνει την αίτηση και απαντάει με ack στο Father Task ξεμπλοκάροντας το. Στη συνέχεια εξετάζει αν το ζητούμενο αντικείμενο υπάρχει στην cache. Αν δεν υπάρχει τότε η συμπεριφορά του εξαρτάται από την πολιτική που έχει υλοποιηθεί, παρακάτω θα παρουσιαστή η πολιτική των συνεργασίας. Ανεξαρτήτως πολιτικής, αν το ζητούμενο αντικείμενο δεν μπορεί να είναι διαθέσιμο τότε στέλνεται nack στο Fetch Master Task του Client Group που έκανε την αίτηση. Στην περίπτωση που υπάρχει στην cache, συνεχίζεται το handshake του TCP. Το Push Master Task υπολογίζει τον αριθμό των τεμαχίων του αντικειμένου που θα αποσταλεί και αναθέτει στα Simple Pusher Tasks την αποστολή τους. Η ανάθεση γίνεται με αποστολή 45

46 μηνύματος που περιέχει στοιχεία για τον αριθμό τον τεμαχίων που πρέπει να στείλει το καθένα και στοιχεία σχετικά με τον τελικό παραλήπτη. Μετά από κάθε αποστολή το Push Master Task περιμένει ack. Όταν τελειώσουν όλα τα Simple Pusher Tasks την εργασία τους στέλνουν ack στο Push Master Task και γίνονται SUSPENDED. Στέλνουν ack γιατί το Push Master Task μπλοκάρεται περιμένοντας να τελειώσουν όλα την μεταφορά τους. Η σύνδεση τελειώνει με handshake τερματισμού σύνδεσης που περιγράφτηκε στο TCP.Τα Simple Pusher Tasks μοιράζονται εξ ίσου στα Push Master Tasks. Δηλαδή αν τα Push Master Tasks είναι 10 και τα Simple Pusher Tasks 50 τότε αντιστοιχούν 5 Τα Simple Pusher Tasks ανά Push Master Task. Η πρακτική σημασία των Simple Pusher Tasks είναι ο ορισμός ενός άνω ορίου στην ταυτόχρονη αποστολή μηνυμάτων μεταφοράς αρχείου. Τα μηνύματα στέλνονται μέσω Links οπότε υπάρχουν και οι αντίστοιχες χρονικές καθυστερήσεις. Από όλη την διαδικασία που περιγράφηκε μέχρι στιγμής μόνο η μεταφορά των αρχείων προχωράει το ρολόι της προσομοίωσης, όλα τα άλλα γίνονται ακαριαία με μηδενικές χρονικές απαιτήσεις. Τα Simple Pusher Tasks μπορούν να μεταδώσουν αρχεία και σε οποιοδήποτε τύπο πελάτη (Client Group, συνεργατικό Surrogate). Βήμα Fetch Master Task του Surrogate Server Client Group 5 Προετοιμασία και αποστολή αίτησης Father Task αναμονή Push Master Tasks εκτέλεση, αναμονή 6 Λήψη ack παραλαβής Παραλαβή αίτησης, αποστολή ack παραλαβής και έλεγχος αν υπάρχει διαθέσιμο Push Master Task 7 αναμονή Αποστολή αίτησης στο διαθέσιμο Push Master Task και αναμονή για ack 8 αναμονή To Push Master Task παραλαμβάνει την αίτηση και στέλνει ack στο Father Task το οποίο ξεμπλοκάρεται. 8 αναμονή Το Push Master Task ελέγχει αν το ζητούμενο αντικείμενο είναι διαθέσιμο. 9 Παραλαβή nack και SUSPENDED Αν δεν μπορεί να γίνει διαθέσιμο τότε αποστέλλεται nack στο Fetch Master του Client Group που έχει κάνει την αίτηση και η απόπειρα σύνδεσης τελειώνει. 9 handshake Αν είναι διαθέσιμο, 46

47 γίνεται handshake 10 αναμονή Υπολογισμός τεμαχίων και ανάθεση σε Simple Pushers 10 αναμονή Τα Simple Pushers αποκρίνονται με ack 11 Λήψη μηνυμάτων και αποστολή ack / nack Τα Simple Pushers στέλνουν το αρχείο και για κάθε μήνυμα λαμβάνουν ack / nack 12 Τα Simple Pushers στέλνουν ack στο Push Master Task το οποίο ξεμπλοκάρεται. 13 handshake τερματισμού Γίνεται handshake τερματισμού Πίνακας 13 Υπάρχει διαθέσιμο Push Master Task 47

48 Εικόνα 11 Διαδικασία ικανοποίησης αίτησης 48

49 Πιο αναλυτικά το Fetch Master Task του Client Group έχει την ακόλουθη δομή: void cl_fetchmastertask ( void ){ for(;;) { ps_recieve(request) ps_send(ack to FatherTask) try to establish connection handshake if(success) { Get file and respond with ack/nack End connection handshake ps_suspend(myself) return; Πίνακας 14 cl_fetchmastertask το Father Task του Surrogate έχει την ακόλουθη δομή: void su_fathertask ( void ){ for(;;) { ps_recieve(request) ps_send(ack to immediate sender) look for available Push Master Task if(success) { ps_resume(push Master Task) ps_send(request to Push Master Task) ps_recieve(ack from Push Master Task ) ps_send(ack to initial sender) if(not success) { ps_send(nack to initial sender) ps_suspend(myself) return; Πίνακας 15 su_fathertask το Push Master Task του Surrogate έχει την ακόλουθη δομή: void su_pushmastertask ( void ){ for(;;) { ps_recieve(request) ps_send(ack to Father Task) look if object is available in local cache (or can become available ) 49

50 if(success) { Handshake with Client Calculate the number of segment for object ps_resume(as many Simple Pusher Tasks as needed)) ps_send(info to Simple Pusher Tasks)) wait all to finish( ps_recieve()) end connection handshake with Client if(not success) { ps_send(nack to Client) ps_suspend(myself) return; Πίνακας 16 su_pushmastertask το Simple Pusher Task του Surrogate έχει την ακόλουθη δομή: void su_simplepushertask ( void ){ for(;;) { ps_recieve(info) ps_send(ack to Push Master Task) if(client = Client Group) { for(μέχρι for all segment assigned to me) { ps_link_send(ipdatagram) ps_recieve(ack ή nack from πελάτη) if(nack){retransmit if(client = cooperative Surrogate) {.. ps_send(ack to Push Master Task) ps_suspend(myself) return; Πίνακας 17 su_simplepushertask Μελέτη περίπτωσης 2,3 Στην περίπτωση αυτή πρέπει να γίνει εισαγωγή τριών ακόμη οντοτήτων. Ο εναλλακτικός Surrogate, ο Origin Server και ο Router. Στο διάγραμμα της προηγούμενης περίπτωσης παρατηρούμε ότι ο κόμβος των Surrogate δεν περιέχει κάποιο task το οποίο είναι υπεύθυνο για την μεταφορά αντικειμένων από εναλλακτικούς Servers. Γι αυτό εισάγουμε μια καινούρια 50

51 κατηγορία tasks, τα Pull Master tasks, τα οποία αναλαμβάνουν τον εντοπισμό του καταλληλότερου Server για την μεταφορά αντικειμένων τα οποία έχουν ζητηθεί από το Client Group και δεν είναι διαθέσιμα στον στη cache. Ο Origin είναι πανομοιότυπος με τον Surrogate, με μόνη διαφορά ότι ο Origin δεν περιέχει Fetch Master tasks, αφού υποτίθεται ότι περιέχει όλα τα αντικείμενα που πιθανώς μπορεί να του ζητηθούν και δεν ενώνεται με κάποιο Client Group, εξ ορισμού της τοπολογίας. Ο Router αναλαμβάνει την μεταφορά των αντικειμένων από τους εναλλακτικούς Servers προσομοιώνοντας την ύπαρξη ενδιάμεσων κόμβων στο δίκτυο προκαλώντας καθυστερήσεις. Ας δούμε αναλυτικά σε βήματα την διαδικασία μεταφοράς από κάποιο Server (Surrogate ή Origin). Αρχικά ακολουθούνται όλα τα βήματα κανονικά μέχρι το βήμα 8, βλ προηγούμενη περίπτωση. Στο βήμα 8 «Το Push Master Task ελέγχει αν το ζητούμενο αντικείμενο είναι διαθέσιμο» ακολουθείται η εξής διαδικασία: 1. αν τα ζητούμενο αντικείμενο υπάρχει στον στη cache τότε έχουμε περίπτωση που μελετήσαμε. 2. αν το ζητούμενο αντικείμενο δεν υπάρχει στον στη cache τότε: a. Αναζητείται ο κοντινότερος Surrogate Server που περιέχει το αντικείμενο. Για το έλεγχο ύπαρξης του αντικειμένου αρκεί να γίνει έλεγχος στο bloom filter του κάθε Surrogate. Η απόσταση (κόστος επικοινωνίας) γίνεται με την βοήθεια των Router tables. b. Αναζητείται ο κοντινότερος Origin Server που περιέχει το αντικείμενο. Για το έλεγχο ύπαρξης του αντικειμένου αρκεί να γίνει έλεγχος στο bloom filter του κάθε Origin. Η απόσταση (κόστος επικοινωνίας) γίνεται με την βοήθεια των Router tables. c. Επιλέγεται τελικά ο κοντινότερος Server και αναζητείται το 1 ο διαθέσιμο Pull Master task. d. Αν δεν υπάρχει διαθέσιμο Pull Master task τότε η αίτηση του Client Group απορρίπτεται.. e. Αν δεν υπάρχει Server που να περιέχει το ζητούμενο αντικείμενο τότε υπάρχει κάποιο πρόβλημα στις ρυθμίσεις. f. Αν υπάρχει διαθέσιμο Pull Master task τότε ανατίθεται σε αυτό η μεταφορά του αντικειμένου από τον Server που επιλέχθηκε. Η ανάθεση γίνεται με την φιλοσοφία διευθυντής εργάτης που περιγράφηκε πιο πάνω. g. Το Push Master Task αναμένει ack ή nack για το αν έγινε η μεταφορά επιτυχώς ή όχι. h. Αν η μεταφορά ήταν επιτυχής τότε συνεχίζεται η μεταφορά του αντικειμένου στο Client Group που έκανε την αίτηση. i. Αν η μεταφορά ήταν αποτυχημένη (Denial of service) )τότε η σύνδεση με το Client Group που έκανε την αίτηση απορρίπτεται. Η διαδικασία μεταφοράς του αντικειμένου από άλλο Server βασίζεται πάλι στην λογική του handshake μεταξύ των Pull Master tasks και των Servers. Το αντικείμενο που μεταφέρεται τελικά δεν αποθηκεύεται μόνιμα στον τοπικό δίσκο, σύμφωνα με την πολιτική που έχει υλοποιηθεί. Τα Simple Pusher Tasks των Servers λαμβάνουν υπ όψιν τους την ύπαρξη ενδιάμεσων Routers. Για το λόγο αυτό κατασκευάζουν ένα ιδανικό μονοπάτι μεταφοράς δεδομένων χρησιμοποιώντας τα Router tables. Το μονοπάτι αυτό 51

52 αποθηκεύεται σε κάθε μήνυμα στο οποίο στέλνεται. Το πεδίο path στο ipdatagram αναφέρεται σε αυτό το μονοπάτι. Οι Routers λαμβάνουν μηνύματα από Simple Pusher Tasks ή άλλους Routers και αναλαμβάνουν να τα προωθήσουν σε επόμενο κόμβο. Ο επόμενος κόμβος μπορεί να είναι ο τελικός στόχος ή κάποιος επόμενος Router. Κάθε Router περιέχει ένα πεπερασμένο αριθμό από Route Master Tasks στα οποία αναθέτονται με τη λογική Διευθυντή εργάτη, από το Father Task του εκάστοτε Router, τα ipdatagrams που πρέπει να δρομολογηθούν σε επόμενο κόμβο. Η διαδικασία δρομολόγησης ενός ipdatagram από ένα Router γίνεται ως εξής: 1. Το Father Task βρίσκεται συνεχώς σε κατάσταση αναμονής μηνύματος. 2. Μόλις δεχτεί κάποιο ipdatagram τότε γίνεται έλεγχος αν υπάρχει διαθέσιμο Route Master Task για να αναλάβει την δρομολόγηση. 3. Αν δεν υπάρχει αποστέλλεται nack στον άμεσο αποστολέα (Router ή Server ) και πάλι στο βήμα1 4. Αν υπάρχει τότε ανατίθεται η δρομολόγηση με την λογική διευθυντής - εργάτης στο Route Master Task και στέλνεται ack στον άμεσο αποστολέα (Router ή Server ). 5. Το Route Master Task ακολουθεί την παρακάτω διαδικασία: a. Προσομοίωση hop για το τρέχον ipdatagram. Αν αποτύχει λόγο παραβίασης hopttl ή λόγο σφάλματος, αποκωδικοποιείται το ipdatagram και το tcpsegment αποστέλλεται nack στον αρχικό αποστολέα (Origin ή Surrogate) και η διαδικασία δρομολόγησης τελειώνει. b. Γίνεται έλεγχος για τον αν υπάρχει προτεινόμενο μονοπάτι μέσα στο ipdatagram. Αν όχι τότε κατασκευάζεται ένα, από τα Router tables. c. Εντοπίζεται ο επόμενος κόμβος. Αν είναι Surrogate τότε αποστέλλεται το μήνυμα απευθείας στο port του Pull Master task το οποίο περιέχεται στο tcpsegment και αναμένεται ack. Αν είναι Router τότε η διαδικασία είναι διαφορετική. Αρχικά αποστέλλεται το μήνυμα και αναμένεται ack. Αν έρθει nack τότε γίνεται προσπάθεια τόσες επιπλέον φορές όσες ορίσει ο χρήστης. Αν ο αριθμός των επαναλήψεων εξαντληθεί τότε καταστρέφεται το προτεινόμενο μονοπάτι, και αποστέλλεται το μήνυμα τυχαία σε κάποιο γειτονικό Router αποφεύγοντας τον προτεινόμενο. Αν και πάλι δεχτεί nack ή δεν υπάρχει άλλος εναλλακτικός Router τότε στέλνεται nack στον αρχικό αποστολέα. Η φιλοσοφία παραμένει η ίδια, για κάθε μήνυμα αντιστοιχεί και ένα ack, οπότε τα Pull Master task αφού παραλάβουν ένα μήνυμα στέλνουν ack στον άμεσο Router που έστειλε το μήνυμα και ack ή nack στον αρχικό αποστολέα αν η προσομοίωση hop ήταν επιτυχής ή αποτυχημένη. Επίσης και Simple Pusher Tasks γνωρίζουν ότι παρεμβάλλονται Routers οπότε αναμένουν κάθε φορά 2 acks ένα από τον άμεσα γειτονικό Router και ένα από τον τελικό παραλήπτη. Τα Simple Pusher Tasks των Surrogate Servers έχουν μηχανισμό αναδρομολόγισης (re-routing), όπως τα Route Master Tasks, σε περίπτωση αποτυχίας λόγο φόρτου του άμεσου γείτονα Router. Για τον λόγο αυτό κάθε Surrogate συνδέεται με περισσότερους από ένα Routers. Το ίδιο όμως δεν ισχύει και για τους Origins οι οποίοι είναι συνδεμένοι μόνο με έναν Surrogate 52

53 και δεν υποστηρίζουν re-routing. Όλα τα μηνύματα αποστέλλονται μέσω Links εκτός βέβαια από τα acks / nacks. Επίσης οι Routers δεν αντιγράφουν το κάθε μήνυμα, αλλά μεταφέρουν ένα δείκτη στο μήνυμα. Προσοχή πρέπει να δοθεί στο γεγονός ότι τα πεδία ενός μηνύματος όπως το path,hopttl μπορούν να μεταβληθούν κατά την διάρκεια δρομολόγησής τους, άρα ο αρχικός αποστολέας θα πρέπει να τα καταστρέφει κάθε φορά που δέχεται ack/nack και να αντικαθιστά με «φρέσκα» αντίγραφα. Αυτό είναι εμφανές στις περιπτώσεις re-routing, ή προσομοίωσης hop. Στην προσομοίωση hop γίνεται έλεγχος του πεδίου OK και μειώνεται το hopttl κατά μία μονάδα. Αν το hopttl < 0 ή το πεδίο OK δηλώνει ύπαρξη λάθους τότε η προσομοίωση hop αποτυγχάνει. Προσοχή πρέπει να δοθεί ότι ο αρχικός αποστολέας είναι υπεύθυνος για την καταστροφή του κάθε μηνύματος. 53

54 Εικόνα 12Αφαιρετική αναπαράσταση του μοντέλου. 54

55 Το Push Master Task του Surrogate έχει την ακόλουθη δομή: void su_pushmastertask ( void ){ for(;;) { ps_recieve(request) ps_send(ack to Father Task) look if object is available in local cache if(not available) { Then look for available Fetch Master Task if(not found) { ps_send(nack to Client) if(found) { ps_send(object request to Fetch Master Task ) ps_recieve(ack from Fetch Master Task ) ps_recieve(ack or nack from Fetch Master Task ) if(nack) { ps_send(nack to Client) if(success) { Handshake with Client Calculate the number of segment for object ps_resume(as many Simple Pusher Tasks as needed)) ps_send(info to Simple Pusher Tasks)) wait all to finish( ps_recieve()) end connection handshake with Client ps_suspend(myself) return; Πίνακας 18 su_pushmastertask Το Pull Master Task του Surrogate έχει την ακόλουθη δομή: void su_pullmastertask ( void ){ for(;;) { ps_recieve(request) ps_send(ack to FatherTask) try to establish connection handshake if(success) 55

56 { Get file and respond with ack/nack End connection handshake ps_send(ack to Push Master Task) if(not success) { ps_send(nack to Push Master Task) ps_suspend(myself) return; Πίνακας 19 su_pullmastertask Tο Simple Pusher Task του Surrogate έχει την ακόλουθη δομή: void su_simplepushertask ( void ){ for(;;) { ps_recieve(info) ps_send(ack to Push Master Task) if(client is Client Group) { if(client is Surrogate) { prepare ipdatagram (find best path mynode -> Surrogate) for(all segments assigned to me) { ps_link_send(ipdatagram to ROUTER) ps_recieve(response from ROUTER) if(response = nack) { Destroy path Retry until ack using random Routers ps_link_send(ipdatagram to ROUTER) ps_recieve(response from ROUTER) ps_send(ack to Push Master Task) ps_suspend(myself) return; Πίνακας 20 su_simplepushertask 56

57 Το Push Master Task του Origin έχει την ακόλουθη δομή: void or_pushmastertask ( void ){ for(;;) { ps_recieve(request) ps_send(ack to Father Task) Handshake with Client Calculate the number of segment for object ps_resume(as many Simple Pusher Tasks as needed)) ps_send(info to Simple Pusher Tasks)) wait all to finish( ps_recieve()) end connection handshake with Client ps_suspend(myself) return; Πίνακας 21 or_pushmastertask Tο Simple Pusher Task του Origin έχει την ακόλουθη δομή: void or_simplepushertask ( void ){ for(;;) { ps_recieve(info) ps_send(ack to Push Master Task) prepare ipdatagram (find best path mynode -> Surrogate) for(all segments assigned to me) { ps_link_send(ipdatagram to ROUTER) ps_recieve(response from ROUTER) if(response = nack) { Retry until ack ps_link_send(ipdatagram to ROUTER) ps_recieve(response from ROUTER) ps_send(ack to Push Master Task) ps_suspend(myself) return; Πίνακας 22 or_simplepushertask Tο Father Task του Router έχει την ακόλουθη δομή: void ro_fathertask ( void ){ for(;;) { ps_recieve(ipdatagram) look for available Route Master Task 57

58 if(επιτυχία) { ps_resume(fetch Master Task) ps_send(ipdatagram to Route Master Task) ps_recieve(ack from Route Master Task ) ps_send(ack to immediate sender) if(αποτυχία) { ps_send(ack to immediate sender) return; Πίνακας 23 ro_fathertask Tο Route Master Task του Router έχει την ακόλουθη δομή: void ro_routehmastertask ( void ){ for(;;) { ps_recieve(ipdatagram) ps_send(ack στο FatherTask) if(not success emulate hop) { ps_send(nack initial sender) if(ipdatagram.path = NULL) { ipdatagram.path = builpath(frommynode, tofinaltargetnode) nextnode = getnextnode(ipdatagram.path) if(nextnode is SURROGATE) { ps_link_send(ipdatagram to SURROGATE) ps_recieve(ack from SURROGATE) if(nextnode is ROUTER) { ps_link_send(ipdatagram to ROUTER) ps_recieve(response from ROUTER) if(response = nack) { try again N times ps_link_send(ipdatagram to ROUTER) ps_recieve(response from ROUTER) if(response = nack ) { select randomly another Router 58

59 ps_link_send(ipdatagram to ROUTER) ps_recieve(response from ROUTER) if(response = nack ) { ps_send(nack to initial sender) ps_suspend(myself) return; Πίνακας 24 ro_routehmastertask 7.5 Ρύθμιση αριθμού των tasks Για το requests generator έχουμε τα ακόλουθα tasks στον κώδικα: req_memreqgenwithshowprogresssupport req_filereqgenwithshowprogresssupport req_memreqgen req_filereqgen τα οποία αντιστοιχούν στις 4 περιπτώσεις εμφάνιση ή όχι προόδου, ανάγνωση του trace κατευθείαν από αρχείο ή όχι. Για τα Client Groups έχουμε τα ακόλουθα tasks στον κώδικα: clt_father clt_fetchmaster clt_fetchmasterwithsavesessionssupport τα οποία έχουν περιγραφεί πιο πάνω. Το clt_fetchmasterwithsavesessionssupport είναι ακριβώς ίδιο με το clt_fetchmaster με μόνη διάφορα ότι χρησιμοποιείται αυτό αντί του clt_fetchmaster σε περίπτωση που επιθυμούμε να αποθηκεύονται σε αρχείο όλα τα sessions με τον γειτονικό Surrogate. Για τους Surrogate Servers έχουμε τα ακόλουθα tasks: sut_simplepusher sut_pullmaster sut_pushmaster sut_father τα οποία έχουν ήδη περιγραφεί. Για τους Origin Servers έχουμε τα ακόλουθα tasks: ort_simplepusher ort_pushmaster ort_father τα οποία έχουν ήδη περιγραφεί. Για τους Routers έχουμε τα ακόλουθα tasks: 59

60 rot_routemaster rot_father τα οποία έχουν ήδη περιγραφεί. Η αυξομείωση των αριθμών των tasks προκαλεί διαφορετικά φαινόμενα: Αριθμός (πάντα 1) Συμπεριφορά Συνέπειες req_memreqgenwithshowprogresssupport req_filereqgenwithshowprogresssupport req_memreqgen req_filereqgen Πίνακας 25 Αλλαγή αριθμού RQ Αριθμός clt_father (πάντα 1) Συμπεριφορά Συνέπειες Πίνακας 26 Αλλαγή αριθμούclt_father Αριθμός clt_fetchmaster clt_fetchmasterw Αύξηση Μείωση Συμπεριφορά Αύξηση αριθμού ταυτόχρονων αιτήσεων στο γειτονικό Surrogate. Μείωση αριθμού ταυτόχρονων αιτήσεων στο γειτονικό Surrogate. Συνέπειες Πίνακας 27 Αλλαγή αριθμού clt_fetchmaster Υπάρχει κίνδυνος σπατάλης μνήμης σε περίπτωση που ο ρυθμός δρομολόγησης των αιτήσεων είναι πολύ μικρότερος από αυτό της ικανοποίησης των αιτήσεων από το γειτονικό Surrogate, πρακτικά θα υπάρχουν συνέχεια clt_fetchmaster σε κατάσταση SUSPENDED χωρίς να εκτελούν τίποτα. Υπάρχει κίνδυνος κάποιες αιτήσεις να μην δρομολογηθούν ποτέ από το clt_father γιατί όλα τα clt_fetchmaster θα είναι δεσμευμένα. Αριθμός sut_father (πάντα 1) Συμπεριφορά Συνέπειες Πίνακας 28 Αλλαγή αριθμού sut_father Αριθμός sut_pushmaster Συμπεριφορά Συνέπειες 60

61 Αύξηση Μείωση Αυξάνεται η δύναμη του Server, δηλαδή αυξάνεται ο αριθμός των ταυτόχρονων συνδέσεων αποστολής αρχείων. Μειώνεται η δύναμη του Server, δηλαδή μειώνεται ο αριθμός των ταυτόχρονων συνδέσεων αποστολής αρχείων. Πίνακας 29 Αλλαγή αριθμού sut_pushmaster Μειώνεται το DOS. Μπορεί να έχουμε σπατάλη μνήμης αν ο ρυθμός εξυπηρέτησης είναι πολύ μικρότερος από τον μέγιστο δυνατό. Αυξάνεται το DOS Αριθμός sut_simplepusher ανά sut_pushmaster Αύξηση Μείωση Συμπεριφορά Αυξάνεται ο αριθμός των κομματιών ανά αρχείο που στέλνονται ταυτόχρονα Μειώνεται ο αριθμός των κομματιών ανά αρχείο που στέλνονται ταυτόχρονα Πίνακας 30 αλλαγή αριθμού sut_simplepusher Συνέπειες Bottleneck αν ο ρυθμός αποστολής μεγάλος. Μπορεί να μειωθεί αισθητά ο χρόνος αποστολής του αρχείου. Αν τα αρχεία είναι πολύ μικρά, δεν χρησιμοποιούνται όλα τα sut_simplepusher οπότε έχουμε σπατάλη μνήμης. Αποφεύγεται το bottleneck αφού ο ρυθμός αποστολής μειώνεται. Μπορεί να αυξηθεί αισθητά ο χρόνος αποστολής του αρχείου. Αριθμός sut_pullmaster Συμπεριφορά Συνέπειες Αύξηση Αύξηση αριθμού ταυτόχρονων συνδέσεων Περισσότερες αιτήσεις μπορούν 61

62 Μείωση παραλαβής αρχείων από άλλους Servers Μείωση αριθμού ταυτόχρονων συνδέσεων παραλαβής αρχείων από άλλους Servers Πίνακας 31 Αλλαγή αριθμού sut_pullmaster ικανοποιηθούν αφού υπάρχουν διαθέσιμα sut_pullmaster για να αντιμετωπίσουν τα πιθανά cache misses. Αν ο αριθμός των cache misses είναι μικρός μπορεί να οδηγηθούμε σε σπατάλη μνήμης. Λιγότερες αιτήσεις μπορούν ικανοποιηθούν αφού μπορεί να μην υπάρχουν πάντα διαθέσιμα sut_pullmaster για να αντιμετωπίσουν τα πιθανά cache misses Αριθμός ort_father (πάντα 1) Συμπεριφορά Συνέπειες Πίνακας 32 Αλλαγή αριθμού ort_father Αριθμός ort_pushmaster Συμπεριφορά Συνέπειες Αύξηση Αυξάνεται η δύναμη του Server, δηλαδή αυξάνεται ο αριθμός των ταυτόχρονων συνδέσεων αποστολής αρχείων. Μειώνεται το DOS. Μπορεί να έχουμε σπατάλη μνήμης αν ο ρυθμός εξυπηρέτησης είναι πολύ μικρότερος από τον μέγιστο Μείωση Μειώνεται η δύναμη του Server, δηλαδή μειώνεται ο αριθμός των ταυτόχρονων συνδέσεων αποστολής δυνατό. Αυξάνεται το DOS 62

63 Αριθμός ort_simplepusher ανά sut_pushmaster Αύξηση Μείωση αρχείων. Συμπεριφορά Αυξάνεται ο αριθμός των κομματιών ανά αρχείο που στέλνονται ταυτόχρονα Μειώνεται ο αριθμός των κομματιών ανά αρχείο που στέλνονται ταυτόχρονα Πίνακας 33 αλλαγή αριθμού ort_pushmaster Συνέπειες Bottleneck αν ο ρυθμός αποστολής μεγάλος. Μπορεί να μειωθεί αισθητά ο χρόνος αποστολής του αρχείου. Αν τα αρχεία είναι πολύ μικρά, δεν χρησιμοποιούνται όλα τα sut_simplepusher οπότε έχουμε σπατάλη μνήμης. Αποφεύγεται το bottleneck αφού ο ρυθμός αποστολής μειώνεται. Μπορεί να αυξηθεί αισθητά ο χρόνος αποστολής του αρχείου. Αριθμός rot_father (πάντα 1) Συμπεριφορά Συνέπειες Πίνακας 34 Αλλαγή αριθμού rot_father Αριθμός rot_routemaster Συμπεριφορά Συνέπειες Αύξηση Αύξηση της δύναμης του Router, δηλαδή του μέγιστου αριθμού ταυτόχρονων δρομολογήσεων. Μείωση των reroutings. Μείωση του DOS. Αύξηση του bottleneck. Σπατάλη μνήμης αν οι Routers δεν χρειάζεται να είναι τόσο Μείωση Μείωση της δύναμης του Router, δηλαδή του μέγιστου αριθμού ταυτόχρονων «δυνατοί» Αύξηση των reroutings. Αύξηση του DOS. Μείωση του 63

64 δρομολογήσεων. Πίνακας 35 Αλλαγή αριθμού rot_routemaster bottleneck. Οι απαίτησης σε μνήμη του κάθε task είναι της τάξης λίγων kilobytes. Άρα μπορούν να κατασκευαστούν πάρα πολλά tasks. Ο αριθμός τους, οπότε και οι απαιτήσεις σε μνήμη, υπολογίζονται εύκολα. 7.6 Πολιτική Στο μοντέλο υποστηρίζεται η εξής διαχείριση-πολιτική των Surrogate Server : Αρχικά τοποθετούνται αντικείμενα στους σκληρούς δίσκους των Surrogate Servers. Το περιεχόμενο τους δεν αλλάζει καθόλου κατά την διάρκεια της προσομοίωσης. Αν κάποιο αντικείμενο ζητηθεί και υπάρχει στη cache τότε αποστέλλεται σε αυτόν που το ζήτησε. Αν κάποιο αντικείμενο ζητηθεί και δεν υπάρχει στη cache τότε ζητείται από κάποιο Surrogate Server συνεργάτη ή από κάποιο Origin Server και τότε αποστέλλεται στον πελάτη. Το αντικείμενο δεν αποθηκεύεται στον στη cache. Επεκτασιμότητα Στο μοντέλο υποστηρίζεται μια μόνο πολιτική για τους Surrogate Servers. Το θέμα για την επιλογή μεταξύ πολλών εναλλακτικών πολιτικών παραμένει ανοιχτό. Για παράδειγμα, έστω ότι θέλουμε ένα μηχανισμό αφαίρεσης μη διάσημων αντικειμένων από την τοπική cache του κάθε Surrogate. Οι ενέργειες που πρέπει να γίνουν είναι οι εξής: Ανάπτυξη μιας αποδοτικής δομής, η οποία θα αποθηκεύει τα χαρακτηριστικά που μας ενδιαφέρουν για τα αποθηκευμένα αντικείμενα, για κάθε Surrogate. Στο κομμάτι του κώδικα του sut_father που δέχεται αιτήσεις να εντοπίζεται κάθε φορά το ζητούμενο αντικείμενο και να ενημερώνονται οι ιδιότητες του στη δομή. Ανάπτυξη ενός task που θα τρέχει παράλληλα σε κάθε κόμβο Surrogate και ανά τακτά χρονικά διαστήματα (ps_sleep) θα ενημερώνει τη δομή με βάση τα κριτήρια που επιθυμούμε, με μηδενική κατανάλωση ιδεατού επεξεργαστή. Το task δεν θα επηρεάζει σε τίποτα τα υπόλοιπα tasks του κόμβου. Προσοχή πρέπει να δοθεί στην περίπτωση διαγραφών από τη δομή, η Parasol υποστηρίζει semaphores (σημαφόρους) για mutual exclusion (αμοιβαίο αποκλεισμό). Οπότε κάθε φορά που θα γίνεται προσπέλαση της δομής είτε από το sut_father είτε από το καινούριο task θα πρέπει να κλειδώνεται στιγμιαία για να γίνεται η ανάγνωση / διαγραφή. Στο τρέχον μοντέλο δεν υποστηρίζονται buffers. Πιο συγκεκριμένα στο port του κάθε Task σχηματίζεται μια ουρά από μηνύματα. Επειδή όμως το Father Task αναμένει συνεχώς μηνύματα δεν σχηματίζεται τελικά ουρά. Αν δεν υπάρχει κάποιο διαθέσιμο task να αναλάβει την αίτηση αυτή απορρίπτεται. Μια παραλλαγή θα μπορούσε να ήταν η υλοποίηση ενός buffer πεπερασμένης χωρητικότητας στο οποίο θα αποθηκεύονται οι αιτήσεις που δεν μπορούν να εξυπηρετηθούν άμεσα, δηλαδή μιας λίστας αναμονής. 64

65 Τέλος μια πιθανή παραλλαγή θα μπορούσε να ήταν η δημιουργία tasks «καθαρών» από πράξεις που αφορούν στατιστικά, ώστε να βελτιωθεί η απόδοση. Δηλαδή αν δεν μας ενδιαφέρει μια ομάδα στατιστικών να επιλέγονται τα tasks τα οποία περιέχουν «καθαρό» κώδικα προσομοίωσης. 65

66 8. Σύνοψη Στις προηγούμενες ενότητες παρουσιάστηκε αναλυτικά το μοντέλο του προσομοιωτή CDNsim, ένα εργαλείο που προσομοιώνει τα CDNs. Παρουσιάστηκε η αρχιτεκτονική του, οι εσωτερικές λειτουργίες, τα πλεονεκτήματα και μειονεκτήματα, οι δυνατότητες και οι επεκτάσεις του. Δεν αποτελεί την μοναδική ή καλύτερη δυνατή υλοποίηση, αλλά μπορεί να αποτελέσει βάση προς ανάπτυξη και πειραματισμό. Αξίζει να σημειωθεί ότι η τελική έκδοση έχει γραμμές κώδικα. Το μοντέλο επιδέχεται επεκτάσεις ως προς δυο τομείς. Ο πρώτος αφορά την εισαγωγή νέων λειτουργιών, όπως η υποστήριξη περισσότερων πολιτικών των CDNs, προσθήκη πρωτοκόλλων ασφαλείας στην μεταφορά των δεδομένων και εισαγωγή νέων συστατικών του δικτύου (π.χ. DNS Servers). Ο δεύτερος αφορά την προγραμματιστική υλοποίηση και τους περιορισμούς των δυνατοτήτων. Επίσης, ταχύτερος κώδικας και αποδοτικότερες δομές μπορούν να συμβάλουν θετικά στην ταχύτητα των εκτελέσεων και στην αύξηση του μεγέθους (size up) των προσομοιώσεων (π.χ. υποστήριξη για πολιτικές συντήρησης της cache). 66

67 9 Βιβλιογραφία [1] B. H. Bloom, Space/Time Trade-offs in Hash Coding with Allowable Errors, Communications of ACM, volume 13, number 7, pp , [2] A. Broder, M. Mitzenmacher, Network Applications of Bloom Filters: A Survey, Internet Mathematics Journal, volume 1, number 4, pp , [3]S. Buchholz, T. Buchholz, Replica Placement in Adaptive Content Distribution Networks, In Proceedings of the 2004 ACM Symposium on Applied Computing (SAC 2004), pp , Nicosia, Cyprus, March [4] K. L. Calvet, G. Tech, M. B. Doar, A. Nexion, E. W. Zegura, Modelling Internet Topology, IEEE Communications Magazine, volume 35, number 6, pp , [5] D. Chakrabarti, Y. Zhan, C. Faloutsos, R-MAT: A Recursive Model for Graph Mining, In Proceedings of the 4th SIAM International Conference on Data Mining (SIAM 2004), Lake Buena Vista, Florida, USA, April [6] Y. Chen, L. Qui, W. Chen, L. Nguyen, R. H. Katz, Efficient and Adaptive Web Replication using Content Clustering, IEEE Journal on Selected Areas in Communications, volume 21, number 6, [7] P. Guillaume, M. van Steen, Design and Implementation of a User- Centered Content Distribution Network, In Proceedings of the 3rd IEEE Workshop on Internet Applications (IEEE WIAPP 2003), pp , San-Jose, USA, June [8] J. Jeong, M. Dubois, Cost-Sensitive Cache Replacement Algorithms, In Proceedings of the 9th International Symposium on High-Performance Computer Architecture (HPCA 2003), pp , Anaheim, California, USA, February [9] J. Kangasharju, J. W. Roberts, K. W. Ross, Object Replication Strategies in Content Distribution Networks, Computer Communications, volume 25, number 4, pp , [10] M. Karlsson, C. Karamanolis, M. Mahalingam, A Framework for Evaluating Replica Placement Algorithms, In Proceedings of the 2004 ACM Symposium on Applied Computing (SAC 2004), pp , Nicosia, Cyprus, March [11] B. Krishnamurthy, J. Wang, On Network-aware Clustering of Web Clients, In Proceedings of the ACM SIGCOMM 2000 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, pp , Stockholm, Sweden, August

68 [12] P. Kulkarni, P. J. Shenoy, W, Gong, Scalable Techniques for Memoryefficient CDN Simulations, In Proceedings of the 12th International World Wide Web Conference (WWW 2003), pp , Budapest, Hungary, May [13] S. Podlipnig, L. Boszormeny, A Survey of Web Cache Replacement Strategies, ACM Computing Surveys, volume 35, number 4, pp , [14] Z. G. Prodanoff, K. J. Christensen, Managing Routing Tables for URL Routers in Content Distribution Networks, International Journal of Network Management, volume 14, number 3, pp , [15] L. Qiu, V. N. Padmanabhan, G. M. Voelker, On the Placement of Web Server Replicas, In proceedings of the 20th Annual Joint Conference of the IEEE Computer and Communications Societies (IEEE INFOCOM 2003), pp , Anchorage, Alaska, USA, April [16], S. Saroiu, P. K. Gummadi, R. J. Dunn, S. D. Gribble, H. M. Levy, An Analysis of Internet Content Delivery Systems, In proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 02), pp , Boston, Massachusetts, USA, December [17], A. Vakali, G. Pallis, Content Delivery Networks: Status and Trends, IEEE Internet Computing, volume 7, number 6, pp , [18] E. W. Zegura, K. L. Calvert, S. Bhattacharjee, How to Model an Internetwork, In proceedings of the 15th Annual Joint Conference of the IEEE Computer and Communications Societies, Networking the Next Generation (IEEE INFOCOM 1996), San Francisco, volume 2, pp , March

69 ΠΑΡΑΡΤΗΜΑ Α Ρυθμίσεις Ε/Ε Ο καλύτερος τρόπος για να περιγραφεί η λειτουργία ενός προγράμματος είναι η παρουσίαση των ρυθμίσεων και της εισόδου εξόδου. Στην προκειμένη περίπτωση η περιγραφή όλων των ρυθμίσεων καλύπτει πλήρως τις απαιτήσεις. Για να ξεκινήσει η προσομοίωση εκτελούμε την παρακάτω εντολή σε ένα terminal σε UNIX περιβάλλον:./simulate ConfgurationFile Όπου simulate είναι το όνομα του εκτελέσιμου και ConfgurationFile το αρχείο ρυθμίσεων. Ένα παράδειγμα αρχείου ρυθμίσεων είναι το παρακάτω: //SIMULATION //GENERAL OPTIONS (use 0 or 1) buildrouter tables=1 cooktracefile=1 showprogress=0 savesessionstimes=0 loadtracefiletoram=0 usebloomfilters=0 //PLACEMENT (use filenames without spaces ) objectsplacementfilename=objectsplacementfilename //TOPOLOGY / NETWORK (use filenames without spaces ) maxlinkspeedinbytes= e9 maxsimulatedipdatagramsizeinbytes= Router tablesfilename=router tablesfilename noofsurrogates=20 nooforigins=1 RoutersGraphFilename=RoutersGraphsFilename RoutersToRoutersLinkSpeedBytes= RoutersToRoutersExtraLinkSpeedBytes=0.0 OriginsToRoutersLinkSpeedBytes= OriginsToRoutersExtraLinkSpeedBytes=0.0 SurrogatesToRoutersLinkSpeedBytes= SurrogatesToRoutersExtraLinkSpeedBytes=0.0 SurrogatesMaxExtraConnectionsToRouters=1 ClientGroupsToSurrogatesLinkSpeedBytes= ClientGroupsToSurrogatesExtraLinkSpeedBytes=0.0 //DATASETS (use filenames without spaces ) tracefilename=tracefilename objectsfilename=objectsfilename cookedtracefilename=cookedtracefilename //ROUTERS noofsimultaneoustransfersperrouter=10 RoutersNoOfTriesPerIpDatagramUntilChangeRouter=2 //ORIGINS OriginsNoOfBloomFiltersBits= OriginsNoOfSimultaneousUploads=20 OriginsNoOfSimultaneousIpdatagramUploads=60 //SURROGATES SurrogatesNoOfBloomFiltersBits= SurrogatesNoOfSimultaneousUploads=20 SurrogatesNoOfSimultaneousIpdatagramUploads=60 SurrogatesNoOfTriesPerIpDatagramUntilChangeRouter=2 SurrogatesNoOfSimultaneousDownloads=20 69

70 //CLIENT GROUPS maxsessionsperclientgroup=30 //OUTPUT (use filenames without spaces ) statisticsfilename=statsiticsfilename sessionstimefilename=sessionstimefilename //PARASOL (for parasoldebugflag use 0 -> NOTHING, 1 -> TRACE, 2 -> STEP (interactive), 3 -> STEP EVENT, 4 - > WARNING) maxsimulationduration= parasolseed=302 parasoldebugflag=0 Πίνακας 36 Παράδειγμα αρχείου ρυθμίσεων Κάθε ρύθμιση ορίζεται από τα εξής: όνομαρύθμισης=τιμη όπου: όνομαρύθμισης είναι το όνομα της ρύθμισης που επηρεάζουμε. Το όνομα είναι το ίδιο με αυτό που χρησιμοποιήθηκε και στον κώδικα, για ευνόητους λόγους. = είναι ο διαχωριστής μεταξύ του ονόματος και τις επιθυμητής τιμής. Τιμή είναι η τιμή που θέλουμε να λάβει η τρέχουσα επιλογή. Να σημειωθεί ότι δεν γίνεται έλεγχος για την ορθότητα των τιμών, αυτό γιατί στόχος είναι να επιτραπεί ο πειραματισμός χωρίς περιορισμούς. Παρακάτω θα αναφέρονται οι σωστές τιμές για το τρέχον μοντέλο και για κάθε επιλογή. Για έλεγχο των επιλογών συστήνεται η χρήση του γραφικού περιβάλλοντος που έχει αναπτυχθεί για το σκοπό αυτό. Από το αρχείο πρέπει να αλλαχθεί απολύτως τίποτα εκτός βέβαια από τις τιμές. Ο λόγος είναι ότι το αρχείο διαβάζεται γραμμή-γραμμή και γίνεται ταυτοποίηση, οπότε αν κάτι δεν ταιριάζει απόλυτα υπάρχει πρόβλημα. Κάθε γραμμή πρέπει να τελειώνει με τον χαρακτήρα νέας γραμμής \n του UNIX και μόνο με αυτό. SIMULATION Αναλυτική περιγραφή των ρυθμίσεων GENERAL OPTIONS buildrouter tables Αν έχει την τιμή 1 τότε τα Router tables κατασκευάζονται από την αρχή και αποθηκεύονται στο Router tablesfilename για μελλοντική χρήση. Αν έχει την τιμή 0 τότε τα Router tables φορτώνονται κατευθείαν από το Router tablesfilename. 70

71 Έγκυρες τιμές : {0, 1 cooktracefile Αν έχει την τιμή 1 τότε το tracefilename επεξεργάζεται από την αρχή και αποθηκεύεται στο cookedtracefilename. Η επεξεργασία αφορά την διαμοιρασμό των Clients σε Client Groups και είναι γρήγορη διαδικασία (για requests χρειάζονται περίπου 2 λεπτά). Αν έχει την τιμή 0 τότε δεν γίνεται καμία επεξεργασία και γίνεται ανάγνωση κατευθείαν από το cookedtracefilename. Έγκυρες τιμές : {0, 1 showprogress Αν έχει την τιμή 1 τότε στο standard output εμφανίζεται συνεχώς ο αριθμός των requests που έχουν σταλεί από τον requests generator. Η διαδικασία μπορεί να προκαλέσει μικρές καθυστερήσεις στον τελικό χρόνο εκτέλεσης Αν έχει την τιμή 0 τότε δεν εμφανίζεται η πρόοδος. Έγκυρες τιμές : {0, 1 savesessionstimes Αν έχει την τιμή 1 τότε στο sessionstimefilename αποθηκεύονται (με append στο αρχείο) η κατάσταση όλων των αιτήσεων (χρόνος έναρξης-λήξης, επιτυχία-αποτυχία). Η διαδικασία μπορεί να προκαλέσει μικρές καθυστερήσεις λόγο I/O. Αν η τιμή είναι 0 τότε δεν γίνεται καμία ενέργεια. Έγκυρες τιμές : {0, 1 loadtracefiletoram Αν έχει την τιμή 1 τότε το cookedtracefilename φορτώνεται στη RAM και διαβάζεται από εκεί. Συνίσταται αν υπάρχει αφθονία μνήμης. Με αυτό τον τρόπο αποφεύγεται το I/O στη cache δίσκο και η εκτέλεση επιταχύνεται. Έγκυρες τιμές : {0, 1 usebloomfilters Αν έχει την τιμή 1 τότε χρησιμοποιούνται hash functions για I/O στους σκληρούς δίσκους των Servers. Δεν δίνεται η επιλογή για αλλαγή του αριθμού τους ή τη λειτουργίας τους. Τέτοιες αλλαγές μπορούν να γίνουν αλλάζοντας τον πηγαίο κώδικα των bloom filters και του πεδίου generaloptions. Used_hash_functions[ Ν ], όπου Ν είναι ο αριθμός των hash functions που χρησιμοποιείται, και περιέχει τα DEFINES των hash functions. Αν η τιμή είναι 0 τότε η διαδικασία I/O στους σκληρούς επιταχύνεται σημαντικά καθώς δεν χρησιμοποιούνται hash functions, αλλά απλό bitmapping. Προσοχή πρέπει να δοθεί στα πεδία OriginsNoOfBloomFiltersBits και SurrogatesNoOfBloomFiltersBits να έχουν τιμές μεγαλύτερες ή ίσες με τον αριθμό των συνολικών αντικειμένων στην περίπτωση του bitmapping. 71

72 Έγκυρες τιμές : {0, 1 PLACEMENT objectsplacementfilename Ορίζεται το όνομα του αρχείου που περιέχει πληροφορίες για την τοποθέτηση των αντικειμένων στους σκληρούς δίσκους. Έγκυρες τιμές : Το όνομα δεν πρέπει να περιέχει τον χαρακτήρα του κενού. Έστω ότι έχουμε 2 Surrogate Servers και 2 Origin Servers. Ένα παράδειγμα του format του αρχείου θα μπορούσε να είναι τα παρακάτω: 0 1 /home/project/objectsseta 1 3 /home/project/objectssetb /home/project/objectsseta /home/project/objectssetz 0 1 /home/project/allobjects 1 1 /home/project/allobjects Πίνακας 37 παράδειγμα αρχείου placement Αρχικά γράφουμε τους Surrogate Servers, η αρίθμησή τους ξεκινά από το 0 και αντιστοιχεί στη θέση τους στη δομή των Surrogate Servers. Στη συνέχεια ακολουθούν οι Origin Servers. Ας δούμε γραμμή-γραμμή τι συμβαίνει: 0 //στο Surrogate στη θέση SurrogatesList[0] 1 //τοποθέτησε αντικείμενα από 1 αρχείο που περιέχει αντικείμενα /home/project/objectsseta //το οποίο αρχείο είναι αυτό 1 //στο Surrogate στη θέση SurrogatesList[1] 3 //τοποθέτησε αντικείμενα από 3 αρχεία που περιχέουν αντικείμενα /home/project/objectssetb //στα οποία ανήκει αυτό /home/project/objectsseta // και αυτό /home/project/objectssetz // και αυτό 0 //στον Origin στη θέση OriginsList[0] (έχουμε τελειώσει με τους Surrogates) 1 //τοποθέτησε αντικείμενα από 1 αρχείο που περιέχει αντικείμενα /home/project/allobjects //το οποίο αρχείο είναι αυτό 1 //στον Origin στη θέση OriginsList[1] 1 //τοποθέτησε αντικείμενα από 1 αρχείο που περιέχει αντικείμενα /home/project/allobjects //το οποίο αρχείο είναι αυτό Πίνακας 38 Παράδειγμα αρχείου placement (επεξηγημένο) Τα ονόματα των αρχείων επίσης δεν πρέπει να περιέχουν τον χαρακτήρα του κενού και οπωσδήποτε κάθε γραμμή να τελειώνει με το χαρακτήρα \n και μόνο. Τα αρχεία που δηλώνουμε περιέχουν συλλογές αντικειμένων. Για 72

73 παράδειγμα το αρχείο /home/project/objectsseta θα μπορούσε να έχει το παρακάτω format: 12 sdfgdfg 33 sdfsdf hndxcvb gdfgdfgsasas gdd 233 Πίνακας 39 Παράδειγμα αρχείου αντικειμένων για αρχείο placement Δηλαδή στο Surrogate στη θέση 0 τοποθετούνται τα αντικείμενα με ID {12, 33, 415, 23423, , 233. Κάθε γραμμή τελειώνει με το χαρακτήρα \n και περιέχει πρώτα έναν ακέραιο που αντιστοιχεί στο objectid και οτιδήποτε άλλο το οποίο παραβλέπεται. Επειδή το αρχείο objectsplacementfilename διαβάζεται γραμμή πρέπει να γνωρίζει τι θα διαβάσει στην επόμενη γραμμή γι αυτό ορίζεται κάθε φορά ο αριθμός των αρχείων. Επίσης αν έχουμε ορίσει 30 Surrogate Servers στις ρυθμίσεις και στο αρχείο έχουμε π.χ. μόνο 2, θα γίνει προσπάθεια να διαβαστούν 30 Surrogates, οπότε υπάρχει πρόβλημα. Επίσης δεν γίνεται κανένας έλεγχος για το αν τα Ids υπάρχουν πραγματικά και δεν γίνεται έλεγχος για τον αν «χωράνε» στη cache, αφού δεν υπάρχει πραγματικά η έννοια του περιορισμού χωρητικότητας λόγο χρήσης bloom filters. Ο χρήστης είναι υπεύθυνος για τους περιορισμούς. TOPOLOGY maxlinkspeedinbytes Ορίζεται ένα άνω όριο για την ταχύτητα μετάδοσης στα Links. Χρησιμοποιείται μόνο κατά την διάρκεια του Dijkstra για να κλιμακώνονται τα κόστη επικοινωνίας στο 0..1 με βάση ένα άνω όριο. Έγκυρες τιμές : Double > 0 και να ισχύουν τα παρακάτω: maxlinkspeedinbytes >= RoutersToRoutersLinkSpeedBytes + RoutersToRoutersExtraLinkSpeedBytes maxlinkspeedinbytes >= OriginsToRoutersLinkSpeedBytes + OriginsToRoutersExtraLinkSpeedBytes maxlinkspeedinbytes >= SurrogatesToRoutersLinkSpeedBytes + SurrogatesToRoutersExtraLinkSpeedBytes maxlinkspeedinbytes >= ClientGroupsToSurrogatesLinkSpeedBytes + ClientGroupsToSurrogatesExtraLinkSpeedBytes maxsimulatedipdatagramsizeinbytes Ορίζεται το μέγεθος των ipdatagrams. Η τιμή αυτή χρησιμοποιείται για τον τεμαχισμό των αντικειμένων κατά την διαδικασία υπολογισμού των τεμαχίων ανά αντικείμενο. Είναι πολύ σημαντική επιλογή γιατί καθορίζει τον αριθμό μηνυμάτων κατά την μεταφορά του αντικειμένου και παίζει τον πλέον καθοριστικό ρόλο στην χρονική διάρκεια της προσομοίωσης. Για παράδειγμα αν η τιμή γίνει 100 φορές μικρότερη από την τρέχουσα τότε θα παραχθούν 100 φορές περισσότερα μηνύματα ανά αποστολή αντικειμένου και άρα ο πραγματικός χρόνος εκτέλεσης σχεδόν θα 100πλασιαστεί. 73

74 Έγκυρες τιμές : Double > 0 Router tablesfilename Ορίζεται το όνομα του αρχείου που αφορά τα Router tables. Αν έχει επιλεχθεί η κατασκευή τους τότε μετά την κατασκευή τους αποθηκεύονται σε αυτό το αρχείο, αλλιώς φορτώνονται κατευθείαν από αυτό το αρχείο. Προσοχή πρέπει να δοθεί αν γίνει χρήση Router tables τα οποία προέκυψαν από διαφορετική τοπολογία.. Θα προκληθεί λάθος γιατί μπορεί να ζητηθεί μετάδοση σε κάποιο μονοπάτι το οποίο δεν ισχύει. Έγκυρες τιμές : Το όνομα δεν πρέπει να περιέχει τον χαρακτήρα του κενού. Ένα παράδειγμα Router tables με 2 Routers, 1 Surrogate, 1 Client Group και 1 Origin είναι: 1 6 -={START PATHS= ={END PATHS=- -={START COSTS= ={END COSTS= ={START PATHS= ={END PATHS=- -={START COSTS= ={END COSTS= ={START PATHS=- 3 74

75 ={END PATHS=- -={START COSTS= ={END COSTS= ={START PATHS= ={END PATHS=- -={START COSTS= ={END COSTS= ={START PATHS= ={END PATHS=- -={START COSTS= ={END COSTS=- Πίνακας 40 Παράδειγμα αρχείου Router Tables Τα Router tables χωρίζονται σε blocks της μορφής sourcenodeid numberofnodes -={START PATHS=- Dijkstra compressed path information -={END PATHS=- -={START COSTS=- 75

76 Communication costs from sourcenodeid to other nodded -={END COSTS=- Δηλαδή αποθηκεύονται τα μονοπάτια που προέκυψαν από τον Dijkstra και τα κόστη επικοινωνίας. Σημαντικό είναι το γεγονός ότι ο iοστος κόμβος έχει nodeid = i. Για παράδειγμα από τον κόμβο με ID = 1 (Router) για να πάμε στον ίδιο κόμβο είναι αδύνατο γιατί το κόστος επικοινωνίας είναι άπειρο (INT_MAX) αφού δεν έχουμε Link που να ενώνει κόμβο με τον εαυτό του ={START PATHS= ={END PATHS=- -={START COSTS= ={END COSTS=- Πίνακας 41 Παράδειγμα αρχείου Router Tables (επεξηγημένο) noofsurrogates Ορίζει τον αριθμό των Surrogate Servers που θα υπάρχουν στο δίκτυο. Υπενθυμίζουμε ότι ο αριθμός τους ορίζει αυτόματα και τον αριθμό των Client Groups, ότι τοποθετούνται με τυχαίο τρόπο στο δίκτυο και ότι μπορεί να συνδέονται και με περσότερους του ενός Routers. Έγκυρες τιμές : Integer > 0 nooforigins Ορίζει τον αριθμό των Origin Servers που θα υπάρχουν στο δίκτυο. Υπενθυμίζουμε ότι τοποθετούνται με τυχαίο τρόπο στο δίκτυο και ότι δεν μπορεί να συνδέονται και με περσότερους του ενός Routers. Έγκυρες τιμές : Integer > 0 RoutersGraphFilename Ορίζεται το όνομα του αρχείου που περιέχει το γράφο των Routers. Έγκυρες τιμές : Το όνομα δεν πρέπει να περιέχει τον χαρακτήρα του κενού. Ένα παράδειγμα είναι : 76

77 Πίνακας 42 Παράδειγμα αρχείου γράφου για Routers Δηλαδή είναι της μορφής: sourcenodeid(integer) destinationnodeid(integer). Επίσης δεν πρέπει να υπάρχει ανατροφοδότηση, δηλαδή sourcenodeid(integer) sourcenodeid (integer) και διπλά Links, δηλαδή sourcenodeid(integer) destinationnodeid(integer), destinationnodeid (integer) sourcenodeid (integer). Κάθε γραμμή τελειώνει με τον χαρακτήρα \n. RoutersToRoutersLinkSpeedBytes Ορίζει την ταχύτητα επικοινωνίας μεταξύ Routers σε bytes. Έγκυρες τιμές : Double > 0 και maxlinkspeedinbytes >= RoutersToRoutersLinkSpeedBytes + RoutersToRoutersExtraLinkSpeedBytes RoutersToRoutersExtraLinkSpeedBytes Ορίζει επιπλέον την ταχύτητα επικοινωνίας μεταξύ Routers σε bytes. Για κάθε Link Router-Router υπολογίζεται επιπλέον ένα τυχαίος αριθμός bytes με άνω όριο το RoutersToRoutersExtraLinkSpeedBytes ο οποίος προστίθεται στο RoutersToRoutersLinkSpeedBytes και αποτελεί την τελική ταχύτητα σε bytes του Link. Ο λόγος που υπάρχει η τυχαιότητα αυτή είναι για την δημιουργία ανομοιομορφίας στο δίκτυο. Προσοχή πρέπει να δοθεί στο γεγονός ότι αλλαγή αυτής της τιμής συνεπάγεται και αλλαγή των Router tables. Έγκυρες τιμές : Double >= 0 και maxlinkspeedinbytes >= RoutersToRoutersLinkSpeedBytes + RoutersToRoutersExtraLinkSpeedBytes OriginsToRoutersLinkSpeedBytes Ορίζει την ταχύτητα επικοινωνίας μεταξύ Routers και Origins σε bytes. Έγκυρες τιμές : Double > 0 και maxlinkspeedinbytes >= OriginsToRoutersLinkSpeedBytes+ OriginsToRoutersExtraLinkSpeedBytes OriginsToRoutersExtraLinkSpeedBytes Ορίζει επιπλέον την ταχύτητα επικοινωνίας μεταξύ Routers και Origins σε bytes. Για κάθε Link Router-Origin υπολογίζεται επιπλέον ένα τυχαίος αριθμός bytes με άνω όριο το OriginsToRoutersExtraLinkSpeedBytes ο οποίος προστίθεται στο OriginsToRoutersLinkSpeedBytesκαι αποτελεί την τελική ταχύτητα σε bytes του Link. Ο λόγος που υπάρχει η τυχαιότητα αυτή είναι για την δημιουργία ανομοιομορφίας στο δίκτυο. Προσοχή πρέπει να δοθεί στο γεγονός ότι αλλαγή αυτής της τιμής συνεπάγεται και αλλαγή των Router tables. 77

78 Έγκυρες τιμές : Double >= 0 και maxlinkspeedinbytes >= OriginsToRoutersLinkSpeedBytes+ OriginsToRoutersExtraLinkSpeedBytes SurrogatesToRoutersLinkSpeedBytes Ορίζει την ταχύτητα επικοινωνίας μεταξύ Routers και Surrogates σε bytes. Έγκυρες τιμές : Double > 0 και maxlinkspeedinbytes >= SurrogatesToRoutersLinkSpeedBytes+ SurrogatesToRoutersExtraLinkSpeedBytes SurrogatesToRoutersExtraLinkSpeedBytes Ορίζει επιπλέον την ταχύτητα επικοινωνίας μεταξύ Routers και Surrogates σε bytes. Για κάθε Link Router- Surrogates υπολογίζεται επιπλέον ένα τυχαίος αριθμός bytes με άνω όριο το SurrogatesToRoutersExtraLinkSpeedBytes ο οποίος προστίθεται στο SurrogatesToRoutersLinkSpeedBytes αποτελεί την τελική ταχύτητα σε bytes του Link. Ο λόγος που υπάρχει η τυχαιότητα αυτή είναι για την δημιουργία ανομοιομορφίας στο δίκτυο. Προσοχή πρέπει να δοθεί στο γεγονός ότι αλλαγή αυτής της τιμής συνεπάγεται και αλλαγή των Router tables. Έγκυρες τιμές : Double >= 0 και maxlinkspeedinbytes >= SurrogatesToRoutersLinkSpeedBytes + SurrogatesToRoutersExtraLinkSpeedBytes SurrogatesMaxExtraConnectionsToRouters Ορίζει τον αριθμό των επιπλέον συνδέσεων ανά Surrogate με Routers. Ο αριθμός ανά Surrogate υπολογίζεται με τυχαίο τρόπο χρησιμοποιώντας ως άνω όριο το SurrogatesMaxExtraConnectionsToRouters. Προσοχή σε αλλαγές της τιμής αυτής γιατί θα πρέπει να αλλαχθούν και τα Router tables. Έγκυρες τιμές : Integer >= 0 ClientGroupsToSurrogatesLinkSpeedBytes Ορίζει την ταχύτητα επικοινωνίας μεταξύ Surrogates και Client Groups σε bytes. Έγκυρες τιμές : Double > 0 και maxlinkspeedinbytes >= ClientGroupsToSurrogatesLinkSpeedBytes + ClientGroupsToSurrogatesExtraLinkSpeedBytes ClientGroupsToSurrogatesExtraLinkSpeedBytes Ορίζει επιπλέον την ταχύτητα επικοινωνίας μεταξύ Surrogates και Client Groups σε bytes. Για κάθε Link Client Group Surrogate υπολογίζεται επιπλέον ένα τυχαίος αριθμός bytes με άνω όριο το ClientGroupsToSurrogatesExtraLinkSpeedBytes ο οποίος προστίθεται στο ClientGroupsToSurrogatesLinkSpeedBytes αποτελεί την τελική ταχύτητα σε bytes του Link. Ο λόγος που υπάρχει η τυχαιότητα αυτή είναι για την δημιουργία ανομοιομορφίας στο δίκτυο. Προσοχή πρέπει να δοθεί στο γεγονός ότι αλλαγή αυτής της τιμής δεν συνεπάγεται και αλλαγή των Router tables. 78

79 Έγκυρες τιμές : Double > 0 και maxlinkspeedinbytes >= ClientGroupsToSurrogatesLinkSpeedBytes + ClientGroupsToSurrogatesExtraLinkSpeedBytes DATASETS tracefilename Ορίζει το όνομα του αρχείου για το trace file που περιέχει requests. Έγκυρες τιμές : Το όνομα δεν πρέπει να περιέχει τον χαρακτήρα του κενού. Ένα παράδειγμα είναι : Πίνακας 43 Παράδειγμα αρχείου trace Κάθε γραμμή αντιστοιχεί σε μία αίτηση και τελειώνει με τον χαρακτήρα \n. Οι αιτήσεις είναι της μορφής «time(double) ClientID (int) objectid(int)», όπου : time είναι ο χρόνος που πρέπει να υποβληθεί η αίτηση. Το αρχείο πρέπει να βρίσκεται σε αύξουσα σειρά με βάση το χρόνο αλλιώς υπάρχει πρόβλημα. ClientID είναι o Client που κάνει την αίτηση. Προσοχή, δεν αναφέρεται σε Client Groups, είναι απλά ένα ID το οποίο μπορεί να συμμετέχει σε πολλές αιτήσεις. Για αυτό το λόγο πρέπει να υποστεί επεξεργασία και να παραχθεί το cookedtracefilename οπού οι Clients μοιράζονται σε Client Groups. objectid είναι το ID του αντικειμένου που ζητείται κάθε φορά από την αίτηση. objectsfilename Ορίζει το όνομα του αρχείου που περιέχει το σύνολο όλων των αντικειμένων και πληροφορίες για το μέγεθός τους. Έγκυρες τιμές : Το όνομα δεν πρέπει να περιέχει τον χαρακτήρα του κενού. Ένα παράδειγμα είναι :

80 Πίνακας 44 Παράδειγμα αρχείου αντικειμένων Κάθε γραμμή αντιστοιχεί σε ένα αντικείμενο, τελειώνει με τον χαρακτήρα \n και είναι της μορφής «objectid(int) sizeinbytes(int)», όπου: objectid είναι ένα μοναδικό ID για το τρέχον αντικείμενο sizeinbytes είναι το μέγεθος του αντικειμένου σε bytes. cookedtracefilename Ορίζει το όνομα του αρχείου για το cooked trace file που περιέχει requests και Clients μοιρασμένους σε Client Groups. Έγκυρες τιμές : Το όνομα δεν πρέπει να περιέχει τον χαρακτήρα του κενού. Ένα παράδειγμα είναι που αντιστοιχεί σε αυτό του tracefilename: Πίνακας 45 Παράδειγμα αρχείου cooked trace file Κάθε γραμμή αντιστοιχεί σε μία αίτηση και τελειώνει με τον χαρακτήρα \n. Οι αιτήσεις είναι της μορφής «time(double) ClientGroup(int) objectid(int)», όπου : time είναι ο χρόνος που πρέπει να υποβληθεί η αίτηση. Το αρχείο πρέπει να βρίσκεται σε αύξουσα σειρά με βάση το χρόνο αλλιώς υπάρχει πρόβλημα. ClientGroup είναι o Client Group που πρέπει να υποβάλει την αίτηση. Τα ClientIDs έχουν μοιρασθεί σε Client Groups με τέτοιο τρόπο ώστε 80

81 όλες οι εμφανίσεις του ίδιου ClientID να ανήκουν στο ίδιο Client Group. Στην προκειμένη περίπτωση έχουμε 100 Client Groups (100 Surrogate Servers). Για τον εντοπισμό του ID του Client Group ανατρέχουμε στην iοστή θέσή της δομής των Client Groups, δηλαδή αν ClientGroup = 3 τότε το ClientGroupID = ClientGroupsList[3].ID. objectid είναι το ID του αντικειμένου που ζητείται κάθε φορά από την αίτηση. ROUTERS noofsimultaneoustransfersperrouter Ορίζει τον αριθμό των rot_routemaster tasks Έγκυρες τιμές : Integer > 0 RoutersNoOfTriesPerIpDatagramUntilChangeRouter Ορίζει τον αριθμό των αποτυχημένων προσπαθειών χρήσης του προβλεπόμενου μονοπατιού ανά ipdatagram πριν γίνει προσπάθεια για re-routing. Έγκυρες τιμές : Integer > 0 ORIGINS OriginsNoOfBloomFiltersBits Ορίζει τον αριθμό των bloom filter bits που πρέπει να χρησιμοποιηθούν για bitmapping ή για hashing. Έγκυρες τιμές : Integer > 0, για ασφάλεια >= αριθμού των αντικειμένων. OriginsNoOfSimultaneousUploads Ορίζει τον αριθμό των ort_pushmaster tasks. Έγκυρες τιμές : Integer > 0 OriginsNoOfSimultaneousIpdatagramUploads Ορίζει τον αριθμό των ort_simplepusher tasks. Έγκυρες τιμές : Integer > 0 SURROGATES SurrogatesNoOfBloomFiltersBits Ορίζει τον αριθμό των bloom filter bits που πρέπει να χρησιμοποιηθούν για bitmapping ή για hashing. Έγκυρες τιμές : Integer > 0, για ασφάλεια >= αριθμού των αντικειμένων. SurrogatesNoOfSimultaneousUploads Ορίζει τον αριθμό των sut_pushmaster tasks. 81

82 Έγκυρες τιμές : Integer > 0 SurrogatesNoOfSimultaneousIpdatagramUploads Ορίζει τον αριθμό των sut_simplepusher tasks. Έγκυρες τιμές : Integer > 0 SurrogatesNoOfTriesPerIpDatagramUntilChangeRouter Ορίζει τον αριθμό των αποτυχημένων προσπαθειών χρήσης του προβλεπόμενου μονοπατιού ανά ipdatagram πριν γίνει προσπάθεια για re-routing. Έγκυρες τιμές : Integer > 0 SurrogatesNoOfSimultaneousDownloads Ορίζει τον αριθμό των sut_pullmaster tasks. Έγκυρες τιμές : Integer > 0 CLIENT GROUPS maxsessionsperclientgroup Ορίζει τον αριθμό των clt_fetchmaster tasks. Έγκυρες τιμές : Integer > 0 OUTPUT statisticsfilename Ορίζει το όνομα του αρχείου όπου θα γίνονται append τα στατιστικά αποτελέσματα της προσομοίωσης Έγκυρες τιμές : Το όνομα δεν πρέπει να περιέχει τον χαρακτήρα του κενού. Ένα παράδειγμα είναι: -={ =- OPTIONS ******* General Options *************** Max Link speed in MB: Max pdatagram size in MBs: Build Router Table: YES Procces trace file: YES Show progress: YES Save session times: YES Load trace file: YES Simulation duration (virtual time): Parasol debug flag: 4 82

83 Parasol seed: 302 Bloom filters enabled: YES File Options ************ Routers graph file: /home/stamos/databank/eggrafa/ap8/the_project/cdnsim/in_files/graphs/1 Trace file: /home/stamos/databank/eggrafa/ap8/the_project/cdnsim/in_files/datasets/trace Objects ids-sizes file: /home/stamos/databank/eggrafa/ap8/the_project/cdnsim/in_files/datasets/sizes Proccessed trace file: /home/stamos/databank/eggrafa/ap8/the_project/cdnsim/in_files/datasets/cook ed_trace45946 Objects placement file: /home/stamos/databank/eggrafa/ap8/the_project/cdnsim/in_files/placement/pla cement1 Router table file: /home/stamos/databank/eggrafa/ap8/the_project/cdnsim/in_files/router tables/router TABLES_1 Statistics file: /home/stamos/databank/eggrafa/ap8/the_project/cdnsim/out_files/results Client Groups Options ********************* Number of Client Groups: 1 Max simultaneous transfers per Client Group: 30 Max Link speed ClientG <-> Surrogate in MBs: Max extra Link speed ClientG <-> Surrogate in MBs: Surrogates Options ****************** Number of Surrogates: 1 Bloom Filter Bits: 3000 Max simultaneous uploads: 20 Max simultaneous downloads: 20 Max simultaneous uploading pdatagrams: 60 Max Link speed Surrogate <-> Routers in MBs: Max extra Link speed Surrogate <-> Routers in MBs: Max extra connections to Routers: 1 Max tries per pdatagram until change Router: 2 Routers Options *************** Number of Routers: 2 Max simultaneous transfers: 10 Max tries per ipdatagram until change Router: 2 Max Link speed Routers <-> Routers in MBs: Max extra Link speed Routers <-> Routers in MBs: Origins Options *************** Number of Origins: 1 Bloom Filter Bits:

84 Max simultaneous uploads: 100 Max simultaneous uploading pdatagrams: 400 Max Link speed Origin <-> Routers in MBs: Max extra Link speed Origin <-> Routers in MBs: Max tries per pdatagram until change Router: 0 >>>>> STATISTICS: Trace/Objects ************* Generated requests: Loaded objects: 2944 Client Groups ************* Denial: 2622 Satisfied Requests: Mean resp time: Unique Clients: 7066 Surrogates ********** Denial: Serves: Cache misses: Pulls: Failed Pulls: 0 Origins ******* Denial: 0 Pushes: Routers ******** Denial: 0 re-pathings: 0 Rejected pdatagrams: 0 Network pdatagrams: ={ =- Πίνακας 46 Παράδειγμα αρχείου στατιστικών Όπου παρουσιάζονται σε κατανοητή μορφή αρχικά οι ρυθμίσεις και στη συνέχεια τα στατιστικά. Τα στατιστικά είναι χωρισμένα ανά κόμβους, οπότε αν μας ενδιαφέρει να δούμε πόσες αιτήσεις χρηστών έχουν ικανοποιηθεί θα δούμε στα Client Groups -> Satisfied Requests: Για ελέγξουμε αν έχουμε αρκετά clt_fetchmaster tasks αρκεί να δούμε ότι Client Groups -> Denial: 2622 που σημαίνει ότι υπάρχουν αιτήσεις που δεν δρομολογήθηκαν καθόλου από Client Groups. Το πεδίο Surrogates ->Serves περιέχει τις επιτυχημένες μεταφορές στα Client Groups και σε Surrogates (εδώ έχουμε μόνο έναν Surrogate). 84

85 SessionsTimeFilename Ορίζει το όνομα του αρχείου όπου θα γίνονται append πληροφορίες για τα requests. Έγκυρες τιμές : Το όνομα δεν πρέπει να περιέχει τον χαρακτήρα του κενού. Ένα παράδειγμα είναι: OK OK OK OK DOS DOS OK OK OK DOS OK OK OK DOS DOS. Πίνακας 47 Παράδειγμα αρχείου sessions Κάθε γραμμή αντιστοιχεί σε μια αίτηση. Το format είναι «starttime endtime timetaken STATUS» όπου: starttime είναι ο χρόνος έναρξης της αίτησης endtime είναι ο χρόνος λήξης της αίτησης timetaken είναι ο χρόνος που χρειάστηκε γα να τελειώσει (endtime - starttime) STATUS δείχνει την κατάσταση της αίτησης, OK είναι όταν έχει ικανοποιηθεί και DOS όταν απορρίφθηκε από το Surrogate. Να τονίσουμε ότι δεν περιέχονται οι αιτήσεις που απορρίπτονται από το clt_father λόγο μη επάρκειας clt_fetchmaster tasks. Επίσης είναι εμφανές ότι τα μηνύματα που δεν χρησιμοποιούν Links για την μετάδοσή τους δεν απαιτούν χρόνο, αυτό φαίνεται όπου έχουμε DOS και από το γεγονός ότι οι χρόνοι έναρξης ταιριάζουν απόλυτα με αυτούς του trace file. PARASOL maxsimulationduration Ορίζει την μέγιστη διάρκεια του simulation σε μονάδες χρόνου Parasol. Έγκυρες τιμές : Double > 0, για ασφάλεια πολύ μεγάλη τιμή για να μην τερματίσει το simulation πριν διαβαστούν όλες οι αιτήσεις. parasolseed Ορίζει μια τιμή για το «σπόρο» της γεννήτριας τυχαίων αριθμών του Parasol. ΟΠΟΙΑΔΗΠΟΤΕ ΑΛΛΑΓΗ ΣΤΗΝ ΤΙΜΗ ΟΔΗΓΕΙ ΣΕ ΔΙΑΦΟΡΕΤΙΚΗ ΤΟΠΟΛΟΓΙΑ ΚΑΙ ΣΕ ΔΙΑΦΟΡΕΤΙΚΑ ΤΕΛΙΚΑ ΑΠΟΤΕΛΕΣΜΑΤΑ. 85

86 Έγκυρες τιμές : Integer > 0 parasoldebugflag Ορίζει την παράμετρο εκτέλεσης της Parasol. Αν είναι 0 τότε έχουμε την ταχύτερη εκτέλεση χωρίς μηνύματα προειδοποιητικά. Αν είναι 1 τότε έχουμε εκτύπωση όλων των γεγονότων που συμβαίνουν όπως παραλαβές αποστολές μηνυμάτων. Αν είναι 2 τότε έχουμε διακοπή ανά γεγονός και ο χρήστης επεμβαίνει για συνέχεια. Αν είναι 3 τότε διακοπή ανά σημαντικά γεγονότα. Αν είναι 4 τυπώνονται μηνύματα που αφορούν λάθος χρήση των συναρτήσεων της Parasol. Έγκυρες τιμές : {0, 1, 2, 3, 4 Όλες οι παραπάνω ρυθμίσεις είναι διαθέσιμες μέσω του configuration file. Υπάρχουν και άλλες ρυθμίσεις οι οποίες είναι προσβάσιμες μόνο μέσω αλλαγών στον πηγαίο κώδικα. Ρυθμίσεις όπως επεξεργαστές ανά cpu δεν μας ενδιαφέρουν αλλά μπορούν να αλλαχθούν μέσω του αρχείου Options_Globals.h του πηγαίου κώδικα. 86

87 ΠΑΡΑΡΤΗΜΑ Β ΒΗΜΑ ΠΡΟΣ ΒΗΜΑ ΕΓΚΑΤΑΣΤΑΣΗ ΚΑΙ ΕΚΤΕΛΕΣΗ Απόκτηση και οργάνωση αρχείων Υποθέτουμε ότι ο χρήστης βρίσκεται logged on σε περιβάλλον Linux με gcc τουλάχιστον και δικαιώματα read / write σε κάποιο φάκελο και πρόσβαση σε terminal. Επίσης υποθέτουμε ότι είναι διαθέσιμο το αρχείο CDNsim.tar.bz2 το οποίο περιέχει ότι χρειάζεται. Εκτελούμε σε terminal τις παρακάτω εντολές υποθέτοντας ότι με το που ανοίγουμε το terminal βρισκόμαστε σε όπου υπάρχει εκεί το αρχείο CDNsim.tar.bz2 και το shell που χρησιμοποιούμε είναι το bash. Ακόμη πρέπει να υπάρχουν εγκατεστημένα τα bunzip2 και tar προγράμματα. Αν δεν ισχύει κάτι τέτοιο επικοινωνήστε με τον admin του συστήματος για την απόκτηση όλων των απαιτούμενων. 1) mkdir DEMO 2) bunzip2 k CDNsim.tar.bz2 3) mv CDNsim.tar DEMO/ 4) cd DEMO/ 5) tar xvpf CDNsim.tar 6) rm f CDNsim.tar Οπότε στο φάκελο DEMO έχουμε το φάκελο CDNsim που περιέχει τους φακέλους: Documentation HELPERS IN_files MySource OUT_files ParasolLibAndHs και το αρχείο TODO.txt που έχει σημειώσεις για το πρόγραμμα. Ο φάκελος Documentation περιέχει την τεκμηρίωση του κώδικα και την τεκμηρίωση του μοντέλου. Ο φάκελος HELPERS περιέχει τους φακέλους: CDNsimBulkRun GUI Parasol3.1D PlacamentGenerators TraceFileCutter 87

88 Ο φάκελος CDNsimBulkRun περιέχει ένα πρόγραμμα για μαζική εκτέλεση προσομοιώσεων το οποίο δεν είναι ολοκληρωμένο. Ο φάκελος GUI περιέχει ένα γραφικό περιβάλλον σε JAVA για την ρύθμιση της προσομοίωσης. Ο φάκελος Parasol3.1D περιέχει την τρέχουσα έκδοση της Parasol. Ο φάκελος PlacamentGenerators περιέχει διάφορα προγράμματα για την δημιουργία placement αρχείων τα οποία δεν είναι στην τελική έκδοσή τους. Ο φάκελος TraceFileCutter περιέχει ένα χρήσιμο πρόγραμμα που επιτρέπει το κόψιμο μεγάλων αρχείων trace. Ο φάκελος IN_files είναι ο προτεινόμενος φάκελος για την τοποθέτηση των αρχείων εισόδου. Ο φάκελος MySource περιέχει τον πηγαίο κώδικα. Ο φάκελος OUT_files είναι ο προτεινόμενος φάκελος για την τοποθέτηση των αρχείων εξόδου. Ο φάκελος ParasolLibAndHs είναι ο προτεινόμενος φάκελος για την τοποθέτηση των αρχείων βιβλιοθήκης του Parasol. Compilation και απόκτηση της βιβλιοθήκης Parasol Συνεχίζοντας εκτελούμε τις παρακάτω εντολές 7)cd CDNsim/HELPERS/Parasol3.1D/parasol/ 8)pico Makefile 9)αντικαθιστούμε την γραμμή (cd src ; make ) με (cd src ; make f makefile.linux ) 10) ctrl+x 11) Y και μετά enter 12) cd src 13) pico para_library.c 14) στη συνάρτηση LOCAL void block_stats_collector(void) στη γραμμή 3950 αντικαθιστούμε το block_stats_outputer(); με para_block_stats_outputer(); 15) ctrl+x 16) Y και μετά enter 17) cd.. 88

89 18) make libraries 19) mv lib/libparasolc.a../../../parasollibandhs/lib/ 20) cp include/ansidecl.h include/para_internals.h include/para_protos.h include/parasol.h include/para_types.h include/para_version.h../../../parasollibandhs/include/ 21) cd../../../mysource/ 22) make 23) mv simulate../ 24) cd.. Compilation του τελικού προγράμματος 25)./simulate IN_files/Config.conf Εκτέλεση του προγράμματος Υπάρχει ένα έτοιμο αρχείο ρυθμίσεων ΙN_files/Config.conf στο οποίο φαίνονται όλες οι λεπτομέρειες της δοκιμαστικής αυτής εκτέλεσης. Συνοπτικά αυτό που χρειάζεται είναι η δημιουργία ενός εκτελέσιμου και ενός αρχείου ρυθμίσεων παρέχοντας όλα τα απαραίτητα που έχουν περιγραφεί στην ενότητα

90 ΠΑΡΑΡΤΗΜΑ Γ ΕΓΧΕΙΡΙΔΙΟ ΧΡΗΣΗΣ ΤΟΥ ΓΡΑΦΙΚΟΥ ΠΕΡΙΒΑΛΛΟΝΤΟΣ Σκοπός του γραφικού περιβάλλοντος (GUI) είναι η διευκόλυνση του χρήστη στην παραγωγή έγκυρων αρχείων ρυθμίσεων για τον προσομοιωτή. Ο χρήστης δεν είναι πλέον υποχρεωμένος να επεξεργάζεται τα αρχεία σε επεξεργαστές κειμένων και δεν χρειάζεται να προβληματίζεται για την ορθότητα των επιλογών. Ο προσομοιωτής δεν περιέχει κάποιο μηχανισμό εντοπισμού μη επιθυμητών τιμών γιατί στόχος είναι ο πειραματισμός με διάφορες ρυθμίσεις. Η λειτουργίες του GUI αφορούν ταυτόχρονο έλεγχο των ρυθμίσεων καθώς κάνει αλλαγές ο χρήστης και αποθήκευση και φόρτωση αρχείων ρυθμίσεων. Η φιλοσοφία του είναι απλή και βασίζεται σε tabs κατηγοριών ρυθμίσεων. Είναι ανεπτυγμένο σε JAVA 1.4.2, οπότε το JAVA runtime πρέπει να είναι εγκατεστημένο έτσι ώστε να εκτελεστεί το αρχείο jar που αντιστοιχεί στο GUI. Με την εντολή java jar jarfile.jar εκτελείται το εκτελέσιμο jarfile.jar που στην προκειμένη περίπτωση είναι το CDNsim_GUI.jar που βρίσκεται στο φάκελο HELPERS/GUI/CDNsim_GUI/ αν ακολουθηθούν τα βήματα της προηγούμενης ενότητας. 90

91 Μία τυπική εικόνα του GUI είναι η παρακάτω. Εικόνα 13 Κύρια οθόνη GUI Όπου: 1. Είναι μια ετικέτα η οποία δίνει μια πολύ σύντομη περιγραφή της ρύθμισης που βρίσκεται δεξιά της. 2. Είναι ένα πεδίο που περιέχει την τρέχουσα τιμή της ρύθμισης που περιγράφεται στα αριστερά. Μπορεί να ζητείται κάποιο όνομα αρχείου ή να οριστεί μια αριθμητική τιμή ή να γίνει επιλογή από μια λίστα. 3. Το κουμπί αυτό επιτρέπει στο χρήστη να αναζητήσει ένα αρχείο που υπάρχει ήδη και να ενημερωθεί η τιμή στα αριστερά του. 4. Βοηθά το χρήστη να καταλάβει σε ποίο tab βρίσκεται. 5. Βοηθά τον χρήστη να καταλάβει ποια tabs δεν είναι επιλεγμένα. 6. Εκεί αναγράφεται ποιο αρχείο ρυθμίσεων επηρεάζεται αν ο χρήστης επιλέξει αποθήκευση των ρυθμίσεων. 7. Περιέχονται τα βοηθητικά κομβία και φόρτωση, αποθήκευση και βοήθεια. 8. Μενού επιλογών τα οποία περιέχουν της επιλογές αποθήκευσης, αποθήκευσης σε διαφορετικό αρχείο από το τρέχον, φόρτωσης αρχείου, βοήθειας και εξόδου. 9. Αν ο χρήστης αφήσει το κέρσορα του ποντικιού πάω από κάποια ετικέτα τότε εμφανίζονται πληροφορίες σχετικά με την διπλανή επιλογή όπως 91

92 ποιες είναι οι επιτρεπτές τιμές και ποιες είναι οι συνέπειες για την προσομοίωση. Προφανώς οι πληροφορίες είναι οι ελάχιστες δυνατές, προτείνεται ο χρήστης να ανατρέξει στην πλήρη περιγραφή των επιλογών. Tabs Στη συνέχεια παρουσιάζονται όλα τα tabs μαζί με τις ρυθμίσεις στο αρχείο ρυθμίσεων που επηρεάζονται. Έστω το αρχείο ρυθμίσεων: //SIMULATION //GENERAL OPTIONS (use 0 or 1) buildrouter tables=1 cooktracefile=1 showprogress=0 savesessionstimes=0 loadtracefiletoram=0 usebloomfilters=0 //PLACEMENT (use filenames without spaces ) objectsplacementfilename=objectsplacementfilename //TOPOLOGY / NETWORK (use filenames without spaces ) maxlinkspeedinbytes= e9 maxsimulatedipdatagramsizeinbytes= Router tablesfilename=router tablesfilename noofsurrogates=20 nooforigins=1 RoutersGraphFilename=RoutersGraphsFilename RoutersToRoutersLinkSpeedBytes= RoutersToRoutersExtraLinkSpeedBytes=0.0 OriginsToRoutersLinkSpeedBytes= OriginsToRoutersExtraLinkSpeedBytes=0.0 SurrogatesToRoutersLinkSpeedBytes= SurrogatesToRoutersExtraLinkSpeedBytes=0.0 SurrogatesMaxExtraConnectionsToRouters=1 ClientGroupsToSurrogatesLinkSpeedBytes= ClientGroupsToSurrogatesExtraLinkSpeedBytes=0.0 //DATASETS (use filenames without spaces ) tracefilename=tracefilename objectsfilename=objectsfilename cookedtracefilename=cookedtracefilename //ROUTERS noofsimultaneoustransfersperrouter=10 RoutersNoOfTriesPerIpDatagramUntilChangeRouter=2 //ORIGINS OriginsNoOfBloomFiltersBits= OriginsNoOfSimultaneousUploads=20 OriginsNoOfSimultaneousIpdatagramUploads=60 //SURROGATES SurrogatesNoOfBloomFiltersBits= SurrogatesNoOfSimultaneousUploads=20 SurrogatesNoOfSimultaneousIpdatagramUploads=60 SurrogatesNoOfTriesPerIpDatagramUntilChangeRouter=2 SurrogatesNoOfSimultaneousDownloads=20 //CLIENT GROUPS maxsessionsperclientgroup=30 //OUTPUT (use filenames without spaces ) statisticsfilename=statsiticsfilename sessionstimefilename=sessionstimefilename //PARASOL (for parasoldebugflag use 0 -> NOTHING, 1 -> TRACE, 2 -> STEP (interactive), 3 -> STEP EVENT, 4 - > WARNING) maxsimulationduration=

93 parasolseed=302 parasoldebugflag=0 Οπότε ανά tab έχουμε (με κόκκινο δηλώνουμε το όνομα της ρύθμισης που επηρεάζεται στο αρχείο): Εικόνα 14 General Options Tab Καρτέλα (tab) που αφορά γενικές ρυθμίσεις-παραμέτρους 93

94 Εικόνα 15 Output Options Tab Καρτέλα (tab) που αφορά I/O Εικόνα 16 Parsol Options Tab 94

95 Καρτέλα (tab) που αφορά ρυθμίσεις της Parasol Εικόνα 17 Network-Topology Options Tab Καρτέλα (tab) που αφορά ρυθμίσεις της τοπολογίας (κόμβοι, ταχύτητες 95

96 Εικόνα 18 Surrogate Options Tab Καρτέλα (tab) που αφορά ρυθμίσεις των Surrogate Servers 96

97 Εικόνα 19 Origins Options Tab Καρτέλα (tab) που αφορά ρυθμίσεις των Origin Servers Εικόνα 20 RoutersOptions Tab 97

98 Καρτέλα (tab) που αφορά ρυθμίσεις των Routers Εικόνα 21 Clients Options Tab Καρτέλα (tab) που αφορά ρυθμίσεις των Clients 98

99 Εικόνα 22 Placemment Options Tab Καρτέλα (tab) που αφορά ρυθμίσεις σχετικές με την τοποθέτηση αντικειμένων στους σκληρούς δίσκους 99

100 Εικόνα 23 Data sets Options Tab Καρτέλα (tab) που αφορά ρυθμίσεις σχετικές με τα datasets 100