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

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ & ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ Διπλωματική Εργασία ΑΣΚΗΤΗΣ ΠΑΝΑΓΙΩΤΗΣ ΘΕΟΔΩΡΟΥ ΕΥΣΤΡΑΤΙΟΣ Κωδικοποίηση ήχου με τεχνικές πολλαπλών περιγραφών και μετάδοση ήχου σε πραγματικό χρόνο σε δίκτυα ομότιμων τερματικών Επιβλέπων καθηγητής κ. Δημήτρης Μητράκος

2 Ευχαριστίες Με την ευκαιρία της ολοκλήρωσης της διπλωματικής μας εργασίας, θα θέλαμε να ευχαριστήσουμε τον επιβλέποντα καθηγητή κ. Δημήτρη Μητράκο για την πολύτιμη καθοδήγησή του καθ' όλη τη διάρκειά της και για τις χρήσιμες και ενδιαφέρουσες συζητήσεις που είχαμε. Επίσης, ένα μεγάλο ευχαριστώ στις οικογένειες και τους φίλους μας, οι οποίοι μας βοήθησαν με τον τρόπο τους όλον αυτόν τον καιρό της εκπόνησης της διπλωματικής εργασίας, αλλά και των σπουδών μας γενικότερα. 2

3 Περιεχόμενα ΚΕΦΑΛΑΙΟ 1ο - ΕΙΣΑΓΩΓΗ... 6 Ιστορική αναδρομή... 6 Σκοπός της διπλωματικής... 7 Διάρθρωση Διπλωματικής... 7 Λέξεις - Κλειδιά... 8 ΚΕΦΑΛΑΙΟ 2ο - ΘΕΩΡΗΤΙΚΟ ΥΠΟΒΑΘΡΟ... 9 Εισαγωγή... 9 Internet Protocol Suite & OSI model... 9 Internet Protocol Suite... 9 OSI Model Πρωτόκολλο Internet & IPv4 vs. IPv Κύρια χαρακτηριστικά του Internet Protocol Τι είναι το best effort delivery; Γιατί να σχεδιαστεί ένα πρωτόκολλο αναξιόπιστο; IPv4 vs. IPv Πρωτόκολλα TCP, UDP και RTP Πρωτόκολλο TCP Πρωτόκολλο UDP TCP vs. UDP Γιατί υπάρχει το UDP; Τι εξυπηρετεί; Πρωτόκολλο RTP Μέθοδοι δρομολόγησης (Routing Schemes) Unicast Broadcast Multicast Anycast Δίκτυα Ομότιμων Κόμβων (Peer-to-Peer Networks) Συγκεντρωμένα P2P δίκτυα Αποκεντρωμένα P2P δίκτυα P2P δίκτυα τρίτης γενιάς Άλλα P2P δίκτυα

4 Κωδικοποίηση Πολλαπλών Περιγραφών (MDC) Κβαντισμός Speech Coding for Channel Splitting Progressive Coding & Unequal Error Protection Τεχνικές Ανακατασκευής Πακέτων Διόρθωση στην πλευρά του αποστολέα Διόρθωση στην πλευρά του παραλήπτη Επιλογή Τεχνικής Ανακατασκευής Επίλογος ΚΕΦΑΛΑΙΟ 3 ο - ΠΑΡΟΜΟΙΕΣ ΕΡΓΑΣΙΕΣ Εισαγωγή Adaptive packet video streaming over P2P networks using active measurements Distributing streaming media content using cooperative networking Challenges & approaches in large-scale P2P media streaming Επίλογος ΚΕΦΑΛΑΙΟ 4 ο - ΠΑΡΟΥΣΙΑΣΗ ΕΦΑΡΜΟΓΗΣ Εισαγωγή Προδιαγραφές Εφαρμογής Γιατί Java Ελάχιστες απαιτήσεις Περιγραφή Server Λογικό διάγραμμα λειτουργίας του Server Εξυπηρέτηση πακέτων Multi-threading & συγχρονισμός Επιλογή UDP έναντι TCP Επίλυση κοινών προβλημάτων Περιγραφή Peer Γενικά Τύποι λειτουργίας Χρήση UDP & TCP Τεχνολογίες Μετάδοσης Ήχου Δομημένο Peer-to-Peer Χρήση MDC & τοποθέτηση των peers στις δομές μετάδοσης

5 Τεχνικές Forward Error Correction και Επαναποστολή πακέτων Λογικά Διαγράμματα Λογικό διάγραμμα κεντρικής λειτουργίας του Peer Λογικό διάγραμμα Packet Handler Λογικό διάγραμμα Socket Handler Λογικό διάγραμμα Retransmit Handler Λογικό διάγραμμα Broadcaster Λογικό διάγραμμα Listener Εικόνες λειτουργίας της εφαρμογής ΚΕΦΑΛΑΙΟ 5 o - ΜΕΤΡΗΣΕΙΣ Εισαγωγή Προετοιμασία Μετρήσεων Έλεγχος συμφόρησης & μέγεθος πακέτου Μετρήσεις απώλειας πακέτων σε δίκτυο P2P Επαναποστολή πακέτων Επίλογος ΚΕΦΑΛΑΙΟ 6 ο - ΣΥΜΠΕΡΑΣΜΑΤΑ, ΠΑΡΑΤΗΡΗΣΕΙΣ & ΠΕΡΑΙΤΕΡΩ ΑΝΑΛΥΣΗ Αρχικές Προσπάθειες Χρήση TCP Multicast Πλατφόρμα JXTA Συμπεράσματα & Παρατηρήσεις UDP Lost Packets & Reasons UDP Arriving Κωδικοποιήσεις Ήχου Packet Size vs. Βέλτιστο Throughput Πολυπλοκότητες Δομών και αναζήτησης Μελλοντική επέκταση ΚΕΦΑΛΑΙΟ 7 ο - ΒΙΒΛΙΟΓΡΑΦΙΑ & ΠΗΓΕΣ Papers Links

6 ΚΕΦΑΛΑΙΟ 1 ο ΕΙΣΑΓΩΓΗ Ιστορική αναδρομή Στις αρχές του 1999 ο Shawn Fanning (γνωστός με το ψευδώνυμο Napster) ξεκίνησε την υλοποίηση μιας ιδέας, η οποία θα έδινε τη δυνατότητα αυτός και οι φίλοι του να μπορούν να αναζητήσουν στο Internet μουσικά κομμάτια MP3 της προτίμησής τους. Μερικούς μήνες αργότερα, η Napster Inc. μετρούσε πάνω από 21 εκατομμύρια χρήστες. Σε καμία περίπτωση όμως ο 18χρονος τότε μαθητής δεν μπορούσε να φανταστεί ότι το δημιούργημά του θα άλλαζε τον τρόπο με τον οποίο απολαμβάνουμε πολυμεσικές εφαρμογές και γενικά επικοινωνούμε. Η εφαρμογή του Fanning έγινε νούμερο 1 στις προτιμήσεις των χρηστών στον δικτυακό τόπο download.com και άνοιξε το δρόμο για την επανάσταση των δικτύων Peer-to-Peer η οποία συνεχίζεται ως τις μέρες μας. Ένα δίκτυο ομότιμων τερματικών ή αλλιώς ένα δίκτυο υπολογιστών Peer-to-Peer (P2P) είναι ένα δίκτυο που επιτρέπει σε δύο ή περισσότερους υπολογιστές να μοιράζονται τους πόρους τους ισοδύναμα. Το δίκτυο αυτό χρησιμοποιεί την επεξεργαστική ισχύ, τον αποθηκευτικό χώρο και το εύρος ζώνης (bandwidth) των κόμβων του. Όλοι οι κόμβοι του δικτύου έχουν ίσα δικαιώματα (ομότιμοι κόμβοι). Πληροφορίες που βρίσκονται στον ένα κόμβο, ανάλογα με τα δικαιώματα που καθορίζονται, μπορούν να διαβαστούν από όλους τους άλλους και αντίστροφα. Σε ένα P2P δίκτυο, σε αντίθεση με την παραδοσιακή αρχιτεκτονική του clientserver μοντέλου, όσο αυξάνεται ο αριθμός των χρηστών τόσο αυξάνεται η ευρωστία και η συνολική δυναμική σε πόρους του δικτύου. Το P2P σαν τεχνολογία βρίσκει χρήση σήμερα σε μια πληθώρα εφαρμογών. Από τη διανομή μεγάλων σε όγκο πολυμεσικών αρχείων, το media streaming και την τηλεφωνία, μέχρι και σε βαριές εφαρμογές του Στρατού και της Βιοπληροφορικής. Ανάμεσα σε αυτήν την πληθώρα εφαρμογών, ας αναφέρουμε ονομαστικά μερικές από τις οποίες έχουν ξεχωρίσει εμπορικά. To πασίγνωστο Skype (2003) για τηλεφωνία μέσω internet, το Kazaa (2000) και τα παραπλήσια του προγράμματα για file sharing, το Joost (2007) σαν μια πρώτη προσπάθεια μετάδοσης near TV quality shows, όπως επίσης και το United Devices Cancer Research Project (2000) που, με τη βοήθεια της επεξεργαστικής ισχύς υπολογιστών σε παγκόσμιο επίπεδο, προσπαθεί να βρει την θεραπεία για τον καρκίνο, μια πρωτοβουλία που ξεκίνησε από το πανεπιστήμιο της Οξφόρδης. Τέλος, η χρήση των P2P δικτύων έχει δώσει ώθηση στην ανάπτυξη διαφόρων τεχνικών που προσπαθούν να βρουν αποτελεσματικούς τρόπους για την αναζήτηση υλικού μέσα σε ένα τέτοιο δίκτυο, τη δρομολόγηση της πληροφορίας, τη συμπίεση των δεδομένων, κλπ. Εστιάζοντας κυρίως στη δρομολόγηση της πληροφορίας, ένας δημοφιλής τρόπος για να 6

7 σπάσουμε την πληροφορία μας σε κομμάτια, τα οποία θα τα μεταδώσουμε από ξεχωριστά κανάλια, είναι η κωδικοποίηση πολλαπλών περιγραφών ή Multiple Description Coding (MDC). Όπως σχεδόν οποιαδήποτε τεχνολογία επικοινωνιών, το MDC ανακαλύφθηκε στα Bell Laboratories και χρησιμοποιήθηκε για πρώτη φορά στη μετάδοση φωνής από ξεχωριστά κανάλια σε τηλεφωνικά δίκτυα, ως ένας τρόπος αύξησης της αξιοπιστίας τους. Από τότε έχει γίνει μια ολόκληρη επιστήμη, που ασχολείται με το πως μπορούμε να φτιάξουμε αποτελεσματικές ανεξάρτητες περιγραφές από μια αρχική πηγή. Σκοπός της διπλωματικής Σε αυτή τη διπλωματική εργασία θα παρουσιάσουμε την υλοποίηση ενός υβριδικού δικτύου ομότιμων κόμβων (θα αναφερόμαστε σε αυτό από εδώ και πέρα με τον όρο P2P) και θα μελετήσουμε το κατά πόσο είναι δυνατό να μεταδώσουμε ήχο σε πραγματικό χρόνο σε αυτό. Χρησιμοποιούμε έναν κεντρικό Server, o οποίος αναλαμβάνει την αρχικοποίηση των Peers στο δίκτυο. Κάποιος από τους Peers δηλώνει ότι θέλει να είναι ο εκπομπός (Broadcaster) και οι Peers που θέλουν να τον ακούσουν (Listeners) επιλέγουν αν θα συνδεθούν πάνω του. Έτσι στην ουσία μελετάμε την μετάδοση ήχου από μια πηγή σε πολλούς δέκτες. Οι Peers οργανώνονται σε ομάδες-δομές τις οποίες τις ονομάζουμε layers και κάθε layer έχει όλους τους Peers, αλλά σε διαφορετική θέση ανάλογα με το μέσο RTT τους (Round Trip Delay Time). Ο ήχος που μεταδίδει ο εκπομπός χρησιμοποιεί την τεχνική της κωδικοποίησης πολλαπλών περιγραφών (MDC) και κάθε περιγραφή μεταδίδεται από διαφορετικό layer. Τέλος, σε περιπτώσεις απώλειας πληροφορίας λόγω της φύσης του δικτύου, χρησιμοποιούμε τεχνικές ανακατασκευής των χαμένων πακέτων (Forward Error Correction). Τα αποτελέσματα της εφαρμογής είναι άκρως ικανοποιητικά καθώς όλοι οι Peers καταφέρνουν να ακούσουν ήχο σε πραγματικό χρόνο και η ανοχή του δικτύου σε χαμένα πακέτα γίνεται πολύ μεγάλη χάρη στο MDC και στα πολλαπλά layers. Διάρθρωση Διπλωματικής Στο κεφάλαιο 2 παρουσιάζουμε όλο το απαραίτητο θεωρητικό υπόβαθρο το οποίο θα βοηθήσει τον αναγνώστη να διασαφηνίσει βασικές έννοιες και να κατανοήσει το πρόβλημα. Ακολουθώντας τις πηγές από όπου αντλήθηκαν οι πληροφορίες μπορεί να εμβαθύνει ακόμα περισσότερο στο αντικείμενο. Στο κεφάλαιο 3 κάνουμε μια μικρή αναφορά σε παρόμοιες εργασίες που ασχολήθηκαν με τη μετάδοση πολυμεσικού υλικού σε P2P δίκτυα και τις τεχνικές που χρησιμοποιούνται για επίλυση των προβλημάτων. 7

8 Στο κεφάλαιο 4 παρουσιάζουμε αναλυτικά την εφαρμογή μας τόσο θεωρητικά όσο και σχηματικά. Αναλύονται ξεχωριστά οι λειτουργίες του Server και του Peer, ενώ βλέπουμε στην πράξη τη χρήση κάποιων από τις τεχνολογίες του 2 ου κεφαλαίου. Στο κεφάλαιο 5 έχουμε μια πληθώρα μετρήσεων που ελήφθησαν κατά την διενέργεια πολλών πειραμάτων για τις ανάγκες της εργασίας. Στο κεφάλαιο 6, που πιστεύουμε ότι είναι ίσως από τα πιο ενδιαφέροντα κεφάλαια, βγάζουμε τα συμπεράσματα από τις μετρήσεις του 5 ου κεφαλαίου. Σχολιάζουμε πράγματα που δούλεψαν και άλλα που δεν δούλεψαν όπως περιμέναμε, καθώς και βελτιώσεις που θα μπορούσαν να γίνουν σε μια μελλοντική επέκταση της εργασίας. Τέλος, στο κεφάλαιο 7, δίνουμε όλη τη βιβλιογραφική αναφορά η οποία συνετέλεσε τα μέγιστα για την ολοκλήρωση αυτής της εργασίας. Λέξεις - Κλειδιά Λέξεις κλειδιά για αυτή τη διπλωματική εργασία αποτελούν τα παρακάτω: Peer-to-Peer (P2P) Multiple Description Source Coding (MDC) Forward Error Correction (FEC) Fluid Point Approximation Client Resource Allocation ΙPv6 vs. IPv4 8

9 ΚΕΦΑΛΑΙΟ 2 ο ΘΕΩΡΗΤΙΚΟ ΥΠΟΒΑΘΡΟ Εισαγωγή Σε αυτήν την ενότητα θα παρουσιάσουμε κάποιες απαραίτητες έννοιες, σχετικές με τα δίκτυα υπολογιστών και τη μετάδοση δεδομένων σε αυτά, που θα βοηθήσουν περαιτέρω τόσο στην κατανόηση του πως οι υπολογιστές επικοινωνούν μεταξύ τους, όσο και στη λειτουργία της εφαρμογής μας. Αρχικά γίνεται μια σύντομη παρουσίαση δύο βασικών εννοιών που χρησιμοποιούνται σήμερα στην επικοινωνία των υπολογιστών, της Internet Protocol Suite και του μοντέλου OSI. Internet Protocol Suite & OSI model Internet Protocol Suite Η Internet Protocol Suite είναι ένα σύνολο πρωτοκόλλων επικοινωνίας που απαρτίζουν ουσιαστικά το Διαδίκτυο (Internet) και τα περισσότερα εμπορικά δίκτυα. Αποκαλείται πολλές φορές και TCP/IP Protocol Suite, παίρνοντας το όνομα αυτό από τα δύο σημαντικότερα πρωτόκολλα που περιέχει: το Transmission Control Protocol (TCP) και το Internet Protocol (IP), τα οποία ήταν τα πρώτα πρωτόκολλα που καθορίστηκαν. Η Internet Protocol Suite μπορεί να θεωρηθεί ως ένα σύνολο τεσσάρων επιπέδων (layers) που το καθένα λύνει ένα σύνολο προβλημάτων που εμφανίζονται στη μετάδοση δεδομένων, και παρέχει μια, καθορισμένη με σαφήνεια, υπηρεσία στα πρωτόκολλα ανώτερου επιπέδου. Τα ανώτερα επίπεδα είναι πιο κοντά στον άνθρωπο-χρήστη, ασχολούνται με πιο αφηρημένα στοιχεία και στηρίζονται στα χαμηλότερα επίπεδα για να μετατρέψουν τα στοιχεία αυτά στις φυσικές μορφές που μπορούν τελικά να μεταδοθούν μέσα από τα δίκτυα. Στις παρακάτω εικόνες φαίνεται το TCP/IP Protocol Suite, όπως σχηματικά υλοποιείται στην επικοινωνία δύο υπολογιστών και ενδεικτικά κάποιες τεχνολογίες που υλοποιούνται σε κάθε επίπεδο. 9

10 (α) (β) (α) Internet Protocol Suite & επικοινωνία δύο υπολογιστών (β) Ενδεικτικές τεχνολογίες ανά επίπεδο OSI Model Το OSI (Open Systems Interconnection) model δεν είναι παρά η εξέλιξη της TCP/IP suite. Αποτελείται από μια ιεραρχική δομή επτά επιπέδων που καθορίζει τις απαιτήσεις για την επικοινωνία μεταξύ δύο υπολογιστών. Το πρότυπο καθορίστηκε από το Διεθνή Οργανισμό για την Τυποποίηση (International Organization for Standardization), στα πρότυπα του ISO Δημιουργήθηκε για να επιτρέψει την επικοινωνία μεταξύ των διαφορετικών πλατφορμών που προέρχονται από διάφορους προμηθευτές. Το OSI επιτρέπει δηλαδή σε όλα τα στοιχεία ενός δικτύου να συνεργάζονται, ανεξάρτητα από ποιος τα κατασκεύασε. Κάθε επίπεδο έχει την ιδιότητα ότι χρησιμοποιεί μόνο τις λειτουργίες του αμέσως κατώτερου επιπέδου και εξάγει πληροφορία και λειτουργία μόνο προς το αμέσως ανώτερό του επίπεδο. Στο παρακάτω σχήμα φαίνεται η σχέση TCP/IP model και OSI model. Όπως είναι φανερό, τα 3 ανώτερα επίπεδα του OSI model, το Application layer, το Presentation layer και το Session layer, συνήθως υλοποιούνται σε ένα μόνο επίπεδο, πάνω από το Transport layer του TCP/IP model. Παρόλο αυτά δεν υπάρχει κάποιος συγκεκριμένος μηχανισμός που να απαγορεύει στο TCP/IP model να χρησιμοποιήσει περισσότερα του ενός επιπέδου, πάνω από το Transport layer. 10

11 TCP/IP και OSI models Σήμερα χρησιμοποιείται μόνο ένα υποσύνολο ολόκληρου του προτύπου OSI. Θεωρείται ότι ένα μεγάλο μέρος των προδιαγραφών του είναι πάρα πολύ περίπλοκο και ότι η πλήρης ενσωμάτωση και λειτουργία του θα καθυστερήσει πολύ, αν και υπάρχουν πολλοί άνθρωποι που το υποστηρίζουν έντονα. Πρωτόκολλο Internet & IPv4 vs. IPv6 Το Internet Protocol (IP) βρίσκεται στο Network layer του TCP/IP model και, όπως είπαμε, είναι ένα από τα σημαντικότερα πρωτόκολλα του. Ενσωματώνεται σε τεχνολογίες που βρίσκονται στο αμέσως από κάτω του επίπεδο, το Data Link layer, όπως για παράδειγμα το Ethernet. Είναι ένα data-oriented πρωτόκολλο, το οποίο χρησιμοποιείται για να στέλνονται δεδομένα σε μορφή πακέτων μέσα από ένα δίκτυο υπολογιστών. Τα πακέτα είναι μικρές ακολουθίες από bytes που αποτελούνται από την επικεφαλίδα (header) και το κυρίως μέρος. Η επικεφαλίδα περιγράφει τον προορισμό του πακέτου, τον οποίο χρησιμοποιούν τα routers στο Internet για να κατευθύνουν το πακέτο στον τελικό του προορισμό. 11

12 Κύρια χαρακτηριστικά του Internet Protocol Το Internet Protocol έχει δύο κύρια χαρακτηριστικά: Είναι Connectionless πρωτόκολλο Για να πάνε τα δεδομένα από έναν υπολογιστή σε έναν άλλο δεν χρειάζεται κάποια προηγούμενη επικοινωνία. Είναι αναξιόπιστο Αυτό σημαίνει ότι υλοποιεί τα λεγόμενο best effort delivery. Δεν υπάρχει εγγύηση για τα πακέτα ότι δεν θα χαθούν, αλλοιωθούν ή ότι θα φτάσουν με τη σωστή σειρά. Από πλευράς αξιοπιστίας το μόνο που κάνει το IP είναι να ελέγχει την επικεφαλίδα του πακέτου που θα στείλει ότι είναι error free, με τη χρήση checksum. Σε περίπτωση συμφόρησης δεδομένων το IP μπορεί να απορρίψει πακέτα ή ακόμα, για λόγους αποδοτικότητας, 2 συνεχόμενα πακέτα να τα στείλει από διαφορετικές διευθύνσεις. Τι είναι το best effort delivery; Ο όρος best effort delivery περιγράφει ένα network service, για το οποίο το δίκτυο δεν παρέχει εγγύηση ότι τα δεδομένα του μεταδίδονται σωστά ή ότι ο χρήστης έχει ένα εγγυημένο QoS ή κάποια συγκεκριμένη προτεραιότητα. Σε ένα best effort δίκτυο παρέχεται σε όλους τους χρήστες best effort service, με την έννοια ότι ο καθένας έχει ένα μη καθορισμένο μεταβλητό ρυθμό μετάδοσης και παράδοσης πακέτου, ανάλογα με την κίνηση στο δίκτυο την συγκεκριμένη χρονική στιγμή. Γιατί να σχεδιαστεί ένα πρωτόκολλο αναξιόπιστο; Ο κύριος λόγος για την έλλειψη αξιοπιστίας είναι για να μειωθεί η πολυπλοκότητα των routers. Έτσι οι routers μπορούν να διαχειριστούν όπως θέλουν αυτοί τα πακέτα που τους έρχονται, αν και οτιδήποτε λιγότερο από best effort delivery οδηγεί σε "poor experience" τον τελικό χρήστη. Έτσι, αν και δεν γίνονται εγγυήσεις για τα πακέτα, όσο καλύτερη είναι η προσπάθεια του δικτύου, τόσο καλύτερο το τελικό αποτέλεσμα για τον χρήστη. Τέλος να αναφέρουμε ότι τα περισσότερα πρωτόκολλα είναι βασισμένα στην ιδέα ότι ο έλεγχος σφαλμάτων είναι καλύτερο να γίνεται στην μεριά του τελικού χρήστη, το λεγόμενο end-to-end principle. 12

13 IPv4 vs. IPv6 Στο σημερινό Internet το IP, όπως αυτό υλοποιείται στο Network layer, βρίσκεται στην έκδοση 4 (IPv4) από το 1981! Το IPv6 θα αντικαταστήσει κάποια στιγμή μελλοντικά το IPv4. Η κύρια διαφορά τους είναι στο χώρο των διευθύνσεων που φαίνεται στο παρακάτω σχήμα. Μέγεθος του χώρου διευθύνσεων σε κάθε πρωτόκολλο Πρωτόκολλα TCP, UDP και RTP Ένα επίπεδο πιο πάνω από το IP, στο Transport layer, βρίσκονται το TCP & UDP. Οι software βιβλιοθήκες του TCP και του UDP, χρησιμοποιούν το Internet Protocol (IP) και παρέχουν ένα πιο απλοποιημένο περιβάλλον για να γραφούν δικτυακές εφαρμογές. Ας δούμε το TCP & UDP αναλυτικά παρακάτω. Πρωτόκολλο TCP Τα αρχικά του TCP προέρχονται από το Transmission Control Protocol. Είναι το πρωτόκολλο που χρησιμοποιείται κατεξοχήν στον Internet. Το TCP δημιουργεί μια ατελείωτη σειρά από μηνύματα (segments), τα οποία φαίνονται σαν μια συνεχής ροή δεδομένων. Αυτή η ροή είναι 2 κατευθύνσεων (αποστολέας-παραλήπτης) και ταυτόχρονα πολύ αξιόπιστη. Ας δούμε τα κυριότερα χαρακτηριστικά του TCP: Είναι connection protocol Άρα χρησιμοποιείται μόνο μεταξύ 2 υπολογιστών. Πριν ξεκινήσει η μεταφορά δεδομένων πρέπει να γίνει ένα 3πλό handshaking (SYN, SYN-ACK, ACK) μεταξύ των 2 13

14 υπολογιστών (connection establishment) και το αντίστοιχο στον τερματισμό της αποστολής (connection termination). Είναι αξιόπιστο Το TCP του παραλήπτη ενημερώνει συνεχώς το TCP του αποστολέα, για το πιο είναι το επόμενο πακέτο που περιμένει, σύμφωνα με τον αύξοντα αριθμό των πακέτων που έχει ήδη λάβει και αν αντιληφθεί ότι κάποιο πακέτο χάθηκε στην πορεία, τότε επιβάλλει retransmission. Αν το πακέτο δεν μπορεί να έρθει μετά από πολλαπλά retransmissions, τότε η σύνδεση διακόπτεται (timeout). Εγγυάται την σωστή σειρά άφιξης των δεδομένων στην εφαρμογή του παραλήπτη Όταν τα δεδομένα έρθουν στην είσοδο του παραλήπτη με λάθος σειρά, τότε το TCP layer κρατάει αυτά τα δεδομένα μέχρι να έρθουν τα προηγούμενα τους. Αφού έρθουν τα διατάσσει στην σωστή σειρά και έπειτα τα παραδίδει στην εφαρμογή. Απόρριψη διπλών δεδομένων Αποτρέπει την αποστολή διπλότυπων, δηλαδή δύο ακριβώς ίδιων δεδομένων. Προσφέρει αυτοματοποιημένο έλεγχο ροής δεδομένων (flow control) Όταν ο buffer του παραλήπτη γεμίσει, τότε σταματάει προσωρινά το transmission ή ελαττώνει τον ρυθμό μετάδοσης του, μέχρις ότου αδειάσει ο buffer. Μια απαραίτητη λειτουργία σε ένα κόσμο όπου επικοινωνούν μηχανές διαφορετικών ταχυτήτων κάτω από διαφορετικά δίκτυα. Προσφέρει αυτοματοποιημένο έλεγχο συμφόρησης (congestion control) Το TCP χρησιμοποιεί μια πληθώρα μηχανισμών για να επιτύχει την μέγιστη απόδοση μεταφοράς δεδομένων αποφεύγοντας την συμφόρηση δεδομένων στους routers του Internet, μια κατάσταση κατά την οποία πέφτει η απόδοση του δικτύου κατά μεγάλο βαθμό. Αυτοί οι μηχανισμοί ελέγχουν τον ρυθμό με τον οποίο τα δεδομένα μπαίνουν στο δίκτυο, κρατώντας αυτό το ρυθμό κάτω από ένα ασφαλές όριο. Συγκεκριμένα, ο βασικός αλγόριθμός που χρησιμοποιεί ονομάζεται Congestion Avoidance. Αν και υπάρχουν διάφορες παραλλαγές του, λειτουργεί ως εξής: Το TCP στέλνει δεδομένα στο δίκτυο αυξάνοντας σιγά σιγά ένα congestion window (χρησιμοποιείται για να ελέγχει τον ρυθμό με τον οποίο τα δεδομένα μπαίνουν στο δίκτυο). Όταν παρατηρηθεί συμφόρηση το μέγεθος του congestion window ελαττώνεται στο μισό, ώστε να αποφευχθεί η κατάρρευση του δικτύου και έπειτα από λίγο συνεχίζει 14

15 να μεγαλώνει σιγά σιγά μέχρι να ξαναπαρατηρηθεί συμφόρηση, οπού και θα μειώσει πάλι το μέγεθος του congestion window στο μισό. Εγγυάται την ακεραιότητα του "μονοπατιού επικοινωνίας" Αυτό βέβαια δεν εμποδίζει την υποκλοπή των δεδομένων από τρίτους. Η τελευταία όμως είναι σχετικά δύσκολη, μιας και ο κακόβουλος χρήστης θα πρέπει να ακούσει όλη την ροή δεδομένων, καθώς δεν υπάρχουν συγκεκριμένου μεγέθους πακέτα. Εξαιτίας των παραπάνω χαρακτηριστικών του λοιπόν, το TCP χρησιμοποιείται και επιβάλλεται να χρησιμοποιείται, όπου η ακεραιότητα των δεδομένων είναι ύψιστης σημασίας. Δηλαδή σε web surfing, s, file transfers και οποιαδήποτε άλλη μεταφορά data αρχείων ανάμεσα σε 2 υπολογιστές. Πρωτόκολλο UDP Τα αρχικά του UDP προέρχονται από το User Datagram Protocol. Είναι ένα σχεδόν μηδενικό πρωτόκολλο, με την έννοια ότι, οι μόνες υπηρεσίες που παρέχει είναι το checksum των προς μετάδοση δεδομένων και της πολυπλεξίας των ports επικοινωνίας του υπολογιστή. Για αυτό και πολλές φορές αναφέρεται με το όνομα Unreliable Datagram Protocol! Χρησιμοποιώντας το UDP τα προγράμματα μπορούν να στείλουν μικρά μηνύματα, γνωστά ως datagrams, το ένα στο άλλο. Είναι αναξιόπιστο (best effort delivery) Δε μπορεί να εγγυηθεί την ακεραιότητα ή τη σωστή σειρά άφιξης των δεδομένων, όπως το TCP. Τα πακέτα(datagrams) μπορούν να φτάσουν με διαφορετική σειρά, να εμφανίζονται διπλά ή να μην έρθουν και καθόλου χωρίς καμία ειδοποίηση. Είναι γρήγορο Το παραπάνω χαρακτηριστικό του εξασφαλίζει μικρό delay και κάνει το UDP πιο γρήγορο από το TCP. Πολλαπλή χρηστικότητα Μπορεί να χρησιμοποιηθεί τόσο σε Unicast όσο και σε Multicast δίκτυα, καθώς δεν είναι connection protocol. Θα αναφερθούμε σε αυτά παρακάτω. Είναι ελαφρύ Λιγότερο απαιτητικό σε πόρους, σε σχέση με το TCP. Δεν δημιουργεί μεγάλο overhead στο δίκτυο, καθώς δεν ελέγχει αν όντως κάποιο πακέτο έφτασε ή όχι. 15

16 Έχει μικρότερο header Το UDP έχει 8 bytes header, σε σχέση με το TCP που έχει 20 bytes header. Αυτό σημαίνει μικρότερο έξτρα overhead στο δίκτυο. TCP vs. UDP Στον πίνακα που ακολουθεί βλέπουμε συνοπτικά τις βασικές διαφορές των δύο πρωτοκόλλων που περιγράψαμε προηγουμένως: UDP & TCP Comparison Table UDP TCP Packet header size 8 Bytes 20 Bytes Transport layer packet entity Datagram Segment Port numbering Yes Yes Error detection Optional Yes Reliability: Error recovery by automatic repeat request (ARQ) No Yes Virtual circuits: Sequence numbering and reordering No Yes Flow control No Yes Congestion avoidance: Variable congestion window, slow start, time outs No Yes Multiple streams No No ECN support No Yes Γιατί υπάρχει το UDP; Τι εξυπηρετεί; Το TCP λοιπόν, σύμφωνα με όσο αναφέραμε παραπάνω, φαντάζει σαν μια ιδανική λύση για την σωστή και αξιόπιστη κυρίως μεταφορά των δεδομένων μας. Γιατί χρησιμοποιούμε το UDP; Το UDP υπάρχει ακριβώς γιατί υπάρχουν εφαρμογές, όπου δεν μας ενδιαφέρει τόσο η ακεραιότητα των δεδομένων, όσο τα δεδομένα να φτάσουν όσο δυνατόν γρηγορότερα στον παραλήπτη, έστω και με κάποια απώλεια. Εκεί δηλαδή που το TCP είναι αργό και δεν μας εξυπηρετεί, έρχεται να πάρει τη θέση του το UDP. Μερικές εφαρμογές που χρησιμοποιούν το UDP είναι οι παρακάτω: Εφαρμογές οι οποίες μεταδίδουν real-time audio/video, όπως IPTV, VoIP. Εδώ μας ενδιαφέρει τα δεδομένα να φτάνουν την σωστή χρονική στιγμή. Οποιαδήποτε απώλεια τους μας επηρεάζει μόνο στην ποιότητα του αναπαραγόμενου σήματος. 16

17 Servers, οι οποίοι απαντάνε σε μικρά αιτήματα ενός τεράστιου αριθμού από clients, όπως στα online παιχνίδια. Οι Servers δεν απασχολούνται με το να ελέγχουν την κατάσταση του κάθε connection και των παραμέτρων του χρησιμοποιώντας UDP, και έτσι μπορούν να εξυπηρετήσουν ένα πολύ μεγαλύτερο αριθμό χρηστών σε αντίθεση με το αν χρησιμοποιούσαν TCP. Όπως επίσης και κάποιες πολύ σημαντικές εφαρμογές όπως το Domain Name System(DNS), Simple Network Management Protocol(SNMP), Dynamic Host Configuration Protocol(DHCP), Routing Information Protocol(RIP). Μετά από όλα αυτά, είναι φανερό ότι ένα πρόγραμμα που χρησιμοποιεί το πρωτόκολλο UDP πρέπει να ασχοληθεί το ίδιο με τα προβλήματα επικοινωνίας που μπορεί να προκύψουν: την αξιόπιστη παράδοση, το packetization και την επανασυναρμολόγηση, τον έλεγχο ροής, την αποφυγή συμφόρησης, κλπ. Επίσης, δεδομένου ότι το UDP στερείται μηχανισμών αποφυγής και ελέγχου δικτυακής συμφόρησης, απαιτούνται network-based μηχανισμοί για να ελαχιστοποιηθούν τα πιθανά προβλήματα κατάρρευσης δικτύου λόγω ανεξέλεγκτα υψηλών ρυθμών αποστολής πακέτων UDP. Με άλλα λόγια, δεδομένου ότι οι αποστολείς UDP δεν μπορούν να ανιχνεύσουν τη συμφόρηση, τα στοιχεία των δικτύων, όπως οι routers, πρέπει να χρησιμοποιούν τεχνικές packet queuing και απόρριψης πακέτων για να ελέγχουν την υπερβολική κίνηση πακέτων UDP στα δίκτυα. Το Datagram Congestion Control Protocol (DCCP) σχεδιάζεται ως μια μερική λύση σε αυτό το πιθανό πρόβλημα προσθέτοντας TCP μηχανισμούς ελέγχου συμφόρησης σε ροές πακέτων UDP υψηλής ταχύτητας (π.χ. media streaming). Πρωτόκολλο RTP Το Real-time Transport Protocol (RTP) καθορίζει ένα τυποποιημένο format πακέτου για αποστολή ήχου/βίντεο μέσω του internet. Μπορεί να δουλέψει παράλληλα με το Real-time Streaming Protocol (RTSP) το οποίο επιτρέπει τον απομακρυσμένο έλεγχο ενός media server με εντολές παρόμοιες ενός βίντεο. Μερικές από τις εντολές που παρέχει το RTSP είναι το Describe, Setup, Play, Pause, Record και Teardown. Οι εντολές αυτές αφορούν την περιγραφή του αρχείου προς μετάδοση, τον έλεγχο της αναπαραγωγής και τον τερματισμό της συνόδου με τον server. Όλες αυτές οι εντολές στέλνονται με το πρωτόκολλο HTTP. Το RTP δεν έχει κάποια συγκεκριμένη TCP/UDP πόρτα από την οποία επικοινωνεί. Το μόνο στο οποίο υπακούει είναι ότι οι UDP επικοινωνίες γίνονται σε ζυγές πόρτες και η αμέσως επόμενη μονή πόρτα να χρησιμοποιείται για το RTP Control Protocol (RTCP). Το τελευταίο δίνει περιοδικά feedback για το quality of service που παρέχει το RTP. Μαζεύει στατιστικά, όπως τα πακέτα που στάλθηκαν, τα χαμένα πακέτα, το jitter και το round trip delay. Μια εφαρμογή μπορεί να τα χρησιμοποιήσει για να αυξήσει το quality of service, ίσως μειώνοντας την ροή πληροφορίας ή χρησιμοποιώντας διαφορετικό codec. 17

18 Το RTP λοιπόν είναι κατάλληλο να χρησιμοποιηθεί για δεδομένα με real-time χαρακτηριστικά, όπως το interactive audio και video. Επίσης το χρησιμοποιούν υπηρεσίες VoIP στις οποίες το call setup και ο τερματισμός του, γίνεται χρησιμοποιώντας άλλα 2 πρωτόκολλα είτε το SIP είτε το H.323. Οι υπηρεσίες που παρέχει το RTP είναι οι παρακάτω: Ένδειξη του τι είδους περιεχόμενο μεταφέρεται Αρίθμηση πακέτων Δυνατότητα υπολογισμού του jitter Παρακολούθηση της διαδικασίας αποστολής. ΔΕΝ παρέχει flow & congestion control από μόνο του. Επίσης το RTCP προσφέρει πληροφορία σχετικά με την λαμβανόμενη ποιότητα, την οποία μπορεί να χρησιμοποιήσει η εφαρμογή για να κάνει τοπικές αλλαγές, όπως να αποφασίσει σε περίπτωση συμφόρησης να μειώσει τον ρυθμό αποστολής. Μέθοδοι δρομολόγησης (Routing Schemes) Υπάρχουν 4 μέθοδοι δρομολόγησης/αποστολής ή αλλιώς Routing Schemes, το καθένα με τα δικά του μοναδικά χαρακτηριστικά. Είναι, με τη σειρά που παρουσιάζονται, το Unicast, το Broadcast, το Multicast και το Anycast. Οι ορολογίες αυτές αναφέρονται και στον τύπο των διευθύνσεων IP που χρησιμοποιούνται. Unicast Ο πιο συνηθισμένος τύπος για μια IP διεύθυνση είναι μια unicast διεύθυνση και είναι ο πιο διαδεδομένος τρόπος μετάδοσης πληροφορίας στο σημερινό Internet. Συνήθως αναφέρεται σε έναν μεμονωμένο αποστολέα ή παραλήπτη και μπορεί να χρησιμοποιηθεί τόσο για αποστολή όσο και παραλαβή. Συνήθως μια unicast διεύθυνση αντιστοιχίζεται με μια μόνο συσκευή, αλλά αυτό δεν σημαίνει ότι υπάρχει αντιστοιχία 1-1. Ορισμένοι υπολογιστές έχουν πολλές διαφορετικές unicast διευθύνσεις, η κάθε μια για την δικιά της ξεχωριστή χρήση. Στέλνοντας την ίδια πληροφορία σε διαφορετικές unicast διευθύνσεις, απαιτεί από τον αποστολέα να στείλει την ίδια πληροφορία τόσες φορές όσες και οι παραλήπτες του. Στην unicast δρομολόγηση κάθε router εξετάζει το destination address του λαμβανόμενου πακέτου και ψάχνει αυτήν την διεύθυνση σε έναν πίνακα, ώστε να προσδιορίσει ποια διασύνδεση να χρησιμοποιήσει ώστε το πακέτο να φτάσει πιο κοντά στον προορισμό του. Η source address του πακέτου δεν παίζει κανένα ρόλο. 18

19 Γραφική απεικόνιση του Unicast Broadcast Το broadcast, στέλνοντας την πληροφορία σε όλους τις πιθανούς προορισμούς, δίνει τη δυνατότητα στον αποστολέα, να στείλει την πληροφορία μόνο μια φορά και όλοι οι παραλήπτες να την πάρουν. Στο IP πρωτόκολλο, η διεύθυνση παριστάνει ένα περιορισμένο τοπικό broadcast. Για παράδειγμα, το να στείλεις σε όλες τις διευθύνσεις σε ένα τοπικό δίκτυο που αρχίζουν με , η directed broadcast διεύθυνση είναι (υποθέτοντας ότι το netmask είναι ). Δυστυχώς δεν υπάρχει καμία μορφή internet-wide broadcast και είναι περιορισμένο σαν τεχνολογία μόνο στα τοπικά Ethernet δίκτυα. Στο IPv6 το broadcast δεν υφίσταται σε καμία μορφή και έχει δώσει την θέση του στο multicasting. Γραφική απεικόνιση του Broadcast Multicast Μια multicast διεύθυνση αντιστοιχίζεται με ένα group από ενδιαφερόμενους χρήστες. Σύμφωνα με το RFC3171 της IANA (Internet Assigned Numbers Authority), οι διευθύνσεις μέχρι είναι ορισμένες ως multicast διευθύνσεις. Αυτές οι διευθύνσεις ήταν γνωστές παλαιότερα και με την ονομασία Class D. Ο αποστολέας στέλνει ένα datagram 19

20 UDP πακέτο από την unicast διεύθυνση του, στην multicast διεύθυνση και οι routers αναλαμβάνουν να κάνουν αντίγραφα του πακέτου μόνο όταν χρειάζεται και να το στείλουν σε όσους παραλήπτες δήλωσαν ενδιαφέρον για το συγκεκριμένο πακέτο από τον συγκεκριμένο αποστολέα. Δεν απαιτείται προηγούμενη γνώση για το ποιοι ή πόσοι παραλήπτες υπάρχουν στο δίκτυο. Κάθε υπολογιστής (στην ουσία κάθε εφαρμογή του υπολογιστή) που θέλει να λάβει πληροφορία από ένα multicast group, πρέπει να χρησιμοποιήσει το IGMP για να πάρει μέρος. Τα ενδιάμεσα routers πρέπει κι αυτά να χρησιμοποιούν το IGMP για να επικοινωνήσουν. Σε αντίθεση με τη unicast δρομολόγηση που αναφέραμε παραπάνω, η source address (που είναι μια απλή unicast διεύθυνση) χρησιμοποιείται για να προσδιορίσει την κατεύθυνση του data stream. H πηγή του multicast traffic θεωρείται σαν upstream. Το router προσδιορίζει ποιες downstream διασυνδέσεις είναι προορισμοί για αυτό το multicast group και στέλνει το πακέτο μέσω των κατάλληλων διασυνδέσεων. Ο όρος reverse path forwarding χρησιμοποιείται για να περιγράψει αυτό το είδος της δρομολόγησης. Δηλαδή, το να δρομολογείς πακέτα μακριά από την πηγή, παρά κοντά προς τον προορισμό. Τέλος, όπως αναφέρει και ο Internet architect Dave Clark για το multicast: "Βάζεις πακέτα στην μια άκρη, και το δίκτυο συνωμοτεί να τα μεταφέρει σε όποιον τα ζητήσει". Γραφική απεικόνιση του Multicast Anycast Όπως το broadcast και το multicast, έτσι και το anycast είναι μια-προς-πολλούς τοπολογία. Η διαφορά του είναι ότι η πληροφορία δεν μεταδίδεται σε όλους τους παραλήπτες, αλλά μόνο σε αυτόν που o router θα αποφασίσει ότι είναι πιο κοντά στον αποστολέα. Δηλαδή στο anycast κάθε διεύθυνση αντιστοιχίζεται με ένα σύνολο παραληπτών, όπως στο multicast και το broadcast, αλλά μόνο ένας από αυτούς επιλέγεται σε μια δεδομένη στιγμή για να πάρει πληροφορία από τον εκάστοτε αποστολέα. Το anycast είναι πολύ χρήσιμο για να εξισορροπεί μεταβολές στον φόρτο του δικτύου. Χρησιμοποιείται κυρίως στο DNS και στο UDP. 20

21 Γραφική απεικόνιση του Anycast Δίκτυα Ομότιμων Κόμβων (Peer-to-Peer Networks) Ένα Peer-to-Peer (P2P) δίκτυο υπολογιστών ή ένα δίκτυο ομότιμων τερματικών χρησιμοποιεί πολλαπλή συνδεσιμότητα μεταξύ των συμμετεχόντων στο δίκτυο και το αθροιστικό τους bandwidth, σε αντίθεση με το παραδοσιακό μοντέλο όπου ένας μικρός αριθμός servers παρέχει τους υπολογιστικούς του πόρους για την παροχή υπηρεσιών. Ένα τέτοιο δίκτυο μπορούμε να το χρησιμοποιήσουμε τόσο για μεταφορά αρχείων (file sharing) αλλά και για μεταφορά real-time data (telephony traffic). Σε ένα "καθαρό" P2P δίκτυο δεν υπάρχει η έννοια του client ή του server, παρά μόνο υπάρχουν ισοδύναμοι Peers, οι λεγόμενοι nodes, οι οποίοι συμπεριφέρονται ταυτόχρονα σαν clients και servers για τους άλλους nodes του δικτύου. Βλέπουμε τη διαφορά των δύο εννοιών γραφικά στις παρακάτω εικόνες. Τοπολογίες μοντέλων Peer-to-Peer και Server-Client 21

22 Σύμφωνα με τα λεγόμενα των προγραμματιστών της δημοφιλούς εφαρμογής Skype, ένα "πραγματικό" P2P σύστημα, είναι αυτό όπου όλοι οι nodes συμμετέχουν δυναμικά στη δρομολόγηση των πακέτων, την επεξεργασία τους και σε διαδικασίες που απαιτούν μεγάλο bandwidth και οι οποίες θα γίνονταν διαφορετικά σε κεντρικούς servers. Συγκεντρωμένα P2P δίκτυα Πολλοί, όταν αναφέρονται σε αυτά, χρησιμοποιούν τη φράση πρώτης γενιάς P2P δίκτυα. Εδώ υπάρχει ένας κεντρικός Index Server στον οποίο αποθηκεύονται οι πληροφορίες για τα περιεχόμενα των καταλόγων που οι συμμετέχοντες επιθυμούν να μοιράζονται. Οι χρήστες μπορούν να αναζητήσουν στους Index Servers αυτούς τα αρχεία που ψάχνουν, χρησιμοποιώντας ένα κατάλληλο πρόγραμμα-πελάτη. Όταν το αρχείο βρεθεί, ανοίγει μια σύνδεση μεταξύ των δύο χρηστών για τη μεταφορά του. Σε αυτή τη κατηγορία ανήκουν το Napster, το DC++ και το WinMX. Αποκεντρωμένα P2P δίκτυα Η φιλοσοφία εδώ είναι εντελώς διαφορετική. Κάθε σύστημα που συμμετέχει αποτελεί ταυτόχρονα client και server (ή αλλιώς servent). Μόλις κάποιος συνδεθεί μέσω ενός ανάλογου προγράμματος-πελάτη P2P, κάνει γνωστή την παρουσία του σε ένα μικρό αριθμό υπολογιστών ήδη συνδεδεμένων οι οποίοι με τη σειρά τους προωθούν τη δήλωση παρουσίας του σε ένα μεγαλύτερο δίκτυο υπολογιστών κλπ. Πλέον ο χρήστης έχει τη δυνατότητα να αναζητήσει οποιαδήποτε πληροφορία μεταξύ των διαμοιραζόμενων αρχείων. Τα δίκτυα αυτά λέγονται και δεύτερης γενιάς. Η μεταφορά των αρχείων είναι όμοια με αυτή των αποκεντρωτικών P2P δικτύων. Σε αυτή τη κατηγορία ανήκουν το Kazaa, το Gnutella και το BearShare. P2P δίκτυα τρίτης γενιάς Είναι αυτά, τα οποία διαθέτουν χαρακτηριστικά ανωνυμίας, όπως το Freenet, το I2P και το Entropy. Είναι αποκεντρωτικού τύπου και η φιλοσοφία του βασίζεται εκτός από την ανωνυμία, στην υψηλή βιωσιμότητα του, στο συνεχή διαμοιρασμό των αρχείων και στην κωδικοποίησή τους έτσι ώστε κανείς να μην μπορέσει ποτέ να αποκτήσει κανένα είδος ελέγχου πάνω σε αυτό. Τα δίκτυα αυτού του τύπου είναι υπό ανάπτυξη και έχουν χαρακτηριστεί ως μικρά παγκόσμια δίκτυα. Άλλα P2P δίκτυα Αν και αυτές που περιγράψαμε παραπάνω είναι οι 3 βασικές κατηγορίες, υπάρχουν και διάφορες άλλες. Έτσι, εκτός από τα pure P2P δίκτυα έχουμε τα υβριδικά δίκτυα, τα οποία έχουν 22

23 έναν κεντρικό server που κρατάει πληροφορίες για τους Peers. Οι Peers αναλαμβάνουν να πληροφορήσουν τον Server για το τι πόρους θέλουν να μοιράσουν στο δίκτυο. Από εκεί και πέρα, στην σύνδεση μεταξύ των peers, ο server δεν έχει κανέναν άλλο ρόλο. Σε αυτήν την κατηγορία ανήκει και το δίκτυο που αναπτύξαμε για τις ανάγκες της διπλωματικής. Άλλες δυο ενδιαφέρουσες κατηγορίες τις οποίες απλώς τις αναφέρουμε ονομαστικά είναι τα structured και τα unstructured P2P δίκτυα. Η ανάλυσή τους ξεφεύγει από τα πλαίσια της διπλωματικής, γι αυτό και γίνεται απλή αναφορά σ αυτές για λόγους συνέπειας και ως έναυσμα για περαιτέρω μελέτη από τον αναγνώστη. Κωδικοποίηση Πολλαπλών Περιγραφών (MDC) Όταν 2 υπολογιστές χρησιμοποιούν το πρωτόκολλο TCP για να επικοινωνήσουν, ο παραλήπτης πρέπει να περιμένει ολόκληρη την πληροφορία να έρθει για να μπορέσει να την επεξεργαστεί. Όταν συμβεί μια απώλεια πακέτου, η ανακατασκευή του stream θα σταματήσει μέχρι να ξανάρθει το χαμένο πακέτο. Αυτό εισάγει σημαντική καθυστέρηση στην εφαρμογή του παραλήπτη, μιας και ο χρόνος που θα κάνει το χαμένο πακέτο να επανασταλεί στον παραλήπτη μπορεί να είναι πολύ μεγαλύτερος από τον χρόνο δυο διαδοχικών πακέτων. Έτσι, όπως έχουμε αναφέρει προτιμάται το UDP για την μεταφορά ήχου σε πραγματικό χρόνο, έστω και με κάποιες απώλειες. Θα δούμε λοιπόν μια τεχνική κωδικοποίησης η οποία χρησιμοποιείται σε δίκτυα τα οποία χρησιμοποιούν το UDP σαν πρωτόκολλο μεταφοράς και λέγεται Multiple Description Coding (MDC). Το MDC είναι μια τεχνική κωδικοποίησης, η οποία χωρίζει ένα media stream σε n ( n>=2) ανεξάρτητα substreams. Αυτά τα substreams λέγονται descriptions. Κάθε description είναι συνήθως διαφορετικής ποιότητας από το προηγούμενο. Έτσι υπάρχει ένα description το οποίο προσφέρει μια βασική ποιότητα και τα υπόλοιπα μια enhanced ποιότητα. Καθώς στην ουσία πρόκειται για ένα τρόπο διαχωρισμού των δεδομένων, είναι συγκρίσιμος με το layered coding που χρησιμοποιείται στο MPEG2 και MPEG4. Εκεί συνήθως υπάρχει ένα base layer το οποίο έχει την βασική ποιότητα και πολλά enhancement layers. Το base layer είναι απαραίτητο για να αποκωδικοποιηθεί σωστά το media stream, ενώ τα enhancement layers εφαρμόζονται για να βελτιωθεί η ποιότητα. Ωστόσο, αν λείπει το n layer, όλα τα n+1 layers καθίστανται άχρηστα, καθώς το καθένα εξαρτάται από το προηγούμενο του για την αποκωδικοποίησή του. Αντίθετα, στο MDC κάθε description είναι ανεξάρτητο από το άλλο με την έννοια ότι μπορεί να αποκωδικοποιηθεί και να αναπαραχθεί χωρίς την ύπαρξη των προηγούμενων ή επόμενων του descriptions. Αυτό κάνει το MDC κατάλληλο για χρήση σε δίκτυα που παρουσιάζουν packet loss ή network congestion. Μπορούμε να δρομολογήσουμε κάθε description από διαφορετικές 23

24 διαδρομές (path diversity) μέχρι να φτάσει στον παραλήπτη. Σε περίπτωση που σε μια διαδρομή παρατηρηθεί congestion, η αποκωδικοποίηση του stream δεν θα σταματήσει στην πλευρά του παραλήπτη, παρά θα παρατηρηθεί μια στιγμιαία υποβάθμιση της ποιότητας. Κοινώς, η ποιότητα που θα λαμβάνει ο παραλήπτης θα είναι ανάλογη των descriptions που λαμβάνει παράλληλα. Το ίδιο το path diversity μας εξασφαλίζει ότι η πιθανότητα να έχει προκληθεί σε όλες τις διαδρομές συμφόρηση είναι πολύ μικρή. Εκτός από την ανοχή στα χαμένα πακέτα που προσφέρει, το ΜDC είναι μια πολύ καλή τεχνική και για αυτούς που παρέχουν το υλικό. Οι providers, λοιπόν, μπορούν να στέλνουν όλα τα descriptions ενός stream χωρίς να τους νοιάζει ο περιορισμός του download του εκάστοτε χρήστη. Οι χρήστες που δεν μπορούν να αντεπεξέλθουν στον ρυθμό μετάδοσης παίρνουν ένα υποσύνολο από αυτά τα descriptions, ελευθερώνοντας τον provider από το να παρέχει επιπλέον streams σε μικρότερους ρυθμούς. Σαν γενικό κανόνα μπορούμε να πούμε το παρακάτω: + => ύ h h + ή ή έ έ Μιας λοιπόν και το MDC είναι μια τεχνική κωδικοποίησης ενός stream, θα δούμε παρακάτω ορισμένες τεχνικές με τις οποίες μπορούμε να φτιάξουμε αποτελεσματικά descriptions από αυτό. Προτού όμως προχωρήσουμε σε αυτές ας δούμε λίγα πράγματα για την διαδικασία που ονομάζουμε κβαντισμό. Κβαντισμός Στην ψηφιακή επεξεργασία σήματος, ο κβαντισμός είναι η διαδικασία κατά την οποία υπολογίζουμε μια συνεχή σειρά τιμών (ή ένα μεγάλο σετ από πιθανές διακριτές τιμές) από ένα σχετικά μικρό σετ διακριτών συμβόλων ή ακεραίων αριθμών. Προφανώς, ο κβαντισμός είναι μια διαδικασία εκτίμησης των τιμών και συνεπώς ένας καλός κβαντιστής είναι αυτός ο οποίος μπορεί να αναπαραστήσει το αρχικό σήμα με τον μικρότερο δυνατό θόρυβο. Μια συχνή χρήση του κβαντισμού είναι η μετατροπή ενός δειγματοληπτημένου συνεχούς σήματος σε ένα ψηφιακό, με κβαντισμό. Οι λεγόμενοι analog-to-digital converters (ADC) εφαρμόζουν κβαντισμό για να μετατρέψουν μια πηγή ήχου π.χ. σε format cd audio που είναι δειγματοληπτημένο με δείγματα/sec και κάθε δείγμα κβαντισμένο με 16bits ή πιθανές τιμές ανά δείγμα. Αυτά τα 16 bits είναι το λεγόμενο step size του κβαντιστή. Ο προσαρμοσμένος κβαντισμός, είναι μια διαδικασία κβαντισμού κατά την οποία το step size του κβαντιστή μεταβάλλεται ανάλογα με τις μεταβολές του σήματος εισόδου, σε μια προσπάθεια για μια πιο αποτελεσματική συμπίεση. Υπάρχουν δύο κύριοι τύποι κβαντισμού. Ο απλός κβαντισμός, όπως συχνά αναφέρεται, και ο διανυσματικός. Στον απλό κβαντισμό, κάθε σύμβολο εισόδου αντιμετωπίζεται ξεχωριστά για να παραχθεί η έξοδος, ενώ στον διανυσματικό κβαντισμό τα σύμβολα εισόδου μαζεύονται μαζί σε groups, τα λεγόμενα διανύσματα, και αυτά τα διανύσματα επεξεργάζονται για να βρεθεί η έξοδος. Σε γενικές γραμμές ένας απλός κβαντιστής μπορεί να αναπαρασταθεί με: 24

25 = όπου x είναι ο πραγματικός αριθμός που θα κβαντιστεί και η η βασική συνάρτηση, η οποία θα δώσει ένα ακέραιο αποτέλεσμα =[ ], που καλείται quantization index. Το και το είναι αυθαίρετες συναρτήσεις. Επίσης ένα κβαντιστής χαρακτηρίζεται από το πως χωρίζει τα σύμβολα εισόδου του, όπως και τα επίπεδα εξόδου του. Αν η είσοδος του χωρίζεται σε ίσου μήκους διαστήματα, τότε είναι ένας ομοιόμορφος κβαντιστής, αλλιώς ένας ανομοιόμορφος. Ένας ομοιόμορφος κβαντιστής είναι πιο εύκολο να υλοποιηθεί και μπορεί να οριστεί εύκολα από το κατώτερο όριο του και το step size του. Παρακάτω φαίνεται ένα παράδειγμα ενός ομοιόμορφου κβαντιστή. Αν η είσοδος είναι ανάμεσα στο και στο +1, τότε η έξοδος του κβαντιστή είναι το σύμβολο. Speech Coding for Channel Splitting Ένας απλός, αλλά αρκετά αποτελεσματικός τρόπος να έχουμε 2 ξεχωριστά descriptions είναι αυτός που παρουσιάζεται στην παρακάτω εικόνα. Αξίζει να σημειωθεί ότι αυτή είναι και η μέθοδος που χρησιμοποιήσαμε στην εφαρμογή μας, ελάχιστα τροποποιημένη, με πολύ καλά αποτελέσματα όπως θα δούμε παρακάτω. Η αρχική πηγή ήχου χωρίζεται σε μονά/ζυγά δείγματα. Κάθε ομάδα δειγμάτων κωδικοποιείται ξεχωριστά με έναν DPCM encoder και στέλνεται το κάθε ένα σε διαφορετικό κανάλι. Το να αποκωδικοποιήσεις τον ήχο και από τα 2 κανάλια απαιτεί ένα DPCM decoder σε κάθε κανάλι και παρεμβολή των δειγμάτων, δημιουργώντας ένα σήμα σαν το αρχικό με κάποιο ποσοστό θορύβου από την κβάντιση του DPCM. Για να αποκωδικοποιήσουμε κάθε κανάλι ξεχωριστά χρησιμοποιείται προσαρμοσμένη γραμμική παρεμβολή. Κρίνοντας τόσο από το SNR, όσο και από το ακουστικό τεστ, αυτή η τεχνική δουλεύει πολύ καλά για 2-5 bits/sample (24 έως 60 Kbit/sec). H ποιότητα του μισού σήματος για ένα 25

26 σύστημα σχεδιασμένο για συνολικό ρυθμό R, είναι ίδια με αυτήν ενός ολόκληρου σήματος ρυθμού R για ένα σύστημα σχεδιασμένο για ρυθμό R/2. Ή διαφορετικά, ο half-rate αποκωδικοποιητής που λαμβάνει τα μονά δείγματα βάζει το ίδιο distortion (παραμόρφωση) σε αυτά τα δείγματα, όσο και ο full-rate αποκωδικοποιητής. Είναι σημαντικό ότι τα μονά και ζυγά δείγματα έχουν πλεονασμό με μορφή συσχέτισης μεταξύ των δειγμάτων ή μνήμης, που υπάρχει ήδη στην αρχική πηγή. Αν ο πλεονασμός είχε αφαιρεθεί πριν τον διαχωρισμό των δειγμάτων σε μονά/ζυγά, για παράδειγμα με γραμμική παρεμβολή, η απόδοση θα ήταν απογοητευτική. Φυσικά με αυτή την τεχνική μπορούμε να διασπάσουμε το αρχικό stream σε όσο substreams θέλουμε, προσέχοντας πάντα να υπάρχει πλεονασμός στην πηγή. Για να δούμε την δυσκολία που έχει η διάσπαση μιας πηγής που δεν έχει πλεονασμό σε διάφορα substreams, ας εξετάσουμε το ακόλουθο παράδειγμα. Έστω ότι θέλουμε να μεταδώσουμε έναν πραγματικό αριθμό x[-1,1] με 4bits. Με όποιον τρόπο και να σπάσουμε τα 4 bits σε 2 ζευγάρια και να τα μεταδώσουμε μέσω 2 καναλιών, τα αποτελέσματα θα είναι απογοητευτικά. Οποιαδήποτε εκτίμηση που θα υπολογιστεί από το κανάλι που δεν λαμβάνει το πιο σημαντικό bit, κατά μέσο όρο, δεν θα είναι καλή. Και αυτό γιατί τα 4 bits δεν έχουν πλεονασμό, με την έννοια ότι δεν συσχετίζονται μεταξύ τους. q(x) x Τα μοντέρνα συστήματα κωδικοποίησης από την άλλη, τείνουν να εξαλείψουν τον πλεονασμό είτε με πρόβλεψη των επόμενων δειγμάτων είτε με μετασχηματισμούς αποσυσχέτισης. Ένας διαχωρισμός σε μονά/ζυγά στους συντελεστές μετασχηματισμού δεν είναι αποτελεσματικός. Χρειαζόμαστε λοιπόν τεχνικές για δημιουργία descriptions οι οποίες θα αποδίδουν σωστά και σε πηγές που δεν έχουν μνήμη (memoryless sources). Κάποιες από αυτές τις τεχνικές θα δούμε παρακάτω. Progressive Coding & Unequal Error Protection Ένας τετριμμένος τρόπος για να στείλουμε 2 descriptions είναι να στείλουμε το ίδιο description 2 φορές. Το description θα αναπαραχθεί με την καλύτερη διαθέσιμη τεχνική 26

27 αποκωδικοποίησης. Όταν μόνο 1 description ληφθεί, η ποιότητα εξακολουθεί να είναι μέγιστη, παρόλο αυτά δεν υπάρχει κανένα όφελος αν ληφθούν και τα 2 descriptions. Το μόνο όφελος είναι ότι διπλασιάζεται η πιθανότητα να ληφθεί επιτυχώς το description. Μια πιο έξυπνη τεχνική είναι να επαναλάβεις μόνο ένα μέρος της πληροφορίας. Θα ήταν ωραίο αν η επαναλαμβανόμενη πληροφορία ήταν και η πιο σημαντική, καθώς με αυτόν τον τρόπο αυτή η επιμέρους επαναλαμβανόμενη πληροφορία θα ταίριαζε με το progressive source coding. Για να δημιουργηθούν 2 R-bit descriptions, πρώτα κωδικοποιούμε την πηγή με έναν progressive code με ρυθμό (2-ζ) R όπου ζ [0,1]. Τα πρώτα ζ R bits είναι και τα πιο σημαντικά και είναι αυτά που επαναλαμβάνονται και στα 2 descriptions. Τα υπόλοιπα 2(1-ζ) R bits μπορούν να διαμοιραστούν στα 2 descriptions όπως φαίνεται παρακάτω: Στον πίνακα βλέπουμε ότι έχει προστεθεί πλεονασμός (το ζ R) εξαιτίας της επανάληψης. Επειδή κάποια bits είναι προστατευμένα λόγω της επανάληψης με ένα ρυθμό κωδικοποίησης ½ σε σχέση με τον αυτόν του καναλιού και κάποια άλλα όχι, αυτό ονομάζεται unequal error protection (UEP), στρατηγική για κωδικοποίηση πολλαπλών περιγραφών. Η χρήση του UEP μπορεί να γενικευθεί και σε περισσότερα των 2 descriptions. Για να παραχθούν L descriptions, χρησιμοποιούμε κωδικοποίηση σε κάθε κανάλι με ρυθμούς 1/L, 2/L,, 1 αντίστοιχα. Αυτό φαίνεται στο παρακάτω σχήμα: Η κύρια δυσκολία στο UEP είναι να αποφασίσουμε πόση πληροφορία θα κωδικοποιήσουμε και σε τι ρυθμό ανά κανάλι. Κλείνοντας, να πούμε ότι η κωδικοποίηση με MD είναι δύσκολη, εξαιτίας των αντικρουόμενων απαιτήσεων της. Αν υλοποιήσουμε ένα καλό description με ρυθμό R1 για να το στείλουμε από το κανάλι 1 και άλλο ένα καλό description με ρυθμό R2 για να το στείλουμε από το κανάλι 2, δεν σημαίνει ότι είναι και σωστό, να ξοδέψουμε R1+R2 συνολικά bits για να στείλουμε 2 καλές περιγραφές, όταν από μόνη της η μια προσφέρει καλό αποτέλεσμα. Όμοια, μια πηγή με μεγάλη συμπίεση σε ρυθμό R1+R2, δύσκολα μπορεί να σπαστεί σε δυο χρήσιμες 27

28 περιγραφές. Κατασκευάζοντας descriptions τα οποία είναι το κάθε ένα καλό, άλλα όχι τόσο ίδια, είναι το θεμελιώδες trade-off που εισάγει η χρήση της MD κωδικοποίησης. Τεχνικές Ανακατασκευής Πακέτων Όπως αναφέραμε και παραπάνω, το UDP είναι ένα best effort πρωτόκολλο. Έτσι, κατά τη μετάδοση πακέτων από έναν υπολογιστή σε έναν άλλο, θα υπάρξουν χαμένα πακέτα. Κύριος λόγος των χαμένων πακέτων είναι η συμφόρηση που προκαλείται στα ενδιάμεσα routers του δικτύου. Η συμφόρηση μπορεί να δημιουργηθεί για 2 εντελώς διαφορετικούς λόγους: 1. Όταν ένας υπολογιστής έχει την ικανότητα να δημιουργεί πακέτα γρηγορότερα από ότι μπορεί το δίκτυο να τα μεταφέρει. 2. Όταν πολλοί υπολογιστές χρειαστεί ταυτόχρονα να στείλουν datagrams μέσα από έναν router, τότε σε αυτό το router μπορεί να προκληθεί συμφόρηση. Έχουν λοιπόν δημιουργηθεί διάφορες τεχνικές με τις οποίες μπορούμε να ανακατασκευάσουμε τα χαμένα πακέτα και τις χρησιμοποιούμε σε περιπτώσεις που είμαστε αναγκασμένοι λόγω της φύσης της εφαρμογής να χρησιμοποιήσουμε UDP, αλλά δεν μπορούμε να ανεχθούμε μεγάλο packet loss. Αυτές οι τεχνικές χωρίζονται σε 2 μεγάλες κατηγορίες. Σε αυτές που εφαρμόζονται στην πλευρά του αποστολέα και σε αυτές που εφαρμόζονται στην πλευρά του παραλήπτη. Είναι συμπληρωματικές τεχνικές και καλό είναι να χρησιμοποιούνται μαζί για μέγιστη απόδοση. Διόρθωση στην πλευρά του αποστολέα Συνοπτικά βλέπουμε τους τρόπους αντιμετώπισης της συμφόρησης στην πλευρά του αποστολέα στην παρακάτω εικόνα. Retransmission Η επαναποστολή, σαν μέθοδος ανακατασκευής των χαμένων πακέτων, δεν ενδείκνυται για real-time εφαρμογές. Παρόλα αυτά είναι δυνατή η εφαρμογή της, όταν το round trip delay 28

29 είναι μικρό, ο αριθμός των χαμένων πακέτων μικρός και υπάρχει και κάποιος buffer από τον οποίο παίζονται τα δεδομένα, ο οποίος θα αυξήσει τον διαθέσιμο για επαναποστολή χρόνο. Γενικά σαν μέθοδος είναι πολύ ελκυστική για την ευκολία υλοποίησής της. Το πρόβλημα που θα δημιουργηθεί αν υπάρχει συμφόρηση και συγχρόνως επαναποστολή πακέτων μπορούμε εν μέρει να το λύσουμε, αν εξαρχής δώσουμε λίγο έξτρα bandwidth για περιπτώσεις επαναποστολής ή αν το κομμάτι audio/video που γίνεται retransmitted, κωδικοποιείται με μικρότερο bit rate. Interleaving Το interleaving είναι μια τεχνική κατά την οποία "σπάμε" ένα πακέτο σε μικρότερο κομμάτια και αυτά τα κομμάτια τα ανακατανέμουμε με άλλη σειρά, ώστε να δημιουργηθούν νέα πακέτα. Αυτά τα νέα πακέτα είναι που στέλνονται από τον αποστολέα. O παραλήπτης, καθώς τα λαμβάνει, ανακατανέμει στην αρχική τους σειρά τα κομμάτια των πακέτων, ώστε να μπορέσει να τα επεξεργαστεί σωστά. Με αυτόν τον τρόπο μειώνουμε την επίδραση των χαμένων πακέτων, καθώς διασκορπίζουμε την χαμένη πληροφορία σε πολύ μικρά κομμάτια στο ανακατασκευασμένο μας stream. Τα πολύ μικρά κομμάτια χαμένης πληροφορίας δε θα επηρεάσουν τόσο την ποιότητα του αναπαραγόμενου σήματος. Παρόλο που το interleaving αυξάνει την καθυστέρηση (latency), καθώς χρειάζεται κάποιος χρόνος για να ανακατασκευαστεί σωστά το stream, δεν αυξάνει σαν τεχνική το κόστος σε bandwidth οπότε αξίζει να δοκιμαστεί. Ειδικά σε non-interactive εφαρμογές έχει πολύ καλά αποτελέσματα. Forward Error Correction (FEC) Αυτή η τεχνική βασίζεται στην λογική ότι προσθέτουμε έξτρα πληροφορία στο stream που θέλουμε να μεταδώσουμε, ώστε να μπορούμε έπειτα από αυτή, στην πλευρά του 29

30 παραλήπτη, να ανακατασκευάσουμε τα χαμένα πακέτα. Δύο γνωστοί αλγόριθμοι για FEC είναι το parity coding και το Reed-Solomon coding. Στο parity coding, εφαρμόζουμε το λογικό XOR σε ομάδες πακέτων ώστε να δημιουργήσουμε αντίστοιχα parity πακέτα (πακέτα ισοτιμίας). Αυτή η τεχνική έχει το πλεονέκτημα ότι είναι ανεξάρτητη από το format του μέσου που θέλουμε να μεταδώσουμε, παρέχει απόλυτη ανακατασκευή των χαμένων πακέτων και δεν έχει μεγάλη υπολογιστική πολυπλοκότητα. Τα ίδια πλεονεκτήματα ισχύουν και για το Reed-Solomon coding. Τα μειονεκτήματα αυτής της τεχνικής είναι η καθυστέρηση που εισάγει μέχρι να δημιουργηθεί το ανακατασκευασμένο stream, το επιπλέον bandwidth που χρειάζεται και η σχετικά δύσκολη αποκωδικοποίηση τους. Επιπρόσθετα, υπάρχει και το media-specific FEC. Εδώ λαμβάνουμε υπόψη το encoding ή τη συμπίεση του stream ώστε να δημιουργηθεί μια πιο ικανή και έξυπνη ανακατασκευή στην μεριά του παραλήπτη. Παρακάτω βλέπουμε σχηματικά πως λειτουργεί το FEC για τις 2 αυτές περιπτώσεις. Repair using Parity FEC Τα parity πακέτα μας βοηθάνε να ανακατασκευάσουμε οποιοδήποτε από τα n-k πακέτα, όπου n-k o αριθμός των parity πακέτων και k o αριθμός των "καθαρών" πακέτων. Στον προσδιορισμό των FEC παραμέτρων n και k, πρέπει να λάβουμε τα παρακάτω υπόψη: Τα επιπλέον πακέτα FEC αυξάνουν το overhead στο δίκτυο και αυξάνουν το απαραίτητο bandwidth. Μικρά FEC blocks, δηλαδή 1 FEC πακέτο για λίγα πακέτα καθαρής πληροφορίας, προκαλούν μεγάλο overhead. 30

31 Μεγάλα FEC blocks προκαλούν μεγάλη καθυστέρηση στο Receiver, καθώς ο τελευταίος πρέπει να περιμένει για όλα τα πακέτα του FEC block για να μπορέσει να κάνει ανακατασκευή. Στο παρακάτω σχήμα ένας scalable κωδικοποιητής παράγει 2 ανεξάρτητα streams. Ένα enhanced level και ένα base level. Το enhance level έχει μικρότερη συμπίεση, υψηλότερη ποιότητα και μεγαλύτερα streams, ενώ το base level έχει μεγαλύτερη συμπίεση, χαμηλότερη ποιότητα και μικρότερα streams. (π.χ. PCM encoding στα 64Kbps και GSM encoding στα 13Kbps). 31

32 Διόρθωση στην πλευρά του παραλήπτη Αυτές οι τεχνικές εφαρμόζονται στην πλευρά του παραλήπτη χωρίς ενημέρωση του αποστολέα. Είναι χρήσιμες όταν οι τεχνικές διόρθωσης του αποστολέα αποτύχουν να διορθώσουν όλα τα χαμένα πακέτα ή όταν ο αποστολέας δεν έχει την δυνατότητα να εφαρμόσει τεχνικές διόρθωσης. Είναι γνωστές ως Error Concealment Techniques και χωρίζονται σε 3 βασικές κατηγορίες όπως δείχνει το παρακάτω σχήμα: Ας δούμε τις τρεις κατηγορίες μία προς μία: Insertion based Αυτές οι τεχνικές έχουν να κάνουν με την αντικατάσταση του χαμένου πακέτου είτε με θόρυβο ή σιωπή, είτε με το προηγούμενο πακέτο, ώστε να καταφέρουν να κρατήσουν την χρονική συσχέτιση ανάμεσα στα πακέτα. H αντικατάσταση του χαμένου πακέτου με σιωπή είναι αποτελεσματική για μικρά μεγέθη πακέτων (< 4ms) και για χαμηλά loss rates (< 2%). Η απόδοσή της πέφτει εκθετικά καθώς το πακέτο μεγαλώνει και είναι εντελώς αναποτελεσματική για μεγέθη πακέτων 40ms, που είναι και πολύ χρησιμοποιούμενα για audio εφαρμογές. H αντικατάσταση του χαμένου πακέτου με θόρυβο έχει καλύτερο ακουστικό αποτέλεσμα στο ανθρώπινο αυτί σε σχέση με την σιωπή. Η αντικατάσταση με το προηγούμενο πακέτο, με κάποιο fading στον ήχο μάλιστα, έχει το καλύτερο αποτέλεσμα από τις 2 παραπάνω τεχνικές και είναι ένας αρκετά καλός συμβιβασμός ανάμεσα στις προηγούμενες δυο τεχνικές και τις πιο περίπλοκες τεχνικές με interpolation. Interpolation based Την καλύτερη απόδοση την έχουν οι τεχνικές interpolation που είναι και δύσκολες στην υλοποίηση και απαιτητικές σε πόρους. Χρησιμοποιώντας αναγνώριση προτύπων και παρεμβολή 32

33 καταλήγουν σε έναν πακέτο το οποίο τελικά μοιάζει με το χαμένο. Ανάμεσα τους ξεχωρίζουν οι παρακάτω: Waveform Substitution Εδώ χρησιμοποιείται πλέον το καθαρό audio λίγο πριν την χαμένη πληροφορία και μετά την χαμένη πληροφορία, ώστε να βρεθεί ένα κατάλληλο σήμα (κυματομορφή) η οποία θα αντικαταστήσει την χαμένη. Time Scale Modification Ίσως η καλύτερη interpolation based τεχνική. Επιτρέπει το audio που βρίσκεται στα 2 άκρα του χαμένου, να διασκορπιστεί σε αυτό. Σαν καλύτερη interpolation τεχνική είναι και η πιο απαιτητική σε πολυπλοκότητα. Regeneration Based Repair Αυτές οι τεχνικές χρησιμοποιούν την πληροφορία που έχουν για τον αλγόριθμο συμπίεσης του audio για να εξάγουν παραμέτρους, από τις οποίες μπορεί το χαμένο audio πακέτο να αναδημιουργηθεί. Είναι υποχρεωτικά τεχνικές που εξαρτιόνται από τον εκάστοτε codec, αλλά δίνουν πολύ καλά αποτελέσματα εξαιτίας της μεγάλης στατικής πληροφορίας που μπορούν να χρησιμοποιήσουν κατά την ανακατασκευή. Γενικότερα, όπως φαίνεται, η επιτυχία μιας error concealment τεχνικής εξαρτάται τόσο από το μέγεθος πακέτου όσο και από το encoding που χρησιμοποιείται. Τα αποτελέσματα μπορεί να διαφέρουν τρομερά για αυτό πρέπει να γίνουν πολλές δοκιμές με διάφορους codecs. Επιλογή Τεχνικής Ανακατασκευής Όπως βλέπουμε λοιπόν, ανάλογα με την εφαρμογή που χρησιμοποιούμε, interactive ή non interactive, την ποιότητα και την πολυπλοκότητα που θέλουμε, έχουμε πολλές επιλογές για να πετύχουμε το επιθυμητό αποτέλεσμα, κάνοντας το κατάλληλο trade-off. Δεν πρέπει να ξεχνάμε ότι πολλοί audio και speech codecs υποθέτουν ότι η αποκωδικοποίηση του ήχου γίνεται σε ιδανικές καταστάσεις. Δηλαδή ότι υπάρχει μια φυσική συνέχεια. Έτσι όταν έρθει ένα χαμένο πακέτο, ίσως είναι αδύνατο να συνεχιστεί η σωστή αποκωδικοποίηση. Κι αυτό πρέπει να ληφθεί σοβαρά υπόψη κατά την διαδικασία επιλογής. Τα παρακάτω σχήματα δείχνουν διάφορες τεχνικές ανακατασκευής και την αντίστοιχη πολυπλοκότητα τους. 33

34 a) Original audio signal, b) the loss pattern, c) packet repetition, d) one sided waveform substitution Στον παρακάτω πίνακα φαίνεται η ποιότητα σε σχέση με την πολυπλοκότητα των μεθόδων που παρουσιάστηκαν. Rough quality/complexity trade-off for error concealment 34

35 Επίλογος Σε αυτό το κεφάλαιο παρουσιάσαμε κάποιες ενδιαφέρουσες τεχνολογίες που αποτέλεσαν τη βάση της μελέτης για την υλοποίηση της εφαρμογής μας. Στα επόμενα κεφάλαια θα δούμε ποιες τεχνολογίες επιλέξαμε τελικά να χρησιμοποιήσουμε και τα αποτελέσματα της χρήσης τους στη δική μας περίπτωση. 35

36 ΚΕΦΑΛΑΙΟ 3 ο ΠΑΡΟΜΟΙΕΣ ΕΡΓΑΣΙΕΣ Εισαγωγή Σε αυτήν την ενότητα θα παρουσιάσουμε περιληπτικά ορισμένες από τις πολλές εργασίες που μελετήσαμε, οι οποίες ασχολήθηκαν παλαιότερα με το ίδιο αντικείμενο. Πιστεύουμε ότι είναι άξιες αναφοράς μιας και μας έδωσαν ιδέες για την υλοποίηση αυτής της διπλωματικής εργασίας. Σε κάποια σημεία του κειμένου παρατίθενται για επεξήγηση αυτούσιες κάποιες εικόνες των εργασιών αυτών. Adaptive packet video streaming over P2P networks using active measurements Mubashar Mushtaq & Toufik Ahmed, ISCC '06 Σε αυτή την εργασία (Paper [8] της βιβλιογραφίας) μελετάται το πρόβλημα της αποστολής real-time video σε P2P δίκτυα από πολλούς αποστολείς σε έναν δέκτη. Παρουσιάζεται ο σχεδιασμός και η αξιολόγηση ένας quality adaptation μηχανισμού. Ο σχεδιασμός βασίζεται στην κατάλληλη επιλογή των αποστολέων ο οποίος γίνεται με μετρήσεις RTT, ώστε να βελτιστοποιηθεί το συνολικό throughput. Το video που στέλνεται είναι οργανωμένο σε MDC layers, το οποίο παρέχει υψηλή ανεκτικότητα στα λάθη. 36

37 Ορισμένες αξιόλογες παρατηρήσεις είναι οι εξής: Η ποιότητα του video στον αποστολέα δεν αυξάνεται αναγκαστικά όταν προστεθούν νέοι peers που θα στέλνουν το υλικό, καθώς οι τελευταίοι μπορεί να συνδεθούν πίσω από το ίδιο bottleneck link. Για αυτό και μετριέται η απόδοση του κάθε νέου peer ξεχωριστά ώστε να αποφασιστεί αν θα "ενεργοποιηθεί" η συμμετοχή του στο δίκτυο. Οι peers σχηματίζουν clusters όπως φαίνεται και στην παρακάτω εικόνα για καλύτερη οργάνωση. Για την αποστολή του video προτιμούνται peers από διαφορετικά clusters, ώστε να αποφεύγεται η συμφόρηση στο link που ενώνει το cluster με τον receiver. Δεν είναι θεμιτό να αλλάζει συνεχώς ο υποψήφιος για αποστολή video λόγω του μικρότερου RTT, για να αποφευχθεί μεγάλο overhead στο δίκτυο. Γι' αυτό προτείνεται μέσω ενός συντελεστή λ να δίνεται μεγαλύτερη προτεραιότητα στις πρόσφατες παρατηρήσεις και λιγότερη στις παλιές. Όσο πιο μικρό το λ τόσο πιο συχνή η αλλαγή του Peer Αν ο buffer του Receiver πέσει κάτω από ένα όριο(threshold), τότε αρχίζει και ψάχνει για καινούργιους υποψήφιους αποστολείς. Τα τελικά αποτελέσματα φανερώνουν ότι η λύση που προτείνουν βοηθάει τόσο στην καλύτερη αξιοποίηση του bandwidth του δικτύου, όσο και στην καλύτερη αναπαραγωγή στην πλευρά του αποστολέα. 37

38 Distributing streaming media content using cooperative networking Venkata N. Padmanabhan, Helen J. Wang, Philip A. Chou, Microsoft Research, April 2002 Σε αυτήν την εργασία (Paper [5] της βιβλιογραφίας) συζητιέται το πρόβλημα που αντιμετωπίζει ένας server όταν ένας πολύ μεγάλος αριθμός από clients ζητήσει εξυπηρέτηση από αυτόν. Σαν λύση προτείνεται το Cooperative Networking (CoopNet), όπου οι clients συνεργάζονται για να διανείμουν το υλικό, απαλλάσσοντας έτσι τον server από το βαρύ φορτίο. Οι Clients συνδέονται μεταξύ τους με overlay network σε μορφή δέντρου. Κάθε node του δέντρου μεταδίδει το stream στα παιδιά του χρησιμοποιώντας unicast. To πόσο παιδιά έχει κάθε node εξαρτάται από το διαθέσιμο για αυτό bandwidth. Σε γενικές γραμμές τα παιδιά που θα έχει ο server θα είναι τα περισσότερα, μιας και, κατά κανόνα, αυτός έχει το μεγαλύτερο διαθέσιμο bandwidth. Ο αλγόριθμος που υλοποιούν για την κατασκευή του δέντρου φροντίζει 2 πράγματα: Το δέντρο να είναι κοντό και balanced, τόσο για να ελαττωθεί η καθυστέρηση της διαδρομής από την ρίζα ως το τελευταίο παιδί, όσο και για να μειωθεί η πιθανότητα αλλοίωσης στην ποιότητα αναπαραγωγής από την αναχώρηση ενός κόμβου. Να είναι γρήγορος στην εισαγωγή και διαγραφή nodes, ώστε να μην επηρεάζονται οι άλλοι nodes του δικτύου. Ορισμένες αξιόλογες παρατηρήσεις είναι οι εξής: Το πολυμεσικό υλικό χωρίζεται σε πολλαπλά descriptions χρησιμοποιώντας MDC και κάθε sub-stream στέλνεται στον παραλήπτη του μέσα από διαφορετικό peer. Ο Server γνωρίζει την κατάσταση των peers. Έτσι σε περίπτωση που μεταδίδεται ondemand πολυμεσικό υλικό και συμβεί overload στον server, οι clients κρατάνε στον 38

39 buffer τους ένα μέρος από αυτό που έχουν ήδη παρακολουθήσει και o server μπορεί να στείλει τους νέους clients στους παλιούς για να αναζητήσουν πληροφορία. Με τη χρήση ενός μόνο δέντρου η αναχώρηση ή το crash ενός node θα έχει σοβαρό αντίκτυπο σε όλους τους απογόνους του. Οι απόγονοι μπορεί να μην πάρουν καθόλου το stream μέχρι το δέντρο να διορθωθεί. Γι' αυτό και υλοποιούνται πολλαπλά δέντρα, με τα nodes σε διαφορετική θέση σε κάθε δέντρο και με ένα MDC description ανά δέντρο. Όσο περισσότερα τα δέντρα που χρησιμοποιούνται, τόσο μικρότερη και η πιθανότητα κάποιο node να μην πάρει κανένα description. Συγκεκριμένα αν Ν ο αριθμός των δέντρων και τείνει στο άπειρο, τότε η παραπάνω πιθανότητα γίνεται μηδενική. Τα τελικά αποτελέσματα δείχνουν ότι το CoopNet μπορεί να βοηθήσει στο να μειωθεί το βαρύ φορτίο στον server, χωρίς μάλιστα οι συνεργαζόμενοι peers να έχουν κάποιο παράλογο overload. Επίσης, μεταδίδοντας live streams σε πολλαπλά δέντρα, με ένα MD description ανά δέντρο, αυξήθηκε σημαντικά η αξιοπιστία του δικτύου. 39

40 Challenges & approaches in large-scale P2P media streaming W. P. Ken Yiu, Xing Jin, and S. H. Gary Chan, Hong Kong University of Science and Technology Αυτή η εργασία (Paper [6] της βιβλιογραφίας) επικεντρώνεται στα 2 μεγάλα προβλήματα που έχει να αντιμετωπίσει κάποιος σχεδιάζοντας ένα P2P δίκτυο. Αυτά είναι ο εντοπισμός των Peers με το ενδιαφερόμενο υλικό και η διαδρομή μετάδοσης του υλικού σε αυτόν που το ζήτησε. Για τον εντοπισμό των κατάλληλων Peers οι συνήθεις τεχνικές που εφαρμόζονται είναι οι εξής: Centralized Directory: Όλοι οι Peers αποθηκεύουν χρήσιμες πληροφορίες σε έναν κεντρικό server, όπως είναι η IP τους, το bandwidth που διαθέτουν, κτλ και ο server αποφασίζει σε ποια θέση θα μπει ο νέος Peer. Για παράδειγμα μπορεί να επιλεχθεί ένας peer με μεγάλο bandwidth και ο οποίος βρίσκεται κοντά με τον νέο Peer. Στην παρακάτω εικόνα φαίνεται η λογική του Centralized Directory. Hierarchical Overlay Structure: Εδώ οι Peers είναι οργανωμένοι ιεραρχικά, π.χ. σε ένα overlay δέντρο. Ο νέος Peer που θέλει να συνδεθεί πρώτα επικοινωνεί με τον rendezvous Peer, που συνήθως είναι η πηγή. Η πηγή επιστρέφει μια λίστα με Peers που είναι συνδεδεμένοι μέχρι και ένα επίπεδο κάτω από αυτήν. O νέος Peer έρχεται σε επαφή με καθένα από αυτούς τους Peer, μέχρι να βρει τον πιο κατάλληλο, ανάλογα με τα κριτήρια της εφαρμογής. Έστω ότι ο πιο κατάλληλος είναι ο Px. O Px θα δώσει και αυτός στον νέο Peer μια λίστα με τους Peers που είναι συνδεδεμένοι ακριβώς ένα επίπεδο κάτω από αυτόν. Ο νέος client έρχεται σε επαφή και με αυτούς τους Peers και διαλέγει τον καλύτερο. Η διαδικασία συνεχίζεται μέχρι ο νέος client να βρει το περιεχόμενο που ζητάει με ένα καλό QoS. 40

41 Control Flooding: Η αίτηση αναζήτησης από έναν Peer πηγαίνει προς όλους τους γειτονικούς του. Οι γειτονικοί του ξαναπροωθούν την αίτηση σε όλους τους γειτονικούς τους Peers, εκτός από αυτόν που έστειλε την αίτηση. Αυτή η αίτηση συνοδεύεται από μια TTL(Time to Live) τιμή. Κάθε αναμετάδοση της αίτησης ελαττώνει αυτή την τιμή κατά 1. Η προώθηση της αίτησης σταματάει μόλις το TTL γίνει μηδέν. Συνήθως αυτές οι αναζητήσεις προκαλούν πολύ κίνηση στο δίκτυο και υπάρχει πάντα η περίπτωση να μην βρεθεί η πληροφορία που ζητήθηκε. Παρακάτω φαίνονται τα αποτελέσματα των διαφορών μεθόδων αναζήτησης κατάλληλων Peers, καθώς και διάφορες τεχνικές για την μετάδοση της πληροφορίας, το λεγόμενο content delivery. Μέθοδοι αναζήτησης κατάλληλων peers 41

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

43 ΚΕΦΑΛΑΙΟ 4 ο ΠΑΡΟΥΣΙΑΣΗ ΕΦΑΡΜΟΓΗΣ Εισαγωγή Έχοντας μελετήσει τις υπάρχουσες τεχνολογίες μετάδοσης ήχου, προχωρήσαμε στην υλοποίηση του στόχου της διπλωματικής, δηλαδή τη δημιουργία ενός δικτύου Peer-to-Peer, που θα δίνει τη δυνατότητα σε κάθε peer να μεταδώσει ή να ακούσει μουσική σε πραγματικό χρόνο. Καταλήξαμε στην υλοποίηση ενός υβριδικού P2P δικτύου, δηλαδή ένα όχι αμιγώς P2P δίκτυο, αφού θα υπάρχει κεντρικός server. Ο server εκτελεί χρέη αρχικοποίησης των peers κατά την είσοδό τους στο δίκτυο, κάνοντας γνωστή την παρουσία του ενός στον άλλο. Εκτός αυτού, ο server δεν επιτελεί άλλη διεργασία, ούτε συμμετέχει στη μετάδοση του ήχου. Έτσι, μπορούμε να μιλάμε για καθαρά P2P μετάδοση του ήχου σε δίκτυο, όπου ναι μεν υπάρχει server, αλλά ο ρόλος του είναι καθαρά βοηθητικός, χωρίς να επεμβαίνει στην επικοινωνία μεταξύ των peers. Σκοπός μας ήταν να μεταδώσουμε ήχο ικανοποιητικής ποιότητας, έχοντας κατά νου την περίπτωση των διαδικτυακών ραδιοφωνικών σταθμών, που εκπέμπουν συνήθως σε bit rates που κυμαίνονται από 32 έως 128Kbps. Επιθυμία μας ήταν η εφαρμογή μας να μπορεί να χρησιμοποιηθεί από κάθε χρήστη που έχει μια τυπική DSL σύνδεση, γι αυτό και καταλήξαμε στην επιλογή ήχου στα 64Kbps. Με αυτό το bit rate, έγινε αρχικά υλοποίηση για μετάδοση ήχου κωδικοποίησης PCM (8 bit, 8 KHz, mono), ενώ στη συνέχεια περάσαμε και σε κωδικοποίηση MP3 (24 KHz, stereo), που είναι σαφώς υψηλότερης ποιότητας. Στην ανάλυση που ακολουθεί, θα περιγράψουμε τις προδιαγραφές της εφαρμογής, τον τρόπο λειτουργίας της, τις επιλογές των διαφόρων παραμέτρων και τους τρόπους αντιμετώπισης των προβλημάτων που παρουσιάστηκαν κατά την υλοποίηση. Προδιαγραφές Εφαρμογής Η εφαρμογή αναπτύχθηκε με τη γλώσσα προγραμματισμού Java, για το server και peer κομμάτι της. Χρησιμοποιήθηκε η πλατφόρμα Java SE 5.0 update 15, για λόγους συμβατότητας, ενώ δεν υστερεί σε λειτουργικότητα από τη νεότερη έκδοση 6.0. Επιπλέον, για την αναπαραγωγή ήχου με κωδικοποίηση MP3 χρησιμοποιήθηκε η open source βιβλιοθήκη MP3SPI

44 Γιατί Java Οι λόγοι για τους οποίους επιλέξαμε τη Java για την ανάπτυξη της εφαρμογής είναι οι εξής: Είναι μια γλώσσα που προσφέρει αυξημένες δυνατότητες για την επικοινωνία των υπολογιστών, χωρίς να απαιτεί την χρήση εξειδικευμένων και πολύπλοκων εντολών. Η Java καταφέρνει μέσα από το package java.net να κρύψει όλη την low-level δυσκολία του προγραμματισμού των sockets και να δώσει ένα καθαρό αντικειμενοστραφές περιβάλλον προγραμματισμού. Η εγγενής υποστήριξη πολυνηματικών εφαρμογών (multi-threading). Κάτι απολύτως απαραίτητο για την υλοποίηση της εφαρμογής, τόσο από την πλευρά του στησίματος του P2P δικτύου, όσο και στο κομμάτι της αναπαραγωγής. No pointers = More fun, όπως λέει και ο επιβλέπων αυτής της διπλωματικής και συμφωνούν οι συγγραφείς της! Το τελικό πρόγραμμα μας μπορεί να τρέξει πρακτικά σε οποιοδήποτε γνωστό λειτουργικό σύστημα, καθώς η Java είναι ανεξάρτητη πλατφόρμας. Ένα πρόγραμμα Java δεν τρέχει ποτέ natively σε κάποιο μηχάνημα, αλλά ένα ειδικό native πρόγραμμα, ο Java Interpreter, διαβάζει το byte code του προγράμματος και το μεταφράζει στις αντίστοιχες εντολές της εκάστοτε μηχανής. Αυτό δοκιμάστηκε και στην πράξη μιας και η εφαρμογή μας γράφτηκε τόσο κάτω από περιβάλλον Windows XP όσο και σε Mac OS X, ενώ δοκιμάστηκε επιπλέον σε Ubuntu Linux 8.04 και Windows Vista χωρίς το παραμικρό πρόβλημα. Ελάχιστες απαιτήσεις Οι απαιτήσεις της εφαρμογής τόσο σε hardware, όσο και σε software είναι μικρές για τα σημερινά δεδομένα. Software requirements: Java Runtime Environment (JRE) 1.5 εγκατεστημένο MP3 SPI για αποκωδικοποίηση MP3 Substance Look and Feel (Theme για το GUI) Πρέπει να τονίσουμε ότι όλα τα παραπάνω προαπαιτούμενα αποτελούν λογισμικό ανοιχτού κώδικα. Hardware requirements: Ένα σχετικά σύγχρονο μηχάνημα ( 5ετίας ) Port forwarding στις απαραίτητες θύρες ( για τον server, για τον peer) Μια σχετικά γρήγορη σύνδεση στο Internet (DSL) ή τοπικό δίκτυο. Τουλάχιστον 2 υπολογιστές, ένας για λειτουργία ως server και broadcaster και ένας listener 44

45 Περιγραφή Server Όπως αναφέραμε και παραπάνω, η εφαρμογή αποτελείται από δύο ανεξάρτητα, αλλά άρρηκτα συνδεδεμένα μεταξύ τους κομμάτια, τον server και τον client (peer), τα οποία περιγράφουμε ξεχωριστά. Λογικό διάγραμμα λειτουργίας του Server ΑΡΧΗ ΠΑΤΗΜΑ ΚΟΥΜΠΙΟΥ ΚΛΕΙΣΙΜΑΤΟΣ ΤΕΛΟΣ ΑΡΧΙΚΟΠΟΙΗΣΗ HANDSHAKING ΡΟΥΤΙΝΑ ΕΞΥΠΗΡΕΤΗΣΗΣ ΠΑΚΕΤΩΝ ΠΡΟΣΘΗΚΗ ΤΟΥ PEER ΣΤΟΝ PEER TABLE ΝΑΙ ΕΠΙΤΥΧΕΣ; ΟΧΙ ΑΝΑΜΟΝΗ ΠΑΚΕΤΟΥ ΤΥΠΟΣ ΠΑΚΕΤΟΥ YOUTUNE ΑΠΟΣΤΟΛΗ ΛΙΣΤΑΣ ΤΩΝ BROADCASTERS ΣΤΟΝ PEER BROADCAST ΝΑΙ TIMEOUT? ΑΠΟΣΤΟΛΗ ΠΑΚΕΤΟΥ ECHO ΣΕ ΟΛΟΥΣ ΤΟΥΣ PEERS ΟΧΙ ΕΞΥΠΗΡΕΤΗΣΗ ΠΑΚΕΤΟΥ ΣΕ ΝΕΟ ΞΕΧΩΡΙΣΤΟ THREAD STOP BROADCAST REFRESH DISCONNECT ΕΝΗΜΕΡΩΣΗ PEER TABLE ΑΠΟΣΤΟΛΗ ΕΝΗΜΕΡΩΜΕΝΗΣ ΛΙΣΤΑΣ ΤΩΝ BROADCASTERS ΣΤΟΝ PEER ΑΦΑΙΡΕΣΗ TOY PEER ΑΠO TON PEER TABLE ΕΝΗΜΕΡΩΣΗ PEER TABLE ΤΕΛΟΣ ΕΞΥΠΗΡΕΤΗΣΗΣ ΠΑΚΕΤΟΥ Η λειτουργία του server είναι αρκετά απλή, αφού θέλαμε να περιορίσουμε το ρόλο του, κάνοντάς τον να επιτελεί μόνο τις απολύτως απαραίτητες λειτουργίες. Ο server, λοιπόν, διατηρεί έναν πίνακα με τις διευθύνσεις IP όλων των peers που έχουν συνδεθεί στο δίκτυο, 45

46 καθώς και μία boolean μεταβλητή που δείχνει αν ένας peer έχει επιλέξει να είναι broadcaster (να μεταδίδει ήχο) ή listener (να ακούει ήχο). Φροντίζει δε, να εξυπηρετεί τους peers που του στέλνουν συγκεκριμένα αιτήματα με αποστολή UDP πακέτων. Εξυπηρέτηση πακέτων Όταν ξεκινάει η λειτουργία του server, ανοίγει μία νέα datagram socket που περιμένει συνεχώς αιτήματα στην πόρτα Όταν λάβει ένα πακέτο, ελέγχει τον header του (τα 4 πρώτα bytes), τον οποίο τεχνητά έχουμε προσθέσει και με τον οποίο ο peer ενημερώνει για τις προθέσεις του. Ο server ελέγχει τα εισερχόμενα πακέτα για τους παρακάτω headers: YouTune : Είναι το συνθηματικό όνομα που διαλέξαμε για το δίκτυό μας και είναι το πρώτο πακέτο που στέλνει ένας peer στον server για να δηλώσει ότι θέλει να γίνει μέλος του δικτύου. Όταν λάβει αυτό το πακέτο, ο server προσθέτει τον peer στον σχετικό πίνακα (αφού ελέγξει ότι δεν είναι ήδη καταχωρημένος) και προχωρεί στην αποστολή πακέτου ACK, που δηλώνει ότι ο peer έχει προστεθεί επιτυχώς. Broadcast : Με αυτό το πακέτο, ένας peer δηλώνει ότι θέλει να γίνει broadcaster, οπότε ο server ενημερώνει τη σχετική boolean μεταβλητή, από false σε true. Stop Broadcast : Αντίστοιχα με το παραπάνω, ο peer δηλώνει ότι σταματάει τη μετάδοση ήχου, οπότε η μεταβλητή γίνεται ξανά false. Refresh : Με αυτό το πακέτο ο peer ζητάει να του αποσταλεί ο ενημερωμένος πίνακας των broadcasters, οπότε ο server προχωράει σε αποστολή των διευθύνσεων IP των peers, οι οποίοι μεταδίδουν ήχο. Δηλαδή, ελέγχεται ο πίνακας για να βρεθούν οι peers που έχουν τη σχετική boolean μεταβλητή true και αποστέλλονται σειριακά οι IPs τους (μία IP σε κάθε πακέτο). Δεν στέλνονται όλες μαζί σε ένα πακέτο, γιατί σε περίπτωση που υπάρχουν πολλοί broadcasters στο δίκτυο, το μέγεθος του πακέτου θα μπορούσε να υπερβεί το μέγιστο επιτρεπόμενο μέγεθος ενός UDP πακέτου, δηλαδή τα bytes. Σε κάποια λειτουργικά συστήματα μάλιστα το όριο αυτό είναι ακόμα μικρότερο, όπως π.χ. στα Windows το μέγιστο προεπιλεγμένο μέγεθος είναι 1280 bytes. Disconnect : Με αυτό το πακέτο ο peer δηλώνει την έξοδό του από το δίκτυο, οπότε ο server αφαιρεί τα στοιχεία του από τον πίνακα των peers. Όσον αφορά την έξοδο ενός peer από το δίκτυο, αυτή μπορεί να μη γίνει πάντα με αποστολή του πακέτου Disconnect. Είναι πιθανό αυτό το πακέτο να χαθεί, ο peer να κλείσει με αντικανονικό τρόπο την εφαρμογή του, ή για οποιονδήποτε άλλο λόγο το πακέτο αυτό να μην αποσταλεί καν. Για να προλάβει τέτοιες καταστάσεις ο server αποστέλλει σε τακτά χρονικά διαστήματα (κάθε 15 δευτερόλεπτα) ένα πακέτο τεσσάρων bytes (πακέτο τύπου ECHO) σε όλους 46

47 τους peers (δουλεύοντας σε ανεξάρτητο thread). Με το πακέτο ECHO ο server ζητάει από τους peers να του επιβεβαιώσουν την παρουσία τους στο δίκτυο. Οι peers πρέπει με τη σειρά τους να απαντήσουν με το ίδιο πακέτο, οπότε ο server καταλαβαίνει ότι ο peer που απάντησε δεν έχει αποσυνδεθεί. Επειδή για οποιονδήποτε λόγο μπορεί κι αυτό το πακέτο να χαθεί, αν δεν πάρει απάντηση από κάποιον peer, ο server προσπαθεί δεύτερη ή και τρίτη φορά αν χρειαστεί. Αν και οι τρεις προσπάθειες επικοινωνίας με ECHO αποτύχουν, δηλαδή ο peer δεν απαντήσει, τότε ο server καταλαβαίνει ότι ο peer έχει πια αποσυνδεθεί, οπότε τον αφαιρεί από τον πίνακα των peers. Multi-threading & συγχρονισμός Εδώ πρέπει να τονίσουμε και τον multi-threaded χαρακτήρα του server. Επειδή μπορεί ανά πάσα στιγμή να βρίσκονται στο δίκτυο πολλοί peers που θέλουν να επικοινωνήσουν μαζί του, η εξυπηρέτηση κάθε λαμβανόμενου πακέτου δεν γίνεται σειριακά, αλλά παράλληλα, σε ξεχωριστό thread για κάθε πακέτο. Έτσι, το κύριο thread παραμένει ανοιχτό αποκλειστικά για την παραλαβή ενός πακέτου (από τη πόρτα 5555) και μόλις γίνει η παραλαβή, ένα νέο thread ανοίγει για να εκτελεστεί ο κώδικας που εξυπηρετεί το αίτημα του peer που έστειλε το πακέτο. Αν απαιτείται αποστολή πακέτου από το νέο thread εξυπηρέτησης, ανοίγει νέο datagram socket στην πόρτα Αυτό όμως μπορεί να δημιουργήσει προβλήματα συγχρονισμού, όταν δύο διαφορετικά thread επιχειρήσουν να αποκτήσουν πρόσβαση στα ίδια δεδομένα. Αν δεν ελεγχθεί αυτή η διαδικασία, μπορεί να προκύψει σφάλμα (Exception, όπως τα ονομάζει η Java) κατά την εκτέλεση του προγράμματος εξαιτίας της ταυτόχρονης πρόσβασης. Για να αντιμετωπιστεί αυτό το πιθανό σφάλμα, όλες οι μέθοδοι που τροποποιούν ή διαβάζουν κοινά δεδομένα του server χρησιμοποιούν τεχνικές συγχρονισμού και κλειδώματος πρόσβασης (βλ. Java Locks). Επιλογή UDP έναντι TCP Οι εναλλακτικές που υπήρχαν για την επικοινωνία server-peer ήταν φυσικά δύο, το UDP και το TCP. Επιλέχθηκε τελικά το UDP για τη μετάδοση των μηνυμάτων αυτής της επικοινωνίας για δύο βασικούς λόγους. Ο ένας είναι η ταχύτητα του UDP, εφόσον η αποστολή ενός πακέτου είναι -πρακτικά- ακαριαία, ενώ για να ανοίξει μία TCP socket μεταξύ 2 υπολογιστών απαιτείται αποστολή 3 πακέτων (μόνο για το άνοιγμα του socket). Επιπλέον, σε περίπτωση πολλών peers στο δίκτυο, επειδή θα έπρεπε να ανοίγει νέο TCP socket για την παραλαβή κάθε μηνύματος, θα ήταν δυνατό να παραβιαστεί το μέγιστο επιτρεπόμενο όριο των ανοιχτών sockets του συστήματος. Αυτό το πρόβλημα αποφεύγεται με το UDP, αφού αρκεί μόνο ένα ανοιχτό datagram socket για την παραλαβή των πακέτων, ενώ για την αποστολή του πίνακα, όποτε αυτή ζητείται, ανοίγει ένα νέο datagram socket, το οποίο κλείνει αμέσως όταν ολοκληρωθεί η αποστολή. 47

48 Επίλυση κοινών προβλημάτων Καθ όλη τη διάρκεια της ανάπτυξης της εφαρμογής καταβλήθηκε μεγάλη προσπάθεια για την πρόβλεψη και αντιμετώπιση δυσάρεστων καταστάσεων που είναι πιθανό να προκύψουν σε ένα δίκτυο επικοινωνίας υπολογιστών. Μπορούμε να πούμε ότι τελικά καταφέραμε, και για το server και για το peer κομμάτι της εφαρμογής, να αναπτύξουμε εφαρμογές που είναι σταθερές στη λειτουργία τους και που προλαμβάνουν πολλά σφάλματα που θα ήταν πιθανό να εμφανιστούν λόγω απρόβλεπτων ενεργειών του χρήστη ή άλλων στοχαστικών προβλημάτων. Ένα συχνό πρόβλημα είναι η απώλεια ενός UDP πακέτου. Αν είναι πακέτο που επηρεάζει μια κρίσιμη διαδικασία (π.χ. αρχικοποίηση του peer ή έλεγχος παραμονής του στο δίκτυο) πρέπει να φροντίσουμε να γίνει επαναποστολή του σε περίπτωση που χαθεί. Επιπλέον, μπορεί να υπάρξουν προβλήματα λόγω απρόβλεπτης χρήσης της εφαρμογής. Για παράδειγμα, για οποιονδήποτε λόγο είναι δυνατό ένας peer που έχει συνδεθεί στο δίκτυο, να αποσυνδεθεί χωρίς να αποστείλει πακέτο Disconnect κι έπειτα να ξανασυνδεθεί χωρίς ο server να έχει προλάβει να εκτελέσει τον τακτικό έλεγχο (με χρήση ECHO). Τότε υπήρχε η περίπτωση να γίνει επανακαταχώρηση του peer στον σχετικό πίνακα, αν και αυτός είναι ήδη εγγραμμένος. Γι αυτό γίνεται έλεγχος διπλοκαταχώρησης. Γενικά, ένα ποσοστό του κώδικα έχει γραφεί για να πραγματοποιεί ακριβώς αυτούς τους ελέγχους. Ενδεικτικά, αναφέρουμε ότι το server κομμάτι της εφαρμογής χρειάστηκε συνολικά περίπου 450 γραμμές κώδικα. Είναι δηλαδή σχετικά μικρής έκτασης, για τις λειτουργίες που επιτελεί. Σε αυτό συμβάλλει και η έλλειψη γραφικού περιβάλλοντος (GUI). Πριν περάσουμε στην περιγραφή του peer (client) της εφαρμογής παραθέτουμε μία εικόνα από τη λειτουργία του server. Μηνύματα λειτουργίας του server στην κονσόλα 48

49 Περιγραφή Peer Γενικά Η εφαρμογή του client (peer) του δικτύου αποτελεί και το κύριο κομμάτι της διπλωματικής, αφού εκεί εφαρμόζουμε όλες τις υπό συζήτηση τεχνολογίες. Αναπτύχθηκε ένα φιλικό προς το χρήστη γραφικό περιβάλλον (GUI), με γνώμονα την απλότητα και την ευχρηστία. Στην εικόνα που ακολουθεί παρουσιάζουμε ένα στιγμιότυπο της εκτέλεσης του προγράμματος. Εικόνα 2 Το GUI είναι ιδιαίτερα απλό και δίνει στο χρήστη τη δυνατότητα να ακούσει ή να εκπέμψει μουσική με 2 απλά βήματα: 1. Ο χρήστης συνδέεται στο δίκτυο πατώντας το κουμπί σύνδεσης (Connect/Disconnect). 2. Σε ελάχιστο χρόνο λαμβάνεται η λίστα των broadcasters και ενεργοποιούνται τα κουμπιά Broadcast & Listen. Ο χρήστης μπορεί πια πατώντας ένα από τα 2 κουμπιά να ξεκινήσει την αντίστοιχη διαδικασία. Η διαδικασία περιγράφεται πιο αναλυτικά παρακάτω σε λογικά διαγράμματα. Θα δούμε διαγράμματα ξεχωριστά για κάθε λειτουργία της εφαρμογής. Πριν από αυτό όμως, ας γνωρίσουμε κάποια βασικά χαρακτηριστικά της εφαρμογής. 49

50 Τύποι λειτουργίας Όταν ο χρήστης ανοίγει την εφαρμογή, είναι εν δυνάμει ακροατής ή μεταδότης μουσικής. Έτσι, μετά τη σύνδεσή του στο δίκτυο και αφού ενεργοποιηθούν τα thread που διαχειρίζονται τα εισερχόμενα πακέτα ή sockets, ο χρήστης διαλέγει αν ο client/peer του θα γίνει Broadcaster (για μετάδοση ήχου) ή Listener (για να ακούσει μουσική). Ας δούμε πιο αναλυτικά αυτούς τους τύπους λειτουργίας. Προγραμματιστικά, ο Listener και ο Broadcaster είναι δύο κλάσεις-αντικείμενα που αρχικοποιούνται όταν ο χρήστης ενεργοποιήσει την αντίστοιχη διαδικασία (πατώντας το κατάλληλο κουμπί). Περιέχουν μεθόδους για διαχείριση των thread αναπαραγωγής (Player) ή μετάδοσης (Transmitter) ήχου. Έχουμε λοιπόν δύο δυαδικά αντικείμενα με τα αντίστοιχα thread, τον Listener-Player και τον Broadcaster-Transmitter. Δυαδικά γιατί, όπως θα δούμε, ο τρόπος λειτουργίας τους είναι παρόμοιος. Χρήση UDP & TCP Η μετάδοση του ήχου στο δίκτυο γίνεται με UDP πακέτα. Η επιλογή του UDP ήταν επιβεβλημένη, καθώς σε μια εφαρμογή που απαιτεί μετάδοση ήχου σε πραγματικό χρόνο, η υψηλή ταχύτητα μετάδοσης είναι σε πρώτη προτεραιότητα. Μετά από δοκιμές, που θα δούμε στο επόμενο κεφάλαιο, επιλέχτηκε ως μέγεθος πακέτου τα 100 bytes καθαρής πληροφορίας ήχου (χωρίς τον header). Και ο Listener και ο Broadcaster διατηρούν από έναν buffer, στον οποίο αποθηκεύονται τα πακέτα ήχου που λαμβάνονται ή μεταδίδονται αντίστοιχα. Η λειτουργία των buffers θα αναλυθεί παρακάτω. Η χρήση του UDP δεν περιορίζεται όμως στη μετάδοση του ήχου. Πολλές διαδικασίες γίνονται με διακίνηση πακέτων. Καταρχήν, η επικοινωνία peer-server είναι βασισμένη εξ ολοκλήρου στο UDP, όπως είδαμε και στην περιγραφή του server. Επιπλέον, η επικοινωνία peerpeer γίνεται κι αυτή με UDP πακέτα, με μόνη εξαίρεση την ανταλλαγή κρίσιμων για τη λειτουργία του peer πληροφοριών, οπότε προτιμήσαμε την αξιοπιστία του TCP εφόσον δεν υπήρχε ανάγκη για ταχύτητα. Όταν προέκυψε η ανάγκη αξιόπιστης ανταλλαγής πληροφοριών που έχουν σχέση με την P2P δομή μετάδοσης του ήχου, το UDP δεν απέδωσε τα αναμενόμενα, οπότε δημιουργήθηκε η ανάγκη χρήσης TCP. Γι αυτό η εφαρμογή χρησιμοποιεί και μια TCP socket για τη μετάδοση αυτών των πληροφοριών. Ο όγκος των δεδομένων που διακινούνται δεν είναι μεγάλος, ώστε το TCP να προκαλεί καθυστέρηση, οπότε μπορούμε να πούμε ότι βρήκαμε τη χρυσή τομή στην παράλληλη χρήση των 2 πρωτοκόλλων. 50

51 Τεχνολογίες Μετάδοσης Ήχου Η μετάδοση του ήχου βασίστηκε σε 3 τεχνολογίες: 1. Το δομημένο Peer-to-Peer (P2P) 2. Τις τεχνικές πολλαπλών περιγραφών του ήχου (MDC) 3. Την αντιμετώπιση σφαλμάτων: a. Με τεχνικές Forward Error Correction (FEC) b. Με επαναποστολή των χαμένων πακέτων 1. Δομημένο Peer-to-Peer Όταν μιλάμε για δομημένο P2P, υπάρχει μια διαφοροποίηση από την κλασική έννοια του P2P. Το σύνηθες σε τέτοια δίκτυα είναι ο κάθε peer να ανακοινώνει στους υπόλοιπους peers το περιεχόμενό του. Όταν ένας peer θέλει π.χ. να ακούσει ένα συγκεκριμένο τραγούδι, ζητάει από τους peers του δικτύου να του ανακοινώσουν το περιεχόμενό τους. Ελέγχει τις ανακοινώσεις, βλέπει ποιοι peers έχουν το τραγούδι που θέλει και ζητάει από αυτούς να του το στείλουν. Ενώ αυτή η διαδικασία προσφέρεται για υπηρεσίες τύπου file sharing ή audio/videoon-demand, δεν είναι αρκετά γρήγορη για χρήση σε real-time εφαρμογή, αφού η διαδικασία ανακοίνωσης του περιεχομένου και αίτησης για πρόσβαση σε αυτό έχει καθυστερήσεις. Επιλέξαμε λοιπόν να φτιάξουμε από την αρχή ένα δίκτυο δικής μας έμπνευσης, όπου κάθε peer θα συμμετέχει σε μια συγκεκριμένη δομή μετάδοσης ήχου. Η αρχική σκέψη ήταν να χρησιμοποιηθεί η δομή του δέντρου, όπου ρίζα θα είναι ο Broadcaster και οι Listeners οι κόμβοι του δέντρου, ή η δομής της λίστας, με ρίζα πάλι τον Broadcaster και τους Listeners ως peers στις υπόλοιπες θέσεις. Οι δομές φαίνονται και σχηματικά. Δομές δέντρου & λίστας 51

52 Η κεντρική ιδέα είναι, σε κάθε περίπτωση, ο Broadcaster που πραγματοποιεί τη μετάδοση να στέλνει πακέτα ήχου μόνο στα παιδιά του σε κάθε δομή (Peer 0 & Peer 1 για το δέντρο και Peer 0 για τη λίστα). Έπειτα, τα παιδιά του αναμεταδίδουν τα πακέτα στα δικά τους παιδιά, κ.ο.κ. Αυτό το δομημένο P2P έχει το σαφές πλεονέκτημα της γρήγορης αναμετάδοσης από peer σε peer, η οποία πραγματοποιείται αμέσως όταν ληφθεί ένα πακέτο ήχου. Βέβαια, έχει το μειονέκτημα της σχετικά καθυστερημένης παραλαβής του ήχου στις κατώτερες θέσεις της δομής μετάδοσης (π.χ. ο Peer 3 παίρνει πακέτα με μικρή καθυστέρηση σε σχέση με τον Peer 0). Στην πράξη όμως, με τη χρήση buffer παραλαβής πακέτων ήχου και MDC (με αποστολή κάθε description σε διαφορετικό layer), θα δούμε ότι το φαινόμενο εξομαλύνεται και όλοι οι peers ακούνε τη μετάδοση του broadcaster με σχεδόν την ίδια μικρή καθυστέρηση. Για λόγους πρακτικότητας επιλέξαμε τη δομή της συνδεδεμένης λίστας (Linked List) που υπάρχει υλοποιημένη στην Java. Η συγκεκριμένη υλοποίηση προσφέρει επιδόσεις αντίστοιχες της διπλής συνδεδεμένης λίστας, ενώ χρησιμοποιεί τους λεγόμενους Iterators (αντικείμενα της Java για πρόσβαση σε στοιχεία δομών δεδομένων) για βελτίωση της ταχύτητας της απευθείας εισαγωγής στοιχείου στη θέση i σε χρόνο Ο(1), ενώ κανονικά απαιτεί χρόνο Ο(i) στην περίπτωση της Linked List. Η προσθήκη στοιχείου στο τέλος της είναι άμεση Ο(1). Αντίθετα, η εισαγωγή peer σε δέντρο είναι πολύ πιο αργή διαδικασία. Το κύριο μειονέκτημα της λίστας είναι ότι σε περίπτωση αποτυχίας (failure) ενός peer, μπορεί να καταρρεύσει (να πάψει να λαμβάνει δεδομένα) όλη η υπολίστα του peer. Σε αντίστοιχη περίπτωση σε ένα δέντρο, το υποδέντρο που επηρεάζεται περιέχει σαφώς μικρότερο αριθμό από peers, οπότε το πρόβλημα έχει μικρότερη έκταση, όπως φαίνεται και στο παρακάτω σχήμα. Αποτυχία ενός peer σε δέντρο & λίστα 52

53 Όταν μιλάμε για αποτυχία, εννοούμε την ανικανότητα του peer να λάβει ή/και να εκπέμψει πακέτα. Αυτό μπορεί να οφείλεται σε προβλήματα του δικτύου ή σε τοπικά προβλήματα του συγκεκριμένου peer. Η δομή του δέντρου υπερτερεί όσον αφορά την ανοχή σε τέτοια σφάλματα, αλλά η πολυπλοκότητα της υλοποίησής του είναι πολύ μεγαλύτερη. Εξάλλου, όπως θα δούμε στη συνέχεια, η χρήση MDC και οι έξυπνες τεχνικές για γρήγορη επίλυση αυτών των σφαλμάτων προσφέρουν απροβλημάτιστη μετάδοση ήχου και στην περίπτωση της λίστας. Βέβαια, η χρήση μιας συνδεδεμένης λίστας για τη μετάδοση του ήχου δεν φτιάχνει ένα P2P δίκτυο. Σε κάθε δομή ο κάθε peer παίρνει ήχο από τον προηγούμενο (Parent) και αναμεταδίδει στον επόμενο (Child), δηλαδή η μετάδοση είναι γραμμική. Το P2P γεννιέται με τη χρήση πολλών τέτοιων δομών μετάδοσης για την αποστολή ήχου σε πολλά Layers, όπως θα δούμε αμέσως παρακάτω. 2. Χρήση MDC & τοποθέτηση των peers στις δομές μετάδοσης Πολλαπλές περιγραφές ήχου Η χρήση MDC, δηλαδή η κωδικοποίηση του ήχου σε με πολλές ανεξάρτητες περιγραφές (Descriptions) δίνει εμμέσως την δομή του P2P στο δίκτυό μας. Μεταδίδοντας κάθε description ήχου σε διαφορετική δομή (layer), ο κάθε peer λαμβάνει πλέον ήχο από πολλούς peers και μεταδίδει επίσης σε πολλούς. Για παράδειγμα, στο παρακάτω σχήμα φαίνεται η περίπτωση της χρήσης τεσσάρων περιγραφών ήχου, οπότε κάθε peer συμμετέχει σε 4 δομές μετάδοσης. LAYER 1 LAYER 2 LAYER 3 LAYER 4 BROADCASTER BROADCASTER BROADCASTER BROADCASTER PEER 0 PEER 2 PEER 1 PEER 3 PEER 1 PEER 4 PEER 2 PEER 1 PEER 2 PEER 0 PEER 0 PEER 4 PEER 3 PEER 1 PEER 4 PEER 0 PEER 4 PEER 3 PEER 3 PEER 2 Μετάδοση ήχου MDC σε πολλές δομές (P2P μετάδοση) 53

54 Αν n είναι ο αριθμός των layers, τότε κάθε peer μπορεί να παίρνει ήχο από n διαφορετικούς peers και να στέλνει ήχο έως και σε n άλλους peers. Για τις ανάγκες τις εφαρμογής και εφόσον δεν υπήρχε διαθέσιμος μεγάλος αριθμός υπολογιστών, καταλήξαμε στη μελέτη της χρήσης 1-4 δομών. Όπως θα δούμε στο επόμενο κεφάλαιο, όσο αυξάνεται ο αριθμός των δομών (από 1 έως 4) τόσο βελτιώνεται η αξιοπιστία του δικτύου. Αυτό συμβαίνει γιατί πλέον κάθε peer συμμετέχει σε διαφορετικές δομές και βρίσκεται (κατά κανόνα) σε διαφορετική θέση σε κάθε δομή. Έτσι, ένα ενδεχόμενο σφάλμα σε έναν peer έχει διαφορετική βαρύτητα για κάθε δομή, που εξαρτάται από τη θέση του peer. Αυτό το βλέπουμε και στο παρακάτω σχήμα. LAYER 1 LAYER 2 LAYER 3 LAYER 4 BROADCASTER BROADCASTER BROADCASTER BROADCASTER PEER 0 PEER 2 PEER 1 PEER 3 PEER 1 PEER 4 PEER 2 PEER 1 PEER 2 PEER 0 PEER 0 PEER 4 PEER 3 PEER 1 PEER 4 PEER 0 PEER 4 PEER 3 PEER 3 PEER 2 Αποτυχία ενός peer σε P2P μετάδοση Βλέπουμε ότι αν αποτύχει ο Peer 4, αυτό δεν θα προκαλέσει κανένα πρόβλημα στους peers του πρώτου layer, ενώ θα οδηγήσει στην αποτυχία τρεις peers στο 2 ο layer, έναν στο 3 ο layer και δύο στο 4 ο layer. Πρέπει να τονίσουμε, ότι παρά την αποτυχία τους στα άλλα layers, οι peers συνεχίζουν να λαμβάνουν και να στέλνουν ήχο κανονικά στο 1 ο layer, καθώς και στα υπόλοιπα layers αν βρίσκονται σε θέση μικρότερη από τη θέση όπου εμφανίστηκε το σφάλμα. Εδώ λοιπόν φαίνεται και το μεγάλο πλεονέκτημα του MDC. Μπορούμε με κατάλληλο τρόπο να κωδικοποιήσουμε τον ήχο σε πολλά descriptions, ώστε κάθε description να αποτελεί μια πλήρη περιγραφή του αρχικού ήχου. Όταν λέμε πλήρης δεν εννοούμε να περιέχει όλη την ηχητική πληροφορία, αλλά ένα τμήμα της με τέτοιο τρόπο ώστε ακόμα και από 1 μόνο description να είναι δυνατή η αναπαραγωγή του αρχικού ήχου, έστω και με χαμηλότερη ποιότητα. Επιπλέον, όσα περισσότερα descriptions λαμβάνει κάποιος, τόσο καλύτερη ποιότητα ήχου ακούει. Αν λαμβάνει χωρίς πρόβλημα ήχο από όλα τα layers, δηλαδή λαμβάνει επιτυχώς όλα τα descriptions, τότε ακούει ήχο με τη μέγιστη δυνατή ποιότητα. Έτσι, στο παραπάνω παράδειγμα, οι Peer 0 και Peer 3 ακούνε τη χειρότερη ποιότητα, αφού λαμβάνουν 2 από τα 4 54

55 descriptions, ενώ οι Peer 2 και Peer 1 λαμβάνουν 3 από τα 4 descriptions και ακούνε πολύ καλής ποιότητας ήχο. Είδαμε στο προηγούμενο κεφάλαιο τις διάφορες τεχνικές κωδικοποίησης ήχου με MDC. Για τις ανάγκες της διπλωματικής επιλέξαμε μια απλή τεχνική για MDC, που όμως αρκεί για να επιβεβαιώσουμε την απόδοσή του. Συγκεκριμένα, προχωρήσαμε σε διαχωρισμό του αρχικού stream ήχου με δειγματοληψία, ανά byte ήχου, με ρυθμό ανάλογο του αριθμού των layers. Έτσι έχουμε ένα description για κάθε layer. Την τεχνική αυτή την περιγράψαμε με λεπτομέρεια στο 2 ο κεφάλαιο. Τώρα θα δούμε πως δουλεύει στην πράξη. Στην περίπτωση των τεσσάρων layers, γίνεται διαίρεση του αύξοντα αριθμού του κάθε πακέτου με το 4 και το υπόλοιπο της διαίρεσης συγκρίνεται με το 1, 2, 3 και 4 για να προσδιοριστεί αν ανήκει στο 1 ο, 2 ο, 3 ο ή 4 ο layer αντίστοιχα. Μπορεί πιο εύκολα να καταλάβει κάποιος τη λογική του χωρισμού σε layers με το παρακάτω σχήμα. ΑΡΧΙΚΟ STREAM ΗΧΟΥ LAYER LAYER LAYER LAYER 4 Δημιουργία πολλαπλών περιγραφών ήχου με χρήση 4 layers Καθένα από τα 4 descriptions που δημιουργούνται με αυτήν την τεχνική MDC περιέχει το ¼ της πληροφορίας του αρχικού ήχου. Αν κάποιος ακούσει τον ήχο που παράγει 1 description, σίγουρα δε θα μείνει ικανοποιημένος από την ποιότητα, αλλά τα ζητούμενο είναι να επιτύχουμε τη βελτίωση του ήχου ελαχιστοποιώντας την πιθανότητα να χαθεί κάποιο από τα descriptions. Έτσι, ακόμα κι αν γίνει λήψη μόνο τριών descriptions, ο χρήστης θα ακούει τα ¾ της πληροφορίας, δηλαδή ήχο χαμηλότερης ποιότητας, χωρίς τα προβλήματα που θα υπήρχαν χωρίς τη χρήση MDC. Ποια είναι αυτά τα προβλήματα όμως; Ας το δούμε με ένα ακόμα παράδειγμα. Στο σχήμα που ακολουθεί υποθέτουμε ότι, μετά την επιτυχή μετάδοση των τριών πρώτων πακέτων του δικτύου, εμφανίζεται ένα μεμονωμένο πρόβλημα στη σύνδεση του Peer 1 με τον Peer 2 που 55

56 οδηγεί στην απώλεια των τριών επόμενων μεταξύ τους πακέτων. Εξετάζουμε τι θα συμβεί στον Peer 2, όταν παρουσιαστεί το πρόβλημα. Αδυναμία σύνδεσης Peer 1 & Peer 2 και απώλεια τριών πακέτων, με ή χωρίς MDC Στην περίπτωση που έχουμε γραμμική μετάδοση από peer σε peer (στην ουσία έχουμε μόνο 1 layer) παύει να υφίσταται το MDC. Αν μετά τα τρία πρώτα πακέτα ο Peer 1 αποτύχει να στείλει τα 3 επόμενα στον Peer 2, βλέπουμε ότι θα υπάρξει ένα συσσωρευμένο σφάλμα στον Peer 2, αφού τον ακολουθεί στη δομή μετάδοσης. Αυτό θα έχει ως αποτέλεσμα μια σύντομη διακοπή στον ήχο. Αντίθετα, αν έχουμε MDC με 4 layers μετάδοσης, τότε σε περίπτωση που ο Peer 2 έπεται του Peer 1 (για χάριν απλότητας) μόνο στο πρώτο layer, θα χάσει τα 3 επόμενα πακέτα του πρώτου layer, ενώ θα λάβει κανονικά τα πακέτα από τα άλλα layers. Βλέπουμε ότι η χρήση MDC θα οδηγήσει στη διασπορά του σφάλματος, ελαττώνοντας την ποιότητα του ήχου, αλλά αποτρέποντας μια ενοχλητική διακοπή κατά την αναπαραγωγή. 56

57 Το συγκεκριμένο παράδειγμα είναι αρκετά απλοϊκό, αλλά είναι ενδεικτικό της κατάστασης που δημιουργεί η αποτυχία σύνδεσης μεταξύ δύο peers και του πως αντιμετωπίζεται με το MDC. Τοποθέτηση των peers στις δομές μετάδοσης Αυτό που δεν έχουμε αναφέρει ως τώρα είναι με ποιον τρόπο αποφασίζεται η θέση κάθε peer στις δομές μετάδοσης. Ήδη από τις πρώτες δοκιμές του δικτύου με μόνο ένα layer θέλαμε η τοποθέτηση να γίνεται με κριτήριο την ταχύτητα/απόκριση, ώστε πιο ψηλά στη δομή να βρίσκονται οι πιο γρήγοροι peers. Έτσι, θα αποφεύγαμε την περίπτωση ένας αργός peer να βρίσκεται ψηλά στη δομή και να καθυστερεί τη λήψη ήχου για τους υπόλοιπους. Προχωρήσαμε λοιπόν στην υλοποίηση μιας μεθόδου υπολογισμού της θέσης με βάση τη μέτρηση των χρόνων απόκρισης (Round Trip Time - RTT) μεταξύ των peers. Όταν ένας peer θέλει να μπει στο δίκτυο ενός broadcaster (να γίνει listener), ο broadcaster του στέλνει τη λίστα των IP των peers που είναι ήδη συνδεδεμένοι, καθώς και το RTT που έχει κάθε peer με τον προηγούμενό του στη δομή μετάδοσης. Ο peer στέλνει 10 πακέτα (όπως θα δούμε παρακάτω, τα ονομάσαμε πακέτα Ping-Pong) μετρώντας το RTT με κάθε peer (και με τον broadcaster) και κρατάει τους μέσους όρους των χρόνων που μέτρησε. Η μέτρηση δεν είναι απόλυτα ακριβής, αλλά ενδεικτική της απόκρισης των peers. Στη συνέχεια ο peer βρίσκει τη θέση στην οποία πρέπει να μπει στην πρώτη δομή μετάδοσης συγκρίνοντας τους δικούς του χρόνους RTT με τους χρόνους των άλλων peers, συνυπολογίζοντας κι έναν εμπειρικό συντελεστή βαρύτητας. Ας δούμε ένα παράδειγμα. Έστω η παρακάτω δομή μετάδοσης με τον broadcaster και 2 listeners. O listener 3 που έρχεται, μετράει το RTT με τον broadcaster (RTT03), τον listener 1 (RTT13) και τον listener 2 (RTT23). Ας εξετάσουμε την περίπτωση του ελέγχου αν θα γίνει παιδί του listener 1. Αυτό θα συμβεί μόνο αν ισχύει η σχέση: Αυτό το επιλέξαμε γιατί δεν θέλαμε ο listener 2, ενώ είχε ένα καλό RTT με τον γονέα του, να έχει τώρα χειρότερο με την είσοδο του listener 3. Τον συντελεστή βάρους W τον χρησιμοποιούμε επειδή δεν θέλουμε με την παραμικρή διαφορά (π.χ. 49ms < 50ms) να γίνεται αλλαγή. Κάτι τέτοιο όχι μόνο είναι άσκοπο, αλλά προσθέτει και χωρίς λόγο overhead στο δίκτυο. Χρησιμοποιώντας λοιπόν έναν συντελεστή W, τον οποίο ρυθμίζουμε κατά βούληση ώστε να ανιχνεύουμε μεγάλες ή μικρές διαφορές των RTT, αποφασίζουμε την τοποθέτηση του νέου 57

58 listener. Παρακάτω φαίνονται οι δύο πιθανές τοποθετήσεις του listener 3, ανάλογα με την τιμή του RTT του. Τοποθέτηση του listener 3 στη βασική δομή, ανάλογα με το RTT Αυτή η δομή ονομάζεται βασική δομή και έχει μεγαλύτερη βαρύτητα γιατί παρέχει μια στοιχειώδη ιεραρχική ταξινόμηση των peers. Επειδή θέλαμε οι peers να μπαίνουν στις διάφορες δομές σε μπερδεμένες θέσεις και όχι στις ίδιες, η είσοδος στις άλλες δομές γίνεται τυχαία. Σίγουρα δεν είναι μια μέθοδος χωρίς προβλήματα σε μεγάλης κλίμακας δίκτυα, αλλά για τις ανάγκες των μετρήσεων της διπλωματικής αυτός είναι ένας από τους δύο συμβιβασμούς που κάναμε (ο άλλος είναι η χρήση της λίστας που αναφέραμε παραπάνω). 3. Τεχνικές Forward Error Correction και Επαναποστολή πακέτων Forward Error Correction (FEC) Η χρήση MDC από μόνη της δεν επιδιορθώνει προβλήματα. Απλά κάνει μια κατάσταση πιο ανεκτή. Το παρατηρήσαμε κατά την αποστολή ήχου κωδικοποίησης PCM, όπου όταν η απώλεια πακέτων ήταν σε φυσιολογικά επίπεδα (1-2%) δεν είχαμε διακοπές στον ήχο. Όταν όμως περάσαμε στην κωδικοποίηση MP3 είδαμε ότι, λόγω συμπίεσης, η απώλεια ενός πακέτου ισοδυναμούσε με απώλεια δεκαπλάσιας πληροφορίας ήχου! Συνεπώς, για χρήση ήχου MP3 είδαμε ότι δεν υπήρχε άλλη επιλογή από την 100% σωστή μετάδοση του ήχου. Για την αντιμετώπιση αυτού του νέου προβλήματος χρειάστηκε να μελετήσουμε διάφορες τεχνικές FEC. Καταλήξαμε στη λύση της ανακατασκευής των χαμένων πακέτων στη μεριά του παραλήπτη, με χρήση πλεονάζουσας πληροφορίας την οποία θα διοχετεύαμε στο δίκτυο. Επιλέξαμε μια απλή τεχνική που προσθέτει 50% περισσότερη πληροφορία στο stream που μεταδίδεται, αλλά μπορεί να αντιμετωπίσει διεσπαρμένες απώλειες πακέτων μέχρι και 5% (99% πιθανότητα ανακατασκευής του χαμένου πακέτου). Όπως θα δούμε και στο κεφάλαιο των μετρήσεων, η μέση απώλεια πακέτων που συναντήσαμε ήταν πολύ χαμηλότερη. 58

59 Η λογική που ακολουθήσαμε είναι να στέλνουμε ένα παραπάνω πακέτο, μετά την αποστολή δύο πακέτων ήχου. Αυτό το τρίτο πακέτο δεν περιέχει καθαρό ήχο, αλλά το λογικό XOR των bytes των δύο προηγούμενων πακέτων. Έτσι, αν χαθεί κάποιο από τα δύο προηγούμενα πακέτα και ληφθεί επιτυχώς το πακέτο XOR, είναι δυνατή η ανακατασκευή του χαμένου πακέτου, κάνοντας τη λογική πράξη XOR μεταξύ των δυο πακέτων που απέμειναν. Το πακέτο αυτό θυμίζει τα bit ισοτιμίας που με την ίδια λογική χρησιμοποιούνται στην επικοινωνία των υπολογιστών, γι αυτό το ονομάζουμε πακέτο ισοτιμίας (Parity). FEC με προσθήκη πακέτων ισοτιμίας τύπου XOR Μετά την αναδημιουργία του stream μετάδοσης, που πλέον περιέχει και την πλεονάζουσα πληροφορία, ο αύξοντας αριθμός κάθε πακέτου (ομάδας από bytes) του stream αλλάζει ώστε να δείχνει την πραγματική διαδοχή των πακέτων που στέλνει ο Broadcaster. Το τελικό stream είναι αυτό που στέλνει το δίκτυό μας, ενώ με βάση τον αύξοντα αριθμό του, κάθε πακέτο αποστέλλεται στο αντίστοιχο layer. Δηλαδή, το MDC που εφαρμόσαμε προηγουμένως στο αρχικό stream, πλέον εφαρμόζεται στο τελικό stream μετάδοσης. Προφανώς, μετά την παραλαβή του stream και την ανακατασκευή τυχόν χαμένων πακέτων, τα πακέτα ισοτιμίας αφαιρούνται για να οδηγηθεί η καθαρή πληροφορία ήχου προς την αναπαραγωγή. Η ανακατασκευή χαμένων πακέτων φαίνεται στο παρακάτω σχήμα. Ανακατασκευή χαμένων πακέτων (1 & 6) με χρήση των πακέτων ισοτιμίας Πρέπει εδώ να σημειώσουμε ότι πλέον το stream του ήχου που μεταδίδουμε έχει γίνει από 64Kbps, 96Kbps. Η πληροφορία που προσθέτει το FEC δεν είναι αμελητέα. Το αντίθετο 59

60 μάλιστα. Αλλά τα οφέλη της χρήσης του είναι μεγάλα, ενώ οι τυπικές DSL συνδέσεις σήμερα επιτρέπουν αρκετά μεγαλύτερες ταχύτητες upload, ώστε το μέγεθος του stream να μην αποτελεί πρόβλημα. Επαναποστολή χαμένων πακέτων & χρήση buffers Διαδικασία επαναποστολής Η διαδικασία ανακατασκευής είναι ιδιαίτερα απλή και γρήγορη. Αποδίδει όμως μόνο όταν έχουν χαθεί μεμονωμένα πακέτα, όπως στην παραπάνω περίπτωση, ενώ δεν μπορεί να αποδώσει όταν έχουν χαθεί πολλά μαζεμένα πακέτα (loss burst). Στην περίπτωση που χαθούν ριπές πακέτων, κάτι που οφείλεται συνήθως σε στιγμιαία προβλήματα της σύνδεσης των peers στο internet, πρέπει να προβούμε σε άλλες λύσεις. Τονίζουμε για δεύτερη φορά ότι για μας η απώλεια ενός και μόνο πακέτου είναι σημαντική και θέλουμε να την αποτρέψουμε. Ήταν μονόδρομος λοιπόν, όταν όλοι οι άλλοι μέθοδοι αποτυγχάνουν, να προχωρήσουμε σε επαναποστολή των χαμένων πακέτων. Για το λόγο αυτό οι peers και ο broadcaster που πραγματοποιεί τη μετάδοση διατηρούν buffers με τα πακέτα ήχου. Όταν απαιτείται η επαναποστολή ενός χαμένου πακέτου από τον peer, αυτός το ζητάει (1η προσπάθεια) από τον γονέα του στη δομή του Layer 1 (κάναμε δοκιμές με 1 έως 4 layers, οπότε μόνο το layer 1 υπήρχε πάντα). Αν δεν βρεθεί εκεί το πακέτο, ο γονέας ενημερώνει τον peer για την αποτυχημένη αναζήτηση. Εν τω μεταξύ, επειδή οι διαδικασίες ανακατασκευής και επαναποστολής των peers είναι κοντά μεταξύ τους, μπορεί κατά τη διάρκεια της αναζήτησης στον buffer του, ο γονέας να έλαβε το χαμένο πακέτο χωρίς να προλάβει να ενημερώσει τον buffer. Τότε η αναζήτηση αποτυγχάνει, παρόλο που το πακέτο υπάρχει. Γι αυτό ο peer ζητάει ξανά το χαμένο πακέτο από τον γονέα του (2η προσπάθεια). Η εμπειρία μας λέει ότι στο 95% των περιπτώσεων η 2 η αναζήτηση είναι επιτυχής και μόνο σε ένα 5% των περιπτώσεων απαιτείται τρίτη προσπάθεια. Παρόλα αυτά, αν πάλι αποτύχει η επαναποστολή του πακέτου, ο peer ζητάει το χαμένο πακέτο από τον γονέα του γονέα του (3η προσπάθεια). Η πιθανότητα να μην υπάρχει το πακέτο ούτε εκεί είναι πολύ μικρή. Σε περίπτωση που δεν βρεθεί, το πακέτο θεωρείται οριστικά χαμένο και δεν επιχειρείται ξανά επαναποστολή του. Λειτουργία των buffers Ο buffer του broadcaster περιέχει όλα τα πακέτα που έχει στείλει, δηλαδή τα πακέτα ήχου και τα πακέτα ισοτιμίας. Οι buffers των peers περιέχουν μόνο τα καθαρά πακέτα ήχου, καθώς ακόμα κι αν κάποιος χάσει ένα πακέτο ήχου, είναι παράλογο να αναζητήσει το πακέτο ισοτιμίας. Απλά θα ζητήσει να του επαναποσταλεί το πακέτο ήχου που έχασε. Κατά την ανάπτυξη των μεθόδων επαναποστολής των πακέτων παρατηρήσαμε ότι πολλές φορές η επαναποστολή αποτύγχανε λόγω μεγάλης καθυστέρησης κατά την αναζήτηση του χαμένου πακέτου στους buffers (οπότε συνέβαινε τεχνητό timeout). Αυτό συμβαίνει γιατί 60

61 δεν θέλαμε η διαδικασία αυτή να καθυστερεί την αναπαραγωγή του ήχου, οπότε έπρεπε να υπάρχει χρονικό όριο. Σε περίπτωση που ξεπεραστεί το όριο, η επαναποστολή θεωρείται αποτυχημένη. Θέλαμε να διατηρούμε σχετικά μεγάλο το μέγεθος των buffers, ώστε ένα πακέτο που δεν μπορεί να ανακατασκευαστεί από έναν peer, να υπάρχει με μεγάλη πιθανότητα στον γονέα του. Έπρεπε λοιπόν να βρούμε μια κατάλληλη δομή για τους buffers που να προσφέρει γρήγορη αναζήτηση παρά το μεγάλο μέγεθος. Καταλήξαμε στη χρήση i) μιας τροποποιημένης εκδοχής της συνδεδεμένης λίστας της Java ως βάση του buffer (Audio buffer) και ii) μιας τροποποιημένης εκδοχής του αλγορίθμου binary search για την αναζήτηση στους buffers (Smart Search). Συγκεκριμένα: i. Audio Buffer: Ο Audio Buffer είναι μια τροποποίηση της java.util.linkedlist που δέχεται ως στοιχεία της τα πακέτα ήχου (bytes ήχου + αύξοντας αριθμός των bytes). Έχει Ο(1) ταχύτητα εισαγωγής στα άκρα και Ο(1) ταχύτητα αναζήτησης όταν τα δεδομένα του είναι ταξινομημένα και ακέραια. Δηλαδή, στην περίπτωση του buffer του broadcaster, που περιέχει όλα τα πακέτα ταξινομημένα, πρακτικά δεν χρειάζεται αναζήτηση. Απλά επιστρέφεται το πακέτο που ζητείται για επαναποστολή απευθείας με χρήση του αύξοντα αριθμού του. ii. Smart Search: Επειδή στην περίπτωση του listener ο buffer είναι ταξινομημένος αλλά δεν περιέχει όλα τα πακέτα (λείπουν τα πακέτα ισοτιμίας και πακέτα που έχουν χαθεί κι έχει αποτύχει η ανακατασκευή και επαναποστολή τους) δεν μπορεί να γίνει απευθείας πρόσβασης στα στοιχεία. Θεωρώντας ότι ο αριθμός των πακέτων που χάνονται οριστικά είναι μηδαμινός, μπορούμε να πούμε ότι ανά πάσα στιγμή ο buffer του listener έχει τα 2/3 των πακέτων που έχουν αποσταλεί (εφόσον τα πακέτα ήχου είναι τα 2/3 του συνολικού αριθμού πακέτων, ενώ το υπόλοιπο 1/3 είναι τα πακέτα ισοτιμίας). Γι αυτό, αντί να αναζητούμε το χαμένο πακέτο σε ολόκληρο τον buffer, ξεκινάμε την αναζήτηση (binary search) στη θέση: = έ έ ώ ί Επιπλέον, περιορίζουμε την αναζήτηση σε εύρος δύο χιλιάδων πακέτων, στο σύνολο: [, + ] Έτσι, η αναζήτηση είναι ταχύτατη. Όταν ο buffer έχει λίγα στοιχεία (λιγότερα από 2000) η αναζήτησή binary search υπερτερεί λίγο (εξ αιτίας κάποιων εσωτερικών ελέγχων της Smart Search), αλλά μετά τα 9000 στοιχεία η ταχύτητα αναζήτησης της Smart Search είναι σταθερή (περίπου 1,7ms) ενώ της binary search είναι πάντα Ο(log 2 n). Ένα εύλογο ερώτημα είναι αν πραγματικά χρειάζεται ένας τόσο μεγάλος buffer. Η απάντηση είναι όχι! Για τις ανάγκες όμως της διπλωματικής (μετρήσεις, κλπ) και για να εκμηδενίσουμε την πιθανότητα μη εύρεσης ενός χαμένου πακέτου σε κάποιον buffer, θέλαμε να κρατάμε αρκετά πακέτα στον buffer. Εξάλλου, ήταν πρόκληση για μας και ευχάριστη διαδικασία η εύρεση της λύσης στο πρόβλημα της αργής αναζήτησης. 61

62 Έχοντας μελετήσει τις αρχές λειτουργίας του Peer ως μέλος ενός P2P δικτύου, προχωράμε στην περιγραφή της λειτουργίας της εφαρμογής με παρουσίαση των λειτουργικών διαγραμμάτων των κυριοτέρων διεργασιών του Peer. Λογικά Διαγράμματα Λογικό διάγραμμα κεντρικής λειτουργίας του Peer ΕΝΕΡΓΟΠΟΙΗΣΗ ΚΟΥΜΠΙΟΥ ΚΛΕΙΣΙΜΑΤΟΣ ΠΑΤΗΜΑ ΚΟΥΜΠΙΟΥ ΚΛΕΙΣΙΜΑΤΟΣ ΑΡΧΗ ΤΕΛΟΣ ΠΑΤΗΜΑ ΚΟΥΜΠΙΟΥ ΑΠΟΣΥΝ ΕΣΗΣ ΠΑΤΗΜΑ ΚΟΥΜΠΙΟΥ ΣΥΝ ΕΣΗΣ ΕΝΕΡΓΟΠΟΙΗΣΗ ΚΟΥΜΠΙΟΥ ΑΠΟΣΥΝ ΕΣΗΣ ΟΧΙ CONNECT TO NETWORK ΕΚΚΙΝΗΣΗ THREAD ΕΞΥΠΗΡΕΤΗΣΗΣ ΠΑΚΕΤΩΝ PACKET HANDLER ΣΥΝ ΕΣΗ ΕΠΙΤΥΧΗΣ; ΝΑΙ ΕΚΚΙΝΗΣΗ THREAD ΕΞΥΠΗΡΕΤΗΣΗΣ SOCKET SOCKET HANDLER ΚΥΡΙΟ THREAD ΝΑΙ ΕΚΚΙΝΗΣΗ THREAD ΑΝΑΜΕΤΑ ΟΣΗΣ ΧΑΜΕΝΩΝ ΠΑΚΕΤΩΝ RETRANSMIT HANDLER ΑΝΑΜΟΝΗ ΛΙΣΤΑΣ BROADCASTERS ΟΧΙ ΠΑΤΗΜΑ ΚΟΥΜΠΙΟΥ BROADCAST ΕΚΚΙΝΗΣΗ ΛΕΙΤΟΥΡΓΙΑΣ BROADCASTER ΛΙΣΤΑ BROADCASTERS ΕΛΗΦΘΗ; NAI ΕΝΕΡΓΟΠΟΙΗΣΗ ΛΕΙΤΟΥΡΓΙΩΝ BROADCASTING & LISTENING ΠΑΤΗΜΑ ΚΟΥΜΠΙΟΥ LISTEN ΕΚΚΙΝΗΣΗ ΛΕΙΤΟΥΡΓΙΑΣ LISTENER 62

63 Στο παραπάνω διάγραμμα βλέπουμε με λεπτομέρεια τι συμβαίνει όταν ξεκινάει η εφαρμογή και ο χρήστης πραγματοποιεί τα 2 βήματα που αναφέραμε. Με πορτοκαλί χρώμα φαίνονται τα τρία thread (handlers) που ανοίγουν όταν γίνεται η σύνδεση στο δίκτυο, ενώ με μωβ χρώμα οι διαδικασίες λειτουργίας της εφαρμογής ως Broadcaster και ως Listener. Αναλυτικά αυτές οι διαδικασίες παρουσιάζονται η καθεμιά στο δικό της λειτουργικό διάγραμμα. Λογικό διάγραμμα Packet Handler 63

64 Ως Packet Handler έχουμε ονομάσει το thread που διαχειρίζεται τα UDP πακέτα που φτάνουν στον Peer. Περιμένει συνεχώς πακέτα στην πόρτα 5557 και όταν λάβει ένα πακέτο, ελέγχει το header του, ο οποίος δείχνει το αίτημα του αποστολέα, και προχωράει στις κατάλληλες ενέργειες για την εξυπηρέτηση του αιτήματος. Ας δούμε πιο αναλυτικά τα πακέτα που μπορεί να έρθουν και φαίνονται συνοπτικά στο λειτουργικό διάγραμμα: ECHO : Πρόκειται για το πακέτο που στέλνει ο server στον peer για να επιβεβαιώσει την ύπαρξή του στο δίκτυο. Ο peer απαντάει με ένα ίδιο πακέτο ECHO. BRTS : O peer ξεκινάει την παραλαβή του πίνακα των broadcasters από τον server. Αρχικοποιεί τον πίνακα και περιμένει τις IP των broadcasters που θα έρθουν με πακέτα τύπου BRIP. BRIP : Πακέτο που περιέχει την διεύθυνση ΙΡ ενός broadcaster. Ο peer διαβάζει την ΙΡ που περιέχεται στα δεδομένα του πακέτου και την προσθέτει στον πίνακα των broadcaster. BRTE : Τελειώνει η παραλαβή των IPs των broadcasters. Δεν θα ακολουθήσει άλλο πακέτο τύπου BRIP, οπότε ενημερώνεται η λίστα των broadcasters του GUI ώστε ο χρήστης να μπορεί να επιλέξει όποιον θέλει. BEND : Πακέτο που στέλνει ο broadcaster σε όλους τους listeners του για να τους ενημερώσει ότι η μετάδοσή του σταμάτησε/τελείωσε. Η εφαρμογή βγαίνει από την κατάσταση λειτουργίας ως listener. PING : Πακέτο που στέλνει ένας peer σε έναν άλλο (ή στον broadcaster) για να μετρήσει το RTT μεταξύ τους. Ο peer που το λαμβάνει απαντάει με αποστολή ενός πακέτου τύπου PONG προς την Ping Port (την πόρτα που χρησιμοποιείται για μέτρηση του RTT). Η πόρτα που χρησιμοποιούμε είναι η AUDP : Είναι ο header του πακέτου ήχου. Όταν ληφθεί ένα πακέτο ήχου, τότε πρώτα τα δεδομένα που περιέχει (α/α πακέτου και bytes ήχου ή ισοτιμίας) αποθηκεύονται σε έναν προσωρινό buffer πριν οδηγηθούν στον player και έπειτα αναμεταδίδεται το πακέτο στο παιδί του peer στην κατάλληλη δομή μετάδοσης. Ελέγχεται ο α/α του πακέτου ήχου και αποφασίζεται σε ποια δομή πρέπει να σταλεί. 64

65 Λογικό διάγραμμα Socket Handler ΟΧΙ THREAD ΕΞΥΠΗΡΕΤΗΣΗΣ SOCKET ΗΜΙΟΥΡΓΙΑ TCP SOCKET SOCKET ΣΥΝ ΕΘΗΚΕ; NAI ΑΝΟΙΓΜΑ STREAM ΑΝΑΓΝΩΣΗΣ Ε ΟΜΕΝΩΝ ΑΠO ΤΗ SOCKET ΕΛΕΓΧΟΣ ΤΩΝ 4 ΠΡΩΤΩΝ ΧΑΡΑΚΤΗΡΩΝ ΤΟΥ STREAM POSITIONING INFORMATION INFO ΑΝΑΓΝΩΣΗ Ε ΟΜΕΝΩΝ ΤΟΥ STREAM (IPs) ΑΛΛΑΓΗ ΤΩΝ IPs ΤΩΝ ΠΑΙ ΙΩΝ ΤΟΥ PEER ΣΤΗ ΟΜΗ ΜΕΤΑ ΟΣΗΣ PEER WANTS TO BECOME LISTENER PEER WANTS TO STOP LISTENING LISS LISE ΑΠΟΣΤΟΛΗ ΤΟΥ ΠΙΝΑΚΑ ΟΜΗΣ ΣΤΟΝ PEER ΜΕΣΩ ΤΟΥ SOCKET ΑΦΑΙΡΕΣΗ ΤΟΥ PEER ΑΠΟ ΤΗ ΟΜΗ ΜΕΤΑ ΟΣΗΣ ΑΛΛΑΓΗ ΤΩΝ IPs ΤΩΝ ΠΑΙ ΙΩΝ ΤΟΥ PEER ΣΤΗ ΟΜΗ ΜΕΤΑ ΟΣΗΣ ΕΝΗΜΕΡΩΣΗ ΥΠΟΛΟΙΠΩΝ PEERS ΓΙΑ ΤΥΧΟΝ ΑΛΛΑΓΕΣ ΑΠΟΣΥΝ ΕΣΗ SOCKET PEER IS SENDING POSITIONING DATA LISP ΚΛΕΙΣΙΜΟ ΤΟΥ ΠΙΑΝΑΚA ΤΩΝ BROADCASTERS & ΕΝΗΜΕΡΩΣΗ GUI ΠΡΟΣΘΗΚΗ ΤΟΥ PEER ΣΤΗ ΟΜΗ ΜΕΤΑ ΟΣΗΣ ΕΝΗΜΕΡΩΣΗ ΥΠΟΛΟΙΠΩΝ PEERS ΓΙΑ ΤΥΧΟΝ ΑΛΛΑΓΕΣ Socket Handler έχουμε ονομάσει το thread που διαχειρίζεται τις TCP συνδέσεις μεταξύ των peers. Περιμένει συνεχώς TCP συνδέσεις στην πόρτα Όταν γίνει μια σύνδεση ανοίγει ένα stream ανάγνωσης δεδομένων από το socket. Διαβάζει τα 4 πρώτα bytes που δείχνουν το αίτημα προς εξυπηρέτηση και προχωράει στις κατάλληλες ενέργειες για την εξυπηρέτησή του. Με μωβ χρώμα φαίνονται τα αιτήματα που δέχεται ο broadcaster και με γαλάζιο τα αντίστοιχα για τον listener. Τα αιτήματα που μπορεί να διαχειριστεί ο socket handler είναι 4: INFO : Σημαίνει ότι το socket άνοιξε για να λάβει ο listener πληροφορίες σχετικά με τα παιδιά του στις δομές μετάδοσης, ώστε να μπορεί να πραγματοποιεί τη σωστή αναμετάδοση των πακέτων ήχου. Λαμβάνονται οι IPs των παιδιών του peer σε κάθε δομή και το socket κλείνει. LISS : Σημαίνει ότι το socket άνοιξε (στη μεριά του broadcaster) γιατί ένας peer θέλει να γίνει listener. Ο broadcaster του στέλνει (μέσω του TCP socket) τις IPs των listeners και τα μεταξύ τους RTT στη βασική δομή μετάδοσης. LISE : Σημαίνει ότι ο listener που το στέλνει θέλει να φύγει από το δίκτυο. Είναι κρίσιμο να μη χαθεί αυτή η πληροφορία, γι αυτό και στέλνεται μέσω TCP. Ο broadcaster αφαιρεί τον peer από τις δομές μετάδοσης και ενημερώνει τους peers που είναι απαραίτητο σχετικά με τις αλλαγές των παιδιών τους στις δομές. LISP : Σημαίνει ότι ο peer έχει υπολογίσει τη θέση στην οποία πρέπει να μπει σε κάθε δομή και στέλνει τις σχετικές πληροφορίες στον broadcaster. Ο τελευταίος προσθέτει 65

66 τον peer σε κάθε δομή στην κατάλληλη θέση και ενημερώνει όσους peers χρειάζεται σχετικά με τις αλλαγές. Λογικό διάγραμμα Retransmit Handler THREAD ΑΠΟΣΤΟΛΗΣ ΧΑΜΕΝΩΝ ΠΑΚΕΤΩΝ ΗΜΙΟΥΡΓΙΑ DATAGRAM SOCKET (RETRANSMIT HANDLING PORT) ΛΕΙΤΟΥΡΓΙΑ ΩΣ BROADCASTER ΕΛΕΓΧΟΣ ΤΡΟΠΟΥ ΛΕΙΤΟΥΡΓΙΑΣ ΑΝΑΖΗΤΗΣΗ ΧΑΜΕΝΟΥ ΠΑΚΕΤΟΥ ΣΤΟΝ BUFFER ΤΟΥ TRANSMITTER ΤΟ ΠΑΚΕΤΟ ΒΡΕΘΗΚΕ; ΝΑΙ ΑΠΟΣΤΟΛΗ ΤΟΥ ΠΑΚΕΤΟΥ ΣΤΟΝ PEER ΠΟΥ ΤΟ ΖΗΤΗΣΕ ΑΠΟΣΤΟΛΗ ΜΗΝΥΜΑΤΟΣ ΑΠΟΤΥΧΗΜΕΝΗΣ ΑΝΑΖΗΤΗΣΗΣ ΤΕΡΜΑΤΙΣΜΟΣ THREAD ΕΞΥΠΗΡΕΤΗΣΗΣ ΤΟΥ ΠΑΚΕΤΟΥ ΟΧΙ ΠΑΚΕΤΟ ΕΛΗΦΘΗ; NAI ΛΕΙΤΟΥΡΓΙΑ ΩΣ LISTENER ΑΝΑΖΗΤΗΣΗ ΧΑΜΕΝΟΥ ΠΑΚΕΤΟΥ ΣΤΟΝ BUFFER ΤΟΥ PLAYER ΝΑΙ ΤΟ ΠΑΚΕΤΟ ΒΡΕΘΗΚΕ; ΕΝΗΜΕΡΩΣΗ ΤΟΥ PEER ΝΑ ΖΗΤΗΣΕΙ ΤΟ ΠΑΚΕΤΟ ΑΠO ΑΛΛΟΝ LISTENER ΕΞΥΠΗΡΕΤΗΣΗ ΣΕ ΝΕΟ THREAD Ο Retransmit Handler είναι το thread που φροντίζει για την εύρεση και αποστολή ενός πακέτου που έχει χαθεί από κάποιον listener και ζητείται η επαναποστολή του. Όταν λάβει ένα αίτημα (πακέτο) ανοίγει νέο thread για την εξυπηρέτησή του. Διαβάζει την πληροφορία που περιέχεται, δηλαδή τον αύξοντα αριθμό του πακέτου που πρέπει να αναζητηθεί. Έπειτα ελέγχει αν η εφαρμογή βρίσκεται σε λειτουργία broadcasting ή listening. Αν είναι broadcaster, αναζητά το πακέτο στον buffer αποστολής, ενώ αν είναι listener το αναζητά στον ταξινομημένο buffer πακέτων που διατηρεί, με χρήση της Smart Search που είδαμε σε προηγούμενη παράγραφο. Αν βρεθεί το πακέτο το στέλνει. Αλλιώς, αν είναι listener και το πακέτο δεν βρεθεί στον buffer του, τον παραπέμπει στον γονέα του για να αναζητήσει ξανά το πακέτο. Αν είναι broadcaster και το πακέτο δεν βρεθεί (έχει σβηστεί από τον buffer) του στέλνει μήνυμα αποτυχίας. Η επαναποστολή γίνεται προς την Retransmit Request Port, την πόρτα που ανοίγει ο listener για αυτόν ακριβώς το σκοπό. Η πόρτα που χρησιμοποιείται είναι η Ο Retransmit Handler χρησιμοποιεί για την παραλαβή των αιτημάτων την 5558 (Retransmit Handling Port). Έχοντας περιγράψει τα thread εξυπηρέτησης που χρησιμοποιεί η εφαρμογή, προχωράμε στην περιγραφή του τρόπου λειτουργίας ως Broadcaster και ως Listener. 66

67 Λογικό διάγραμμα Broadcaster Ο Broadcaster είναι το αντικείμενο που χειρίζεται τις διαδικασίες μετάδοσης του ήχου. Αυτές είναι δύο: το γέμισμα του buffer ήχου με bytes που διαβάζονται από ένα τραγούδι (ένα αρχείο MP3 ή PCM) και η δημιουργία πακέτων ήχου από τα στοιχεία του buffer και αποστολή τους στους πρώτους peers των δομών μετάδοσης. Οι δύο διεργασίες λειτουργούν σε διαφορετικά threads. 67

68 Λογικό διάγραμμα Listener Παρατηρώντας το διάγραμμα του Listener είναι φανερό γιατί χαρακτηρίσαμε τα δύο αυτά αντικείμενα δυαδικά. Ο Listener χειρίζεται, ακριβώς αντίστοιχα με τον Broadcaster, τις διαδικασίες παραλαβής και αναπαραγωγής του ήχου. Έχει κι αυτός δύο threads που τρέχουν παράλληλα. Το ένα συνεχώς παίρνει τα πακέτα του buffer πακέτων ήχου και τα ταξινομεί, εφαρμόζει τεχνικές ανακατασκευής και ζητάει, αν χρειάζεται, επαναποστολή τους. Αφού φροντίσει για την ακεραιότητά τους, αποθηκεύει τα ταξινομημένα πακέτα στον buffer ήχου. Το άλλο thread παίρνει συνεχώς δεδομένα (ήχο) από τον buffer ήχου και τον οδηγεί στην έξοδο του ήχου για αναπαραγωγή. 68

69 Εικόνες λειτουργίας της εφαρμογής Κλείνοντας το κεφάλαιο, παραθέτουμε μερικές εικόνες από τη λειτουργία της εφαρμογής Peer. Στο επόμενο κεφάλαιο θα δούμε πια στην πράξη τα αποτελέσματα του σχεδιασμού της εφαρμογής μας. Λειτουργία εφαρμογής σε περιβάλλον Mac OSX (skin συστήματος) &Windows (Substance skin) Λειτουργία του peer ως Listener & Broadcaster (Substance skin) Εκτυπώσεις κονσόλας κατά τη λειτουργία ως Listener 69