Κωδικοποίηση ήχου με τεχνικές πολλαπλών περιγραφών και μετάδοση ήχου σε πραγματικό χρόνο σε δίκτυα ομότιμων τερματικών

emujabΛογισμικό & κατασκευή λογ/κού

2 Ιουλ 2012 (πριν από 5 χρόνια και 19 μέρες)

417 εμφανίσεις


2
Ευχαριστίες

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

3
Περιεχόμενα


ΚΕΦΑΛΑΙΟ 1ο - ΕΙΣΑΓΩΓΗ ................................................................................................ 6
Ιστορική αναδρομή ................................................................................................................... 6
Σκοπός της διπλωματικής ......................................................................................................... 7
Διάρθρωση Διπλωματικής ........................................................................................................ 7
Λέξεις - Κλειδιά ......................................................................................................................... 8


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

4
Κωδικοποίηση Πολλαπλών Περιγραφών (MDC) ...................................................................... 23
Κβαντισμός ......................................................................................................................... 24
Speech Coding for Channel Splitting .................................................................................... 25
Progressive Coding & Unequal Error Protection................................................................... 26
Τεχνικές Ανακατασκευής Πακέτων .......................................................................................... 28
Διόρθωση στην πλευρά του αποστολέα .............................................................................. 28
Διόρθωση στην πλευρά του παραλήπτη ............................................................................. 32
Επιλογή Τεχνικής Ανακατασκευής ....................................................................................... 33
Επίλογος ................................................................................................................................. 35


ΚΕΦΑΛΑΙΟ 3
ο
- ΠΑΡΟΜΟΙΕΣ ΕΡΓΑΣΙΕΣ ........................................................................... 36
Εισαγωγή ................................................................................................................................ 36
Adaptive packet video streaming over P2P networks using active measurements ................... 36
Distributing streaming media content using cooperative networking ...................................... 38
Challenges & approaches in large-scale P2P media streaming ................................................. 40
Επίλογος ................................................................................................................................. 42


ΚΕΦΑΛΑΙΟ 4
ο
- ΠΑΡΟΥΣΙΑΣΗ ΕΦΑΡΜΟΓΗΣ .................................................................... 43
Εισαγωγή ................................................................................................................................ 43
Προδιαγραφές Εφαρμογής ..................................................................................................... 43
Γιατί Java ............................................................................................................................ 44
Ελάχιστες απαιτήσεις .......................................................................................................... 44
Περιγραφή Server ................................................................................................................... 45
Λογικό διάγραμμα λειτουργίας του Server .......................................................................... 45
Εξυπηρέτηση πακέτων ........................................................................................................ 46
Multi-threading & συγχρονισμός ......................................................................................... 47
Επιλογή UDP έναντι TCP ...................................................................................................... 47
Επίλυση κοινών προβλημάτων ............................................................................................ 48
Περιγραφή Peer ...................................................................................................................... 49
Γενικά ................................................................................................................................. 49
Τύποι λειτουργίας ............................................................................................................... 50
Χρήση UDP & TCP ............................................................................................................... 50
Τεχνολογίες Μετάδοσης Ήχου ............................................................................................ 51
Δομημένο Peer-to-Peer .................................................................................................. 51
Χρήση MDC & τοποθέτηση των peers στις δομές μετάδοσης ......................................... 53

5
Τεχνικές Forward Error Correction και Επαναποστολή πακέτων ..................................... 58
Λογικά Διαγράμματα .............................................................................................................. 62
Λογικό διάγραμμα κεντρικής λειτουργίας του Peer ............................................................. 62
Λογικό διάγραμμα Packet Handler ...................................................................................... 63
Λογικό διάγραμμα Socket Handler ...................................................................................... 65
Λογικό διάγραμμα Retransmit Handler ............................................................................... 66
Λογικό διάγραμμα Broadcaster ........................................................................................... 67
Λογικό διάγραμμα Listener ................................................................................................. 68
Εικόνες λειτουργίας της εφαρμογής ....................................................................................... 69


ΚΕΦΑΛΑΙΟ 5
o
- ΜΕΤΡΗΣΕΙΣ ............................................................................................ 70
Εισαγωγή ................................................................................................................................ 70
Προετοιμασία Μετρήσεων...................................................................................................... 71
Έλεγχος συμφόρησης & μέγεθος πακέτου .............................................................................. 71
Μετρήσεις απώλειας πακέτων σε δίκτυο P2P ......................................................................... 77
Επαναποστολή πακέτων ......................................................................................................... 85
Επίλογος ................................................................................................................................. 86


ΚΕΦΑΛΑΙΟ 6
ο
- ΣΥΜΠΕΡΑΣΜΑΤΑ, ΠΑΡΑΤΗΡΗΣΕΙΣ & ΠΕΡΑΙΤΕΡΩ ΑΝΑΛΥΣΗ ................. 87
Αρχικές Προσπάθειες .............................................................................................................. 87
Χρήση TCP........................................................................................................................... 87
Multicast ............................................................................................................................. 88
Πλατφόρμα JXTA ................................................................................................................. 89
Συμπεράσματα & Παρατηρήσεις ............................................................................................ 92
UDP Lost Packets & Reasons ............................................................................................... 92
UDP Arriving........................................................................................................................ 92
Κωδικοποιήσεις Ήχου ......................................................................................................... 93
Packet Size vs. Βέλτιστο Throughput ................................................................................... 94
Πολυπλοκότητες Δομών και αναζήτησης ............................................................................ 97
Μελλοντική επέκταση ............................................................................................................. 98


ΚΕΦΑΛΑΙΟ 7
ο
- ΒΙΒΛΙΟΓΡΑΦΙΑ & ΠΗΓΕΣ ...................................................................... 101
Papers ................................................................................................................................... 101
Links ..................................................................................................................................... 102


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 δίκτυο, σε αντίθεση με την παραδοσιακή αρχιτεκτονική του client-
server μοντέλου, όσο αυξάνεται ο αριθμός των χρηστών τόσο αυξάνεται η ευρωστία και η
συνολική δυναμική σε πόρους του δικτύου.
Το P2P σαν τεχνολογία βρίσκει χρήση σήμερα σε μια πληθώρα εφαρμογών. Από τη
διανομή μεγάλων σε όγκο πολυμεσικών αρχείων, το media streaming και την τηλεφωνία, μέχρι
και σε βαριές εφαρμογές του Στρατού και της Βιοπληροφορικής. Ανάμεσα σε αυτήν την
πληθώρα εφαρμογών, ας αναφέρουμε ονομαστικά μερικές από τις οποίες έχουν ξεχωρίσει
εμπορικά. To πασίγνωστο Skype (2003) για τηλεφωνία μέσω internet, το Kazaa (2000) και τα
παραπλήσια του προγράμματα για file sharing, το Joost (2007) σαν μια πρώτη προσπάθεια
μετάδοσης near TV quality shows, όπως επίσης και το United Devices Cancer Research Project
(2000) που, με τη βοήθεια της επεξεργαστικής ισχύς υπολογιστών σε παγκόσμιο επίπεδο,
προσπαθεί να βρει την θεραπεία για τον καρκίνο, μια πρωτοβουλία που ξεκίνησε από το
πανεπιστήμιο της Οξφόρδης.
Τέλος, η χρήση των P2P δικτύων έχει δώσει ώθηση στην ανάπτυξη διαφόρων τεχνικών
που προσπαθούν να βρουν αποτελεσματικούς τρόπους για την αναζήτηση υλικού μέσα σε ένα
τέτοιο δίκτυο, τη δρομολόγηση της πληροφορίας, τη συμπίεση των δεδομένων, κλπ.
Εστιάζοντας κυρίως στη δρομολόγηση της πληροφορίας, ένας δημοφιλής τρόπος για να

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 δίκτυα και τις τεχνικές που χρησιμοποιούνται για
επίλυση των προβλημάτων.

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



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, όπως σχηματικά υλοποιείται
στην επικοινωνία δύο υπολογιστών και ενδεικτικά κάποιες τεχνολογίες που υλοποιούνται σε
κάθε επίπεδο.

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 για να κατευθύνουν το πακέτο στον τελικό του
προορισμό.


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.


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 ελαττώνεται
στο μισό, ώστε να αποφευχθεί η κατάρρευση του δικτύου και έπειτα από λίγο συνεχίζει

15
να μεγαλώνει σιγά σιγά μέχρι να ξαναπαρατηρηθεί συμφόρηση, οπού και θα μειώσει
πάλι το μέγεθος του congestion window στο μισό.

 Εγγυάται την ακεραιότητα του "μονοπατιού επικοινωνίας"

Αυτό βέβαια δεν εμποδίζει την υποκλοπή των δεδομένων από τρίτους. Η τελευταία
όμως είναι σχετικά δύσκολη, μιας και ο κακόβουλος χρήστης θα πρέπει να ακούσει όλη
την ροή δεδομένων, καθώς δεν υπάρχουν συγκεκριμένου μεγέθους πακέτα.
Εξαιτίας των παραπάνω χαρακτηριστικών του λοιπόν, το TCP χρησιμοποιείται και
επιβάλλεται να χρησιμοποιείται, όπου η ακεραιότητα των δεδομένων είναι ύψιστης σημασίας.
Δηλαδή σε web surfing, e-mails, 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
στο δίκτυο, καθώς δεν ελέγχει αν όντως κάποιο πακέτο έφτασε ή όχι.


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. Εδώ μας
ενδιαφέρει τα δεδομένα να φτάνουν την σωστή χρονική στιγμή. Οποιαδήποτε απώλεια
τους μας επηρεάζει μόνο στην ποιότητα του αναπαραγόμενου σήματος.


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.

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 του πακέτου δεν παίζει κανένα ρόλο.


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 δίκτυα έχουμε τα
υβριδικά δίκτυα
, τα οποία έχουν

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 από διαφορετικές

24
διαδρομές (path diversity) μέχρι να φτάσει στον παραλήπτη. Σε περίπτωση που σε μια διαδρομή
παρατηρηθεί congestion, η αποκωδικοποίηση του stream δεν θα σταματήσει στην πλευρά του
παραλήπτη, παρά θα παρατηρηθεί μια στιγμιαία υποβάθμιση της ποιότητας. Κοινώς, η
ποιότητα που θα λαμβάνει ο παραλήπτης θα είναι ανάλογη των descriptions που λαμβάνει
παράλληλα. Το ίδιο το path diversity μας εξασφαλίζει ότι η πιθανότητα να έχει προκληθεί σε
όλες τις διαδρομές συμφόρηση είναι πολύ μικρή.
Εκτός από την ανοχή στα χαμένα πακέτα που προσφέρει, το ΜDC είναι μια πολύ καλή
τεχνική και για αυτούς που παρέχουν το υλικό. Οι providers, λοιπόν, μπορούν να στέλνουν όλα
τα descriptions ενός stream χωρίς να τους νοιάζει ο περιορισμός του download του εκάστοτε
χρήστη. Οι χρήστες που δεν μπορούν να αντεπεξέλθουν στον ρυθμό μετάδοσης παίρνουν ένα
υποσύνολο από αυτά τα descriptions, ελευθερώνοντας τον provider από το να παρέχει επιπλέον
streams σε μικρότερους ρυθμούς.
Σαν γενικό κανόνα μπορούμε να πούμε το παρακάτω:
+ 

 => ύ ℎ ℎ!"+#$%ή '(ή ) (*έ' ,-έ

Μιας λοιπόν και το MDC είναι μια τεχνική κωδικοποίησης ενός stream, θα δούμε
παρακάτω ορισμένες τεχνικές με τις οποίες μπορούμε να φτιάξουμε αποτελεσματικά
descriptions από αυτό. Προτού όμως προχωρήσουμε σε αυτές ας δούμε λίγα πράγματα για την
διαδικασία που ονομάζουμε κβαντισμό.
Κβαντισμός

Στην ψηφιακή επεξεργασία σήματος, ο κβαντισμός είναι η διαδικασία κατά την οποία
υπολογίζουμε μια συνεχή σειρά τιμών (ή ένα μεγάλο σετ από πιθανές διακριτές τιμές) από ένα
σχετικά μικρό σετ διακριτών συμβόλων ή ακεραίων αριθμών. Προφανώς, ο κβαντισμός είναι μια
διαδικασία εκτίμησης των τιμών και συνεπώς ένας καλός κβαντιστής είναι αυτός ο οποίος
μπορεί να αναπαραστήσει το αρχικό σήμα με τον μικρότερο δυνατό θόρυβο. Μια συχνή χρήση
του κβαντισμού είναι η μετατροπή ενός δειγματοληπτημένου συνεχούς σήματος σε ένα
ψηφιακό, με κβαντισμό. Οι λεγόμενοι analog-to-digital converters (ADC) εφαρμόζουν κβαντισμό
για να μετατρέψουν μια πηγή ήχου π.χ. σε format cd audio που είναι δειγματοληπτημένο με
44100 δείγματα/sec και κάθε δείγμα κβαντισμένο με 16bits ή 65536 πιθανές τιμές ανά δείγμα.
Αυτά τα 16 bits είναι το λεγόμενο step size του κβαντιστή.
Ο προσαρμοσμένος κβαντισμός, είναι μια διαδικασία κβαντισμού κατά την οποία το
step size του κβαντιστή μεταβάλλεται ανάλογα με τις μεταβολές του σήματος εισόδου, σε μια
προσπάθεια για μια πιο αποτελεσματική συμπίεση.
Υπάρχουν δύο κύριοι τύποι κβαντισμού. Ο απλός κβαντισμός, όπως συχνά αναφέρεται,
και ο διανυσματικός. Στον απλό κβαντισμό, κάθε σύμβολο εισόδου αντιμετωπίζεται ξεχωριστά
για να παραχθεί η έξοδος, ενώ στον διανυσματικό κβαντισμό τα σύμβολα εισόδου μαζεύονται
μαζί σε groups, τα λεγόμενα διανύσματα, και αυτά τα διανύσματα επεξεργάζονται για να βρεθεί
η έξοδος. Σε γενικές γραμμές ένας απλός κβαντιστής μπορεί να αναπαρασταθεί με:

26
σύστημα σχεδιασμένο για συνολικό ρυθμό R, είναι ίδια με αυτήν ενός ολόκληρου σήματος
ρυθμού R για ένα σύστημα σχεδιασμένο για ρυθμό R/2. Ή διαφορετικά, ο half-rate
αποκωδικοποιητής που λαμβάνει τα μονά δείγματα βάζει το ίδιο distortion (παραμόρφωση) σε
αυτά τα δείγματα, όσο και ο full-rate αποκωδικοποιητής.
Είναι σημαντικό ότι τα μονά και ζυγά δείγματα έχουν πλεονασμό με μορφή συσχέτισης
μεταξύ των δειγμάτων ή μνήμης, που υπάρχει ήδη στην αρχική πηγή. Αν ο πλεονασμός είχε
αφαιρεθεί πριν τον διαχωρισμό των δειγμάτων σε μονά/ζυγά, για παράδειγμα με γραμμική
παρεμβολή, η απόδοση θα ήταν απογοητευτική. Φυσικά με αυτή την τεχνική μπορούμε να
διασπάσουμε το αρχικό stream σε όσο substreams θέλουμε, προσέχοντας πάντα να υπάρχει
πλεονασμός στην πηγή.
Για να δούμε την δυσκολία που έχει η διάσπαση μιας πηγής που δεν έχει πλεονασμό σε
διάφορα substreams, ας εξετάσουμε το ακόλουθο παράδειγμα. Έστω ότι θέλουμε να
μεταδώσουμε έναν πραγματικό αριθμό x[-1,1] με 4bits. Με όποιον τρόπο και να σπάσουμε τα 4
bits σε 2 ζευγάρια και να τα μεταδώσουμε μέσω 2 καναλιών, τα αποτελέσματα θα είναι
απογοητευτικά. Οποιαδήποτε εκτίμηση που θα υπολογιστεί από το κανάλι που δεν λαμβάνει το
πιο σημαντικό bit, κατά μέσο όρο, δεν θα είναι καλή. Και αυτό γιατί τα 4 bits δεν έχουν
πλεονασμό, με την έννοια ότι δεν συσχετίζονται μεταξύ τους.
x
q(x)
-1 1
1000
10
01
1001
11
00
1010
11
01
1011
10
10
1100
01
11
1101
10
11
1110
11
10
1111
11
11
0000
00
00
0001
00
01
0010
01
00
0011
10
00
0100
01
01
0101
00
10
0110
00
11
0111
01
10

Τα μοντέρνα συστήματα κωδικοποίησης από την άλλη, τείνουν να εξαλείψουν τον
πλεονασμό είτε με πρόβλεψη των επόμενων δειγμάτων είτε με μετασχηματισμούς
αποσυσχέτισης. Ένας διαχωρισμός σε μονά/ζυγά στους συντελεστές μετασχηματισμού δεν είναι
αποτελεσματικός. Χρειαζόμαστε λοιπόν τεχνικές για δημιουργία descriptions οι οποίες θα
αποδίδουν σωστά και σε πηγές που δεν έχουν μνήμη (memoryless sources). Κάποιες από αυτές
τις τεχνικές θα δούμε παρακάτω.
Progressive Coding & Unequal Error Protection

Ένας τετριμμένος τρόπος για να στείλουμε 2 descriptions είναι να στείλουμε το ίδιο
description 2 φορές. Το description θα αναπαραχθεί με την καλύτερη διαθέσιμη τεχνική

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, δύσκολα μπορεί να σπαστεί σε δυο χρήσιμες

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

29
είναι μικρό, ο αριθμός των χαμένων πακέτων μικρός και υπάρχει και κάποιος buffer από τον
οποίο παίζονται τα δεδομένα, ο οποίος θα αυξήσει τον διαθέσιμο για επαναποστολή χρόνο.
Γενικά σαν μέθοδος είναι πολύ ελκυστική για την ευκολία υλοποίησής της. Το πρόβλημα που θα
δημιουργηθεί αν υπάρχει συμφόρηση και συγχρόνως επαναποστολή πακέτων μπορούμε εν
μέρει να το λύσουμε, αν εξαρχής δώσουμε λίγο έξτρα bandwidth για περιπτώσεις
επαναποστολής ή αν το κομμάτι audio/video που γίνεται retransmitted, κωδικοποιείται με
μικρότερο bit rate.
Interleaving

Το interleaving είναι μια τεχνική κατά την οποία "σπάμε" ένα πακέτο σε μικρότερο
κομμάτια και αυτά τα κομμάτια τα ανακατανέμουμε με άλλη σειρά, ώστε να δημιουργηθούν
νέα πακέτα. Αυτά τα νέα πακέτα είναι που στέλνονται από τον αποστολέα. O παραλήπτης,
καθώς τα λαμβάνει, ανακατανέμει στην αρχική τους σειρά τα κομμάτια των πακέτων, ώστε να
μπορέσει να τα επεξεργαστεί σωστά.
Με αυτόν τον τρόπο μειώνουμε την επίδραση των χαμένων πακέτων, καθώς
διασκορπίζουμε την χαμένη πληροφορία σε πολύ μικρά κομμάτια στο ανακατασκευασμένο μας
stream. Τα πολύ μικρά κομμάτια χαμένης πληροφορίας δε θα επηρεάσουν τόσο την ποιότητα
του αναπαραγόμενου σήματος. Παρόλο που το interleaving αυξάνει την καθυστέρηση (latency),
καθώς χρειάζεται κάποιος χρόνος για να ανακατασκευαστεί σωστά το stream, δεν αυξάνει σαν
τεχνική το κόστος σε bandwidth οπότε αξίζει να δοκιμαστεί. Ειδικά σε non-interactive
εφαρμογές έχει πολύ καλά αποτελέσματα.

Forward Error Correction (FEC)

Αυτή η τεχνική βασίζεται στην λογική ότι προσθέτουμε έξτρα πληροφορία στο stream
που θέλουμε να μεταδώσουμε, ώστε να μπορούμε έπειτα από αυτή, στην πλευρά του

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.


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).



32
Διόρθωση στην πλευρά του παραλήπτη

Αυτές οι τεχνικές εφαρμόζονται στην πλευρά του παραλήπτη χωρίς ενημέρωση του
αποστολέα. Είναι χρήσιμες όταν οι τεχνικές διόρθωσης του αποστολέα αποτύχουν να
διορθώσουν όλα τα χαμένα πακέτα ή όταν ο αποστολέας δεν έχει την δυνατότητα να εφαρμόσει
τεχνικές διόρθωσης. Είναι γνωστές ως Error Concealment Techniques και χωρίζονται σε 3
βασικές κατηγορίες όπως δείχνει το παρακάτω σχήμα:


Ας δούμε τις τρεις κατηγορίες μία προς μία:
Insertion based

Αυτές οι τεχνικές έχουν να κάνουν με την αντικατάσταση του χαμένου πακέτου είτε με
θόρυβο ή σιωπή, είτε με το προηγούμενο πακέτο, ώστε να καταφέρουν να κρατήσουν την
χρονική συσχέτιση ανάμεσα στα πακέτα.
H αντικατάσταση του χαμένου πακέτου με σιωπή είναι αποτελεσματική για μικρά
μεγέθη πακέτων (< 4ms) και για χαμηλά loss rates (< 2%). Η απόδοσή της πέφτει εκθετικά καθώς
το πακέτο μεγαλώνει και είναι εντελώς αναποτελεσματική για μεγέθη πακέτων 40ms, που είναι
και πολύ χρησιμοποιούμενα για audio εφαρμογές.
H αντικατάσταση του χαμένου πακέτου με θόρυβο έχει καλύτερο ακουστικό
αποτέλεσμα στο ανθρώπινο αυτί σε σχέση με την σιωπή.
Η αντικατάσταση με το προηγούμενο πακέτο, με κάποιο fading στον ήχο μάλιστα, έχει το
καλύτερο αποτέλεσμα από τις 2 παραπάνω τεχνικές και είναι ένας αρκετά καλός συμβιβασμός
ανάμεσα στις προηγούμενες δυο τεχνικές και τις πιο περίπλοκες τεχνικές με interpolation.

Interpolation based

Την καλύτερη απόδοση την έχουν οι τεχνικές interpolation που είναι και δύσκολες στην
υλοποίηση και απαιτητικές σε πόρους. Χρησιμοποιώντας αναγνώριση προτύπων και παρεμβολή

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 υποθέτουν ότι η αποκωδικοποίηση του ήχου γίνεται
σε ιδανικές καταστάσεις. Δηλαδή ότι υπάρχει μια φυσική συνέχεια. Έτσι όταν έρθει ένα χαμένο
πακέτο, ίσως είναι αδύνατο να συνεχιστεί η σωστή αποκωδικοποίηση. Κι αυτό πρέπει να ληφθεί
σοβαρά υπόψη κατά την διαδικασία επιλογής.
Τα παρακάτω σχήματα δείχνουν διάφορες τεχνικές ανακατασκευής και την αντίστοιχη
πολυπλοκότητα τους.

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



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, το οποίο παρέχει υψηλή ανεκτικότητα στα λάθη.



37
Ορισμένες αξιόλογες παρατηρήσεις είναι οι εξής:
 Η ποιότητα του video στον αποστολέα δεν αυξάνεται αναγκαστικά όταν προστεθούν
νέοι peers που θα στέλνουν το υλικό, καθώς οι τελευταίοι μπορεί να συνδεθούν πίσω
από το ίδιο bottleneck link. Για αυτό και μετριέται η απόδοση του κάθε νέου peer
ξεχωριστά ώστε να αποφασιστεί αν θα "ενεργοποιηθεί" η συμμετοχή του στο δίκτυο.

 Οι peers σχηματίζουν clusters όπως φαίνεται και στην παρακάτω εικόνα για καλύτερη
οργάνωση. Για την αποστολή του video προτιμούνται peers από διαφορετικά clusters,
ώστε να αποφεύγεται η συμφόρηση στο link που ενώνει το cluster με τον receiver.

 Δεν είναι θεμιτό να αλλάζει συνεχώς ο υποψήφιος για αποστολή video λόγω του
μικρότερου RTT, για να αποφευχθεί μεγάλο overhead στο δίκτυο. Γι' αυτό προτείνεται
μέσω ενός συντελεστή λ να δίνεται μεγαλύτερη προτεραιότητα στις πρόσφατες
παρατηρήσεις και λιγότερη στις παλιές. Όσο πιο μικρό το λ τόσο πιο συχνή η αλλαγή του
Peer




 Αν ο buffer του Receiver πέσει κάτω από ένα όριο(threshold), τότε αρχίζει και ψάχνει για
καινούργιους υποψήφιους αποστολείς.

Τα τελικά αποτελέσματα φανερώνουν ότι η λύση που προτείνουν βοηθάει τόσο στην
καλύτερη αξιοποίηση του bandwidth του δικτύου, όσο και στην καλύτερη αναπαραγωγή στην
πλευρά του αποστολέα.

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. Έτσι σε περίπτωση που μεταδίδεται on-
demand πολυμεσικό υλικό και συμβεί overload στον server, οι clients κρατάνε στον

39
buffer τους ένα μέρος από αυτό που έχουν ήδη παρακολουθήσει και o server μπορεί να
στείλει τους νέους clients στους παλιούς για να αναζητήσουν πληροφορία.

 Με τη χρήση ενός μόνο δέντρου η αναχώρηση ή το crash ενός node θα έχει σοβαρό
αντίκτυπο σε όλους τους απογόνους του. Οι απόγονοι μπορεί να μην πάρουν καθόλου
το stream μέχρι το δέντρο να διορθωθεί. Γι' αυτό και υλοποιούνται πολλαπλά δέντρα,
με τα nodes σε διαφορετική θέση σε κάθε δέντρο και με ένα MDC description ανά
δέντρο.
 Όσο περισσότερα τα δέντρα που χρησιμοποιούνται, τόσο μικρότερη και η πιθανότητα
κάποιο node να μην πάρει κανένα description. Συγκεκριμένα αν Ν ο αριθμός των
δέντρων και τείνει στο άπειρο, τότε η παραπάνω πιθανότητα γίνεται μηδενική.


Τα τελικά αποτελέσματα δείχνουν ότι το CoopNet μπορεί να βοηθήσει στο να μειωθεί το
βαρύ φορτίο στον server, χωρίς μάλιστα οι συνεργαζόμενοι peers να έχουν κάποιο παράλογο
overload. Επίσης, μεταδίδοντας live streams σε πολλαπλά δέντρα, με ένα MD description ανά
δέντρο, αυξήθηκε σημαντικά η αξιοπιστία του δικτύου.


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.

41


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

Παρακάτω φαίνονται τα αποτελέσματα των διαφορών μεθόδων αναζήτησης
κατάλληλων Peers, καθώς και διάφορες τεχνικές για την μετάδοση της πληροφορίας, το
λεγόμενο content delivery.

Μέθοδοι αναζήτησης κατάλληλων peers

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
1.9.4.


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 1.9.4 για αποκωδικοποίηση MP3
Substance Look and Feel (Theme για το GUI)
Πρέπει να τονίσουμε ότι όλα τα παραπάνω προαπαιτούμενα αποτελούν λογισμικό ανοιχτού
κώδικα.
Hardware requirements:
Ένα σχετικά σύγχρονο μηχάνημα ( 5ετίας )
Port forwarding στις απαραίτητες θύρες (5555-5556 για τον server, 5557-5560 για τον peer)
Μια σχετικά γρήγορη σύνδεση στο Internet (DSL) ή τοπικό δίκτυο.
Τουλάχιστον 2 υπολογιστές, ένας για λειτουργία ως server και broadcaster και ένας listener

45
Περιγραφή Server

Όπως αναφέραμε και παραπάνω, η εφαρμογή αποτελείται από δύο ανεξάρτητα, αλλά
άρρηκτα συνδεδεμένα μεταξύ τους κομμάτια, τον server και τον client (peer), τα οποία
περιγράφουμε ξεχωριστά.
Λογικό διάγραμμα λειτουργίας του Server


Η λειτουργία του server είναι αρκετά απλή, αφού θέλαμε να περιορίσουμε το ρόλο του,
κάνοντάς τον να επιτελεί μόνο τις απολύτως απαραίτητες λειτουργίες. Ο server, λοιπόν,
διατηρεί έναν πίνακα με τις διευθύνσεις IP όλων των peers που έχουν συνδεθεί στο δίκτυο,

46
καθώς και μία boolean μεταβλητή που δείχνει αν ένας peer έχει επιλέξει να είναι broadcaster
(να μεταδίδει ήχο) ή listener (να ακούει ήχο). Φροντίζει δε, να εξυπηρετεί τους peers που του
στέλνουν συγκεκριμένα αιτήματα με αποστολή UDP πακέτων.

Εξυπηρέτηση πακέτων

Όταν ξεκινάει η λειτουργία του server, ανοίγει μία νέα datagram socket που περιμένει
συνεχώς αιτήματα στην πόρτα 5555. Όταν λάβει ένα πακέτο, ελέγχει τον 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 πακέτου, δηλαδή τα 65.535 bytes.
Σε κάποια λειτουργικά συστήματα μάλιστα το όριο αυτό είναι ακόμα μικρότερο, όπως
π.χ. στα Windows το μέγιστο προεπιλεγμένο μέγεθος είναι 1280 bytes.

“Disconnect”: Με αυτό το πακέτο ο peer δηλώνει την έξοδό του από το δίκτυο, οπότε ο
server αφαιρεί τα στοιχεία του από τον πίνακα των peers.

Όσον αφορά την έξοδο ενός peer από το δίκτυο, αυτή μπορεί να μη γίνει πάντα με
αποστολή του πακέτου “Disconnect”. Είναι πιθανό αυτό το πακέτο να χαθεί, ο peer να κλείσει
με αντικανονικό τρόπο την εφαρμογή του, ή για οποιονδήποτε άλλο λόγο το πακέτο αυτό να
μην αποσταλεί καν. Για να προλάβει τέτοιες καταστάσεις ο server αποστέλλει σε τακτά χρονικά
διαστήματα (κάθε 15 δευτερόλεπτα) ένα πακέτο τεσσάρων bytes (πακέτο τύπου ECHO) σε όλους

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
στην πόρτα 5556.
Αυτό όμως μπορεί να δημιουργήσει προβλήματα συγχρονισμού, όταν δύο διαφορετικά
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, το οποίο κλείνει αμέσως όταν ολοκληρωθεί η
αποστολή.


48
Επίλυση κοινών προβλημάτων

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

Μηνύματα λειτουργίας του server στην κονσόλα



49
Περιγραφή Peer

Γενικά

Η εφαρμογή του client (peer) του δικτύου αποτελεί και το κύριο κομμάτι της
διπλωματικής, αφού εκεί εφαρμόζουμε όλες τις υπό συζήτηση τεχνολογίες. Αναπτύχθηκε ένα
φιλικό προς το χρήστη γραφικό περιβάλλον (GUI), με γνώμονα την απλότητα και την ευχρηστία.
Στην εικόνα που ακολουθεί παρουσιάζουμε ένα στιγμιότυπο της εκτέλεσης του προγράμματος.


Εικόνα 2

Το GUI είναι ιδιαίτερα απλό και δίνει στο χρήστη τη δυνατότητα να ακούσει ή να
εκπέμψει μουσική με 2 απλά βήματα:
1. Ο χρήστης συνδέεται στο δίκτυο πατώντας το κουμπί σύνδεσης (Connect/Disconnect).

2. Σε ελάχιστο χρόνο λαμβάνεται η λίστα των broadcasters και ενεργοποιούνται τα
κουμπιά Broadcast & Listen. Ο χρήστης μπορεί πια πατώντας ένα από τα 2 κουμπιά να
ξεκινήσει την αντίστοιχη διαδικασία.
Η διαδικασία περιγράφεται πιο αναλυτικά παρακάτω σε λογικά διαγράμματα. Θα δούμε
διαγράμματα ξεχωριστά για κάθε λειτουργία της εφαρμογής. Πριν από αυτό όμως, ας
γνωρίσουμε κάποια βασικά χαρακτηριστικά της εφαρμογής.

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. Επιπλέον, η επικοινωνία peer-
peer γίνεται κι αυτή με UDP πακέτα, με μόνη εξαίρεση την ανταλλαγή κρίσιμων για τη
λειτουργία του peer πληροφοριών, οπότε προτιμήσαμε την αξιοπιστία του TCP εφόσον δεν
υπήρχε ανάγκη για ταχύτητα.
Όταν προέκυψε η ανάγκη αξιόπιστης ανταλλαγής πληροφοριών που έχουν σχέση με την
P2P δομή μετάδοσης του ήχου, το UDP δεν απέδωσε τα αναμενόμενα, οπότε δημιουργήθηκε η
ανάγκη χρήσης TCP. Γι’ αυτό η εφαρμογή χρησιμοποιεί και μια TCP socket για τη μετάδοση
αυτών των πληροφοριών. Ο όγκος των δεδομένων που διακινούνται δεν είναι μεγάλος, ώστε το
TCP να προκαλεί καθυστέρηση, οπότε μπορούμε να πούμε ότι βρήκαμε τη χρυσή τομή στην
παράλληλη χρήση των 2 πρωτοκόλλων.




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/video-
on-demand, δεν είναι αρκετά γρήγορη για χρήση σε real-time εφαρμογή, αφού η διαδικασία
ανακοίνωσης του περιεχομένου και αίτησης για πρόσβαση σε αυτό έχει καθυστερήσεις.
Επιλέξαμε λοιπόν να φτιάξουμε από την αρχή ένα δίκτυο δικής μας έμπνευσης, όπου
κάθε peer θα συμμετέχει σε μια συγκεκριμένη δομή μετάδοσης ήχου. Η αρχική σκέψη ήταν να
χρησιμοποιηθεί η δομή του δέντρου, όπου ρίζα θα είναι ο Broadcaster και οι Listeners οι κόμβοι
του δέντρου, ή η δομής της λίστας, με ρίζα πάλι τον Broadcaster και τους Listeners ως peers στις
υπόλοιπες θέσεις. Οι δομές φαίνονται και σχηματικά.

Δομές δέντρου & λίστας

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 σε δέντρο & λίστα

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

Η χρήση MDC, δηλαδή η κωδικοποίηση του ήχου σε
με πολλές ανεξάρτητες περιγραφές
(Descriptions)
δίνει εμμέσως την δομή του P2P στο δίκτυό μας. Μεταδίδοντας κάθε description
ήχου σε διαφορετική δομή (layer), ο κάθε peer λαμβάνει πλέον ήχο από πολλούς peers και
μεταδίδει επίσης σε πολλούς. Για παράδειγμα, στο παρακάτω σχήμα φαίνεται η περίπτωση της
χρήσης τεσσάρων περιγραφών ήχου, οπότε κάθε peer συμμετέχει σε 4 δομές μετάδοσης.

Μετάδοση ήχου MDC σε πολλές δομές (P2P μετάδοση)


54
Αν n είναι ο αριθμός των layers, τότε κάθε peer μπορεί να παίρνει ήχο από n
διαφορετικούς peers και να στέλνει ήχο έως και σε n άλλους peers. Για τις ανάγκες τις
εφαρμογής και εφόσον δεν υπήρχε διαθέσιμος μεγάλος αριθμός υπολογιστών, καταλήξαμε στη
μελέτη της χρήσης 1-4 δομών. Όπως θα δούμε στο επόμενο κεφάλαιο, όσο αυξάνεται ο αριθμός
των δομών (από 1 έως 4) τόσο βελτιώνεται η αξιοπιστία του δικτύου. Αυτό συμβαίνει γιατί
πλέον κάθε peer συμμετέχει σε διαφορετικές δομές και βρίσκεται (κατά κανόνα) σε διαφορετική
θέση σε κάθε δομή. Έτσι, ένα ενδεχόμενο σφάλμα σε έναν peer έχει διαφορετική βαρύτητα για
κάθε δομή, που εξαρτάται από τη θέση του peer. Αυτό το βλέπουμε και στο παρακάτω σχήμα.

Αποτυχία ενός 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
BROADCASTER

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 με το παρακάτω σχήμα.


Δημιουργία πολλαπλών περιγραφών ήχου με χρήση 4 layers

Καθένα από τα 4 descriptions που δημιουργούνται με αυτήν την τεχνική MDC περιέχει
το ¼ της πληροφορίας του αρχικού ήχου. Αν κάποιος ακούσει τον ήχο που παράγει 1
description, σίγουρα δε θα μείνει ικανοποιημένος από την ποιότητα, αλλά τα ζητούμενο είναι να
επιτύχουμε τη βελτίωση του ήχου ελαχιστοποιώντας την πιθανότητα να χαθεί κάποιο από τα
descriptions. Έτσι, ακόμα κι αν γίνει λήψη μόνο τριών descriptions, ο χρήστης θα ακούει τα ¾ της