Περιγραφή της Υλοποίησης της Αρχιτεκτονικής LibraRing

Σε αυτή την ενότητα θα παρουσιαστούν διάφορα σημαντικά θέματα υλοποίησης της αρχιτεκτονικής του συστήματος LibraRing. Η σειρά με την οποία θα παρουσιαστούν είναι όμοια με τη σειρά παρουσίασης της προηγούμενης ενότητας, της περιγραφής της αρχιτεκτονικής LibraRing. Έτσι, στην Ενότητα 4.1 περιγράφεται η υλοποίηση των προσφερόμενων υπηρεσιών, ενω στην Ενότητα 4.2 περιγράφεται η υλοποίηση των προσφερόμενων πρωτοκόλλων και παράλληλα παρουσιάζονται μερικοί επιλεγμένοι αλγόριθμοι που βοηθούν στην κατανόησή τους.

Για την υλοποίηση του συστήματος LibraRing χρησιμοποιήθηκε η γλώσσα προγραμματισμού Java σε συνδυασμό με τη τεχνολογία του ΚΠΚ Pastry που προσφέρεται από το πακέτο FreePastry^4.1. To FreePastry είναι και αυτό γραμμένο στη γλώσσα προγραμματισμού Java. Παράλληλα, χρησιμοποιείται η τεχνολογία XML για την αναπαράσταση των δεδομένων, όπως επερωτήσεις, δημοσιεύσεις και ειδοποιήσεις, όπως περιγράφηκε και στην Ενότητα 2.6.

Εδώ θα πρέπει να σημειώσουμε ότι υπάρχουν δύο λειτουργίες της αρχιτεκτονικής LibraRing -- η πολλαπλή αποστολή μηνυμάτων από έναν υπερ-κόμβο σε άλλους και η δυνατότητα αποχώρησης / συμμετοχής νέων υπερ-κόμβων -- που δεν έχουν υλοποιηθεί. Και οι δύο αναφέρονται σε επικοινωνία μεταξύ των υπερ-κόμβων, δηλαδή των κόμβων που αναλαμβάνουν να εκτελέσουν και να προσφέρουν τη διεπαφή των κατανεμημένων πινάκων κατακερματισμού και είναι λογικό διαφορετικά συστήματα που υλοποιούν αυτή τη διεπαφή να διαφέρουν σε σχεδιαστικά θέματα. Δεδομένου, επίσης, ότι η αρχιτεκτονική LibraRing έχει περιγραφεί βάσει του ΚΠΚ που υλοποιείται από το σύστημα Chord, ενώ η υλοποίησή του έγινε χρησιμοποιώντας το σύστημα Pastry, κάτι τέτοιο είναι απολύτως λογικό.

Πιο συγκεκριμένα, το σχεδιαστικό θέμα του Chord, το οποίο δεν υιοθετείται και από το Pastry είναι η έννοια του successor, predecessor κόμβου στο δακτύλιο αναγνωριστικών του Chord σε συνδυασμό με τη δομή του πίνακα δεικτών^4.2. Στην πρώτη λειτουργία, δηλαδή στην αποστολή του ίδιου μηνύματος από έναν υπερ-κόμβο σε πολλούς^4.3 ο αποστολέας υπερ-κόμβος θα κατασκεύαζε μία ταξινομημένη λίστα, σε αύξουσα σειρά ως προς τα αναγνωριστικά των παραληπτών υπερ-κόμβων, και θα έστελνε το μήνυμα στον πρώτο από αυτούς. Ο παραλήπτης θα έλεγχε αν είναι υπεύθυνος για αυτό το μήνυμα και σε αρνητική απάντηση θα προωθούσε το μήνυμα στον πρώτο κόμβο της λίστας συμβουλευόμενος τον πίνακα δεικτών του. Σε θετική απάντηση θα αφαιρούσε από τη λίστα τα αναγνωριστικά για τα οποία θα ήταν υπεύθυνος, κρατώντας επίσης και το ίδιο το μήνυμα και θα προωθούσε και πάλι το μήνυμα στον πρώτο κόμβο της λίστας, αν αυτός υπήρχε, συμβουλευόμενος πάντα τον πίνακα δεικτών του. Αυτή η διαδικασία αποτελεί μία βελτιστοποίηση για την πολλαπλή αποστολή ενός μηνύματος σε περισσότερους από έναν υπερ-κόμβους, αφού με τη χρήση της μειώνονται σε σημαντικό βαθμό ο αριθμός των hops που χρειάζεται για να φτάσει το μήνυμα σε όλους τους παραλήπτες.

Το ίδιο σχεδιαστικό θέμα του Chord εμποδίζει την ακριβή υλοποίηση της λειτουργίας σύνδεσης / αποσύνδεσης ενός υπερ-κόμβου^4.4. Σύμφωνα με αυτή, κατά τη σύνδεση ενός υπερ-κόμβου, αυτός θα πρέπει να γίνει ο predecessor ενός κόμβου $n$ και ο successor του πρώην predecessor του κόμβου $n$ . Στη συνέχεια ο νεο-συνδεδεμένος κόμβος θα πρέπει να παραλάβει όλα τα δεδομένα για τα οποία είναι υπεύθυνος από τον κόμβο $n$ και να ενημερώσει κατάλληλα το δίκτυο για την ύπαρξή του. Μία παρόμοια διαδικασία ενημέρωσης του successor και predecessor και αποστολής των δεδομένων γίνεται και όταν ένας υπερ-κόμβος χρειάζεται να αποχωρήσει από το δίκτυο.