Ασκηση Τετραδίου Μαθητή σ. 55 και προτεινόμενη λύση

[geopapa]

Στο ερώτημα σχετικά με το ποιό στοιχείο δείχνει οτι το χρησιμοποιούμενο πρωτόκολλο είναι το TCP , η ενδεικτική λύση αναφέρει οτι το καταλαβαίνουμε απο την λέξη "STREAM" αρα είναι ροή άρα προϋποθέτει σύνδεση που μόνο το TCP μπορει να παρέχει.
Μα το το βιβλίο στην σ. 136  μιλάει για ροές βίντεο και ήχου στις οποίες μάλιστα ειναι ιδανικό να χρησιμοποιηθεί το UDP.
Μήπως εγώ δεν εχω καταλάβει κάτι;

[the_eye]

Καλημέρα το SOCK_STREAM είναι το Socket type για το πρωτόκολλο TCP.
To SOCK_DGRAM είναι για το UDP.

Η ενδεικτική λύση που παίρνει μόνο την λέξη STREAM, θα έλεγα ότι δεν αιτιολογεί σωστά.

[z1000biker]

Η ύλη που διδάσκουμε στα σχολεία αντιστοιχεί σε γνώση των 80s/90s. Αν ήξεραν πραγματικά τι συμβαίνει στην πράξη οι μαθητές μας θα έπαιρναν τους υπεύθυνους με τις πέτρες για τα χάλια των βιβλίων που διδάσκουμε.

Για να βάλουμε μερικά πράγματα στη θέση τους:

Η κάθε ροή βίντεο σήμερα όταν είναι σε on-demand υπηρεσίες (πχ Netflix, Youtube) χρησιμοποιεί pre-fetching και pre-buffering για να επιτύχει ομαλή αναπαραγωγή βίντεο. Το TCP παρέχει μόνο τέτοια δυνατότητα και όχι το UDP καθώς και την αξιόπιστη εγγύηση μετάδοσης για μη απώλεια πλαισίων.

Δεύτερον, προτιμάμε σε τέτοιες υπηρεσίες το TCP έναντι του UDP γιατί η ανίχνευση εύρους ζώνης και ο έλεγχος συμφόρησης του TCP θα προσπαθήσει να χρησιμοποιήσει όλο το διαθέσιμο εύρος ζώνης μεταξύ του διακομιστή και του πελάτη, φέρνοντας το περιεχόμενο όσο το δυνατόν γρηγορότερα, ενώ παράλληλα θα είναι φιλικό προς την άλλη κίνηση (TCP) στις ίδιες συνδέσεις(text chat/usage charging κτλ).

Tρίτο, πλατφόρμες όπως το Netflix κατασκευάζουν/νοικιάζουν/εντοπίζουν με δίκτυα παράδοσης περιεχομένου (CDN). Οι περισσότεροι από τους διακομιστές CDN (π.χ. της Akamai) ήταν αρχικά και ήδη διαμορφωμένοι για να υποστηρίζουν υπηρεσίες web κατά βάση. Έτσι, η ροή βίντεο μέσω HTTP λειτουργεί χωρίς τη δημιουργία ειδικών διακομιστών και τα περισσότερα τείχη προστασίας δεν θα μπλοκάρουν την κυκλοφορία HTTP. Στην πραγματικότητα, η δυναμική  ροή μέσω HTTP (Dynamic Adaptive Streaming over HTTP - DASH) έχει γίνει η πιο κοινή πρακτική. Παρόλο που θεωρητικά το HTTP μπορεί να ενθυλακωθεί σε άλλα πρωτόκολλα, τα πρωτόκολλα αυτά εξακολουθούν να πρέπει να παρέχουν αξιόπιστη μεταφορά γεγονός που αποκλείει και πάλι το UDP.

Τέταρτο , τα firewalls/border routers  (από επιχειρήσεις, ISPs) αντιπαθούν το UDP (σε αντίθεση με το TCP, αυτά τα πρωτόκολλα μπορούν να καταναλώνουν εύκολα το πολύτιμο εύρος ζώνης), καθιστώντας δύσκολη τη διέλευση της μεταφερόμενης κίνησης βίντεο , αντίθετα με το TCP που οι δικτυάδες δεν το κόβουν τόσο εύκολα στα access lists).

Μόνο πλέον στην ζωντανή ροή βίντεο (πχ live chat apps) επιλέγεται το UDP, επειδή το pre-fetching και το pre-buffering μόνο lag μπορεί να δημιουργήσει στη φάση της αναπαραγωγής του βίντεο/ήχου. Δεδομένου ότι το UDP εξυπηρετεί μόνο τις πιο βασικές λειτουργίες του επιπέδου μεταφοράς, χρησιμοποιείται συχνά από κοινού με άλλα πρωτόκολλα ειδικού επιπέδου εφαρμογής(όπως το RTSP), για την εκτέλεση ροής βίντεo. Και πάλι όμως όλα τα υπόλοιπα τα κάνουμε με το TCP(registration/file transfers κτλ)

Το udp θα έπρεπε να λέγεται Unreliable Datagram Protocol. Και επειδή πολλοί συνάδελφοι που δεν έχουν ποτέ ασχοληθεί επαγγελματικά με το θέμα λένε πως είναι πιο γρήγορο, η απάντηση είναι πως αυτό δεν είναι σίγουρο πως ισχύει. Ας σκεφτούμε λίγο πως για κάθε retransmission υπάρχουν overheads και στο δίκτυο και σε κάθε εμπλεκόμενη CPU και πως η ύπαρξη σήμερα κατά βάση συνδέσεων που γίνονται πάνω από TLS και για big data μάλλον κάνουν τη χρήση του πολύ σπάνια. Η καλύτερη λύση σήμερα είναι το πρωτ/λο QUIC.