Προς κυβέρνηση παΝΔημίας: «είστε επικίνδυνοι» απο ένωση πληροφορικών Ελλάδας

[Awesomatic]

Πώς γίνεται αυτό; Πού την στέλνεις μια φορά, αφού δεν υπάρχει κεντρικός server. Δεν έχεις ανοικτές συνδέσεις και με τα 20 άτομα;

Δεν χρειάζεται κεντρικός σέρβερ για την λήψη του ίδιου του stream, το stream εκπέμπει και είτε έχεις πρόσβαση σε αυτό είτε όχι, είναι ανάλογα με την υλοποίηση βέβαια, οι ζωντανές εκπομπές στο yt χρειάζονται, well, τους centralized servers του yt, αλλά εκεί δεν μιλάμε για p2p. Ένα κεντρικό hub χρειάζεται όμως εφόσον θέλεις να κάνεις moderation πολλαπλών streams.

Αφού είναι P2P, κάθε καρέ του stream θα έπρεπε να εκπέμπεται τόσες φορές οσοι είναι και οι χρήστες, έτσι δεν είναι; Εκτός εάν μιλάμε για μουλτικαστ; Αλλιώς δεν γίνεται αυτό που λες.

P2P: οι χρήστες μοιράζονται τα καρέ μεταξύ τους. Στην πράξη με την προϋπόθεση ότι όλοι έχουν καλή σύνδεση κάθε πηγή στέλνει λίγο πάνω από μια φορά. Σε φωνή δουλεύει μια χαρά αλλά για βίντεο έχω τις επιφυλάξεις μου, ειδικά με τα άθλια upload speeds που έχει η τυπική aDSL στην Ελλάδα.

Αυτό επίσης είναι μεγάλο πρόβλημα και για περιοχές που δεν έχουν καλή σύνδεση στο Internet ούτε στο download (πρακτικά η μισή+ επαρχία).

[NoMoreLice]

Δεν χρειάζεται κεντρικός σέρβερ για την λήψη του ίδιου του stream, το stream εκπέμπει και είτε έχεις πρόσβαση σε αυτό είτε όχι, είναι ανάλογα με την υλοποίηση βέβαια, οι ζωντανές εκπομπές στο yt χρειάζονται, well, τους centralized servers του yt, αλλά εκεί δεν μιλάμε για p2p. Ένα κεντρικό hub χρειάζεται όμως εφόσον θέλεις να κάνεις moderation πολλαπλών streams.

Αφού είναι P2P, κάθε καρέ του stream θα έπρεπε να εκπέμπεται τόσες φορές οσοι είναι και οι χρήστες, έτσι δεν είναι; Εκτός εάν μιλάμε για μουλτικαστ; Αλλιώς δεν γίνεται αυτό που λες.

P2P: οι χρήστες μοιράζονται τα καρέ μεταξύ τους. Στην πράξη με την προϋπόθεση ότι όλοι έχουν καλή σύνδεση κάθε πηγή στέλνει λίγο πάνω από μια φορά. Σε φωνή δουλεύει μια χαρά αλλά για βίντεο έχω τις επιφυλάξεις μου, ειδικά με τα άθλια upload speeds που έχει η τυπική aDSL στην Ελλάδα.

Μα εδώ μιλάμε για real-time video conference, όχι για streaming on-demand, που πες κάποιος το έχει αρχίσει πιο νωρίς το βίντεο και μπορεί να στέλνει κομμάτια που έχει ήδη κατεβάσει σε άλλους. Και αν ανοίγουν και οι μαθητές κάμερες-μικρόφωνα μιλάμε για 20χ20 κανάλια επικοινωνίας.

[Awesomatic]

Αφού είναι P2P, κάθε καρέ του stream θα έπρεπε να εκπέμπεται τόσες φορές οσοι είναι και οι χρήστες, έτσι δεν είναι; Εκτός εάν μιλάμε για μουλτικαστ; Αλλιώς δεν γίνεται αυτό που λες.

P2P: οι χρήστες μοιράζονται τα καρέ μεταξύ τους. Στην πράξη με την προϋπόθεση ότι όλοι έχουν καλή σύνδεση κάθε πηγή στέλνει λίγο πάνω από μια φορά. Σε φωνή δουλεύει μια χαρά αλλά για βίντεο έχω τις επιφυλάξεις μου, ειδικά με τα άθλια upload speeds που έχει η τυπική aDSL στην Ελλάδα.

Μα εδώ μιλάμε για real-time video conference, όχι για streaming on-demand, που πες κάποιος το έχει αρχίσει πιο νωρίς το βίντεο και μπορεί να στέλνει κομμάτια που έχει ήδη κατεβάσει σε άλλους. Και αν ανοίγουν και οι μαθητές κάμερες-μικρόφωνα μιλάμε για 20χ20 κανάλια επικοινωνίας.

Ναι. Οκ θεωρητικά δεν χρειάζεται να συνδεθείς με όλους τους peers αλλά αυτό σημαίνει. 20 ανά συσκευή δεν είναι τόσα πολλά.

[sys3x]

Πώς γίνεται αυτό; Πού την στέλνεις μια φορά, αφού δεν υπάρχει κεντρικός server. Δεν έχεις ανοικτές συνδέσεις και με τα 20 άτομα;

Δεν χρειάζεται κεντρικός σέρβερ για την λήψη του ίδιου του stream, το stream εκπέμπει και είτε έχεις πρόσβαση σε αυτό είτε όχι, είναι ανάλογα με την υλοποίηση βέβαια, οι ζωντανές εκπομπές στο yt χρειάζονται, well, τους centralized servers του yt, αλλά εκεί δεν μιλάμε για p2p. Ένα κεντρικό hub χρειάζεται όμως εφόσον θέλεις να κάνεις moderation πολλαπλών streams.

Αφού είναι P2P, κάθε καρέ του stream θα έπρεπε να εκπέμπεται τόσες φορές οσοι είναι και οι χρήστες, έτσι δεν είναι; Εκτός εάν μιλάμε για μουλτικαστ; Αλλιώς δεν γίνεται αυτό που λες.

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

[klg]

Συγνώμη, να ρωτήσω κάτι σχετκά με αυτό. Αν είναι peer to peer και ας πούμε εγώ έχω μια τάξη με 20 άτομα, δεν θα πρέπει εγώ από τη δική μου σύνδεση να στέλνω το βίντεο και στους 20; Είναι εφικτό αυτό με το upload που έχει μια DSL;

Μία φορά στέλνεις την πληροφορία, όχι 20.

Πώς γίνεται αυτό; Πού την στέλνεις μια φορά, αφού δεν υπάρχει κεντρικός server. Δεν έχεις ανοικτές συνδέσεις και με τα 20 άτομα;

Ναι έχεις ανοικτές 20 συνδέσεις.

[axilmar]

Δεν χρειάζεται κεντρικός σέρβερ για την λήψη του ίδιου του stream, το stream εκπέμπει και είτε έχεις πρόσβαση σε αυτό είτε όχι, είναι ανάλογα με την υλοποίηση βέβαια, οι ζωντανές εκπομπές στο yt χρειάζονται, well, τους centralized servers του yt, αλλά εκεί δεν μιλάμε για p2p. Ένα κεντρικό hub χρειάζεται όμως εφόσον θέλεις να κάνεις moderation πολλαπλών streams.

Αφού είναι P2P, κάθε καρέ του stream θα έπρεπε να εκπέμπεται τόσες φορές οσοι είναι και οι χρήστες, έτσι δεν είναι; Εκτός εάν μιλάμε για μουλτικαστ; Αλλιώς δεν γίνεται αυτό που λες.

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

Υπαρχει ενα μπερδεμα στην κουβεντα.

Αυτα τα δυο πραγματα ειναι ξεχωριστα:

1) στελνω την ιδια πληροφορια σε καθεναν απο τους clients ξεχωριστα.

2) στελνω μονο τις αλλαγες απο καρε σε καρε.

Εγω ειχα την εντυπωση οτι μιλουσαμε για το #1, διοτι αυτο ηταν που σε ρωτησε ο NoMoreLice, και του απαντησες οτι 'Δεν χρειάζεται κεντρικός σέρβερ για την λήψη του ίδιου του stream, το stream εκπέμπει και είτε έχεις πρόσβαση σε αυτό είτε όχι'.

Αυτο που απαντησες ισχυει για μεταδοσεις σε ραδιοσυχνοτητες. Στο ιντερνετ δεν ισχυει αυτο, η μεταδοση γινεται απο IP σε συγκεκριμενη IP. Για να λαβεις ενα stream, πρεπει ο σερβερ που το στελνει να σε ξερει.

Απο περιεργεια ρωτω, για να καταλαβω τι εννοουσες, οχι για να σου υποδειξω οτι εκανες καποιο λαθος.

[axilmar]

P2P: οι χρήστες μοιράζονται τα καρέ μεταξύ τους.

Δεν μπορω να το παρσαρω αυτο που εγραψες. Τι εννοεις 'τα μοιραζονται'; προγραμματιστικα, ο σερβερ (ή τελος παντων ο υπολογιστης που παραγει το στριμ) θα πρεπει να το στειλει σε καθε ip address που εχει γινει connect, σωστα; αυτο σημαινει peer-to-peer.

Εκτος και εαν υπαρχει καποια τεχνολογια, πχ σε επιπεδο ip, οπου μπορεις να πεις 'εχω να στειλω αυτο το πακετο σε αυτες τις ip, λειτουργικο και δικτυο στειλτε το'...εσυ το στελνεις μια φορα, και οι ρουτερς κατα την διαδρομη φροντιζουν να το διακλαδωσουν ωστε να φτασει σε ολους.

Νομιζω το multicast παιζει ετσι..οποτε μιλας για multicast; ή για κατι αλλο που αγννοω;

ρωταω για να μαθω.

[sys3x]

Αφού είναι P2P, κάθε καρέ του stream θα έπρεπε να εκπέμπεται τόσες φορές οσοι είναι και οι χρήστες, έτσι δεν είναι; Εκτός εάν μιλάμε για μουλτικαστ; Αλλιώς δεν γίνεται αυτό που λες.

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

Υπαρχει ενα μπερδεμα στην κουβεντα.

Αυτα τα δυο πραγματα ειναι ξεχωριστα:

1) στελνω την ιδια πληροφορια σε καθεναν απο τους clients ξεχωριστα.

2) στελνω μονο τις αλλαγες απο καρε σε καρε.

Εγω ειχα την εντυπωση οτι μιλουσαμε για το #1, διοτι αυτο ηταν που σε ρωτησε ο NoMoreLice, και του απαντησες οτι 'Δεν χρειάζεται κεντρικός σέρβερ για την λήψη του ίδιου του stream, το stream εκπέμπει και είτε έχεις πρόσβαση σε αυτό είτε όχι'.

Αυτο που απαντησες ισχυει για μεταδοσεις σε ραδιοσυχνοτητες. Στο ιντερνετ δεν ισχυει αυτο, η μεταδοση γινεται απο IP σε συγκεκριμενη IP. Για να λαβεις ενα stream, πρεπει ο σερβερ που το στελνει να σε ξερει.

Απο περιεργεια ρωτω, για να καταλαβω τι εννοουσες, οχι για να σου υποδειξω οτι εκανες καποιο λαθος.

Ένα stream είναι ένα stream, είτε είναι live είτε είναι προβιντεοσκοπημένο, είναι σαν τα torrents, όσοι περισσότεροι συμμετέχουν τόσο καλύτερα γίνεται ο διαμοιρασμός σε ένα p2p δίκτυο.

[axilmar]

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

Υπαρχει ενα μπερδεμα στην κουβεντα.

Αυτα τα δυο πραγματα ειναι ξεχωριστα:

1) στελνω την ιδια πληροφορια σε καθεναν απο τους clients ξεχωριστα.

2) στελνω μονο τις αλλαγες απο καρε σε καρε.

Εγω ειχα την εντυπωση οτι μιλουσαμε για το #1, διοτι αυτο ηταν που σε ρωτησε ο NoMoreLice, και του απαντησες οτι 'Δεν χρειάζεται κεντρικός σέρβερ για την λήψη του ίδιου του stream, το stream εκπέμπει και είτε έχεις πρόσβαση σε αυτό είτε όχι'.

Αυτο που απαντησες ισχυει για μεταδοσεις σε ραδιοσυχνοτητες. Στο ιντερνετ δεν ισχυει αυτο, η μεταδοση γινεται απο IP σε συγκεκριμενη IP. Για να λαβεις ενα stream, πρεπει ο σερβερ που το στελνει να σε ξερει.

Απο περιεργεια ρωτω, για να καταλαβω τι εννοουσες, οχι για να σου υποδειξω οτι εκανες καποιο λαθος.

Ένα stream είναι ένα stream, είτε είναι live είτε είναι προβιντεοσκοπημένο, είναι σαν τα torrents, όσοι περισσότεροι συμμετέχουν τόσο καλύτερα γίνεται ο διαμοιρασμός σε ένα p2p δίκτυο.

1) Εχεις καμμια πηγη οτι το p2p streaming λειτουργει σαν τα τορρεντς; πρωτη φορα το ακουω. Δλδ οταν κανω streaming, ενδεχομενως δεν θα παρω ενα πακετο δεδομενων απο τον original server αλλα απο αλλον client που το εχει ηδη κατεβασει; αυτο δεν γινεται εαν ο client δεν τρεχει ειδικο software και τρεχει απλα μια εφαρμογη αναπαραγωγης βιντεο.

2) στα τα τορρεντς καθε πακετο παει σε καθε client ξεχωριστα. Η αυξηση της ταχυτητας του download δεν ερχεται απο το οτι καθε πακετο στελνεται μονο μια φορα προς ολους τους clients, αλλα απο το οτι καθε client ζηταει ενα πακετο απο διαφορετικους σερβερς.

[sys3x]

Το p2p είναι η βάση λειτουργίας των torrent.

[axilmar]

Το p2p είναι η βάση λειτουργίας των torrent.

Δεν μας τα λες καλα μαστορα.

Σου εχω κανει πολυ συγκεκριμενες τεχνικες ερωτησεις και δεν εχεις απαντησει σε καμμια, παρα μονο με γενικοτητες.

p2p ειναι οτιδηποτε στελνει δεδομενα απο client σε client. Εγω σε ρωτω πολυ συγκεκριμενα πραγματα ομως. Σε ρωτω για λεπτομερειες.

Απο οτι φαινεται δεν γνωριζεις τα πραγματα αυτα σε βαθος, για να μου απαντας με γενικοτητες.

[sys3x]

Πρώτη φορά ακούς ότι το p2p είναι η βάση λειτουργίας των torrent αλλά ταυτόχρονα σου φαίνεται ότι δεν έχω εγώ γνώση σε βάθος.
(:

[NoMoreLice]

Υπαρχει ενα μπερδεμα στην κουβεντα.

Αυτα τα δυο πραγματα ειναι ξεχωριστα:

1) στελνω την ιδια πληροφορια σε καθεναν απο τους clients ξεχωριστα.

2) στελνω μονο τις αλλαγες απο καρε σε καρε.

Εγω ειχα την εντυπωση οτι μιλουσαμε για το #1, διοτι αυτο ηταν που σε ρωτησε ο NoMoreLice, και του απαντησες οτι 'Δεν χρειάζεται κεντρικός σέρβερ για την λήψη του ίδιου του stream, το stream εκπέμπει και είτε έχεις πρόσβαση σε αυτό είτε όχι'.

Αυτο που απαντησες ισχυει για μεταδοσεις σε ραδιοσυχνοτητες. Στο ιντερνετ δεν ισχυει αυτο, η μεταδοση γινεται απο IP σε συγκεκριμενη IP. Για να λαβεις ενα stream, πρεπει ο σερβερ που το στελνει να σε ξερει.

Απο περιεργεια ρωτω, για να καταλαβω τι εννοουσες, οχι για να σου υποδειξω οτι εκανες καποιο λαθος.

Ένα stream είναι ένα stream, είτε είναι live είτε είναι προβιντεοσκοπημένο, είναι σαν τα torrents, όσοι περισσότεροι συμμετέχουν τόσο καλύτερα γίνεται ο διαμοιρασμός σε ένα p2p δίκτυο.

1) Εχεις καμμια πηγη οτι το p2p streaming λειτουργει σαν τα τορρεντς; πρωτη φορα το ακουω. Δλδ οταν κανω streaming, ενδεχομενως δεν θα παρω ενα πακετο δεδομενων απο τον original server αλλα απο αλλον client που το εχει ηδη κατεβασει; αυτο δεν γινεται εαν ο client δεν τρεχει ειδικο software και τρεχει απλα μια εφαρμογη αναπαραγωγης βιντεο.

2) στα τα τορρεντς καθε πακετο παει σε καθε client ξεχωριστα. Η αυξηση της ταχυτητας του download δεν ερχεται απο το οτι καθε πακετο στελνεται μονο μια φορα προς ολους τους clients, αλλα απο το οτι καθε client ζηταει ενα πακετο απο διαφορετικους σερβερς.

Νομίζω υπάρχει ένα μπλέξιμο όσον αφορά τα σενάρια. Το πρώτο σενάριο είναι να έχουμε on-demand video streaming και το δεύτερο να έχουμε video conference με πολλούς συμμετέχοντες όπως είναι το θέμα του τόπικ. Στο πρώτο σενάριο από ό,τι βλέπω υπάρχει δυνατότητα για υβριδική υλοποίηση με την έννοια ότι έχουμε έναν σέρβερ που επικοινωνεί με τους client που ζητάνε το βίντεο μέσω ενός λογισμικού (π.χ. το WebRTC που αναφέρθηκε και μπορεί να τρέχει μέσα σε έναν browser). Αυτό το λογισμικό μπορεί να διαχειριστεί το σενάριο ορισμένα κομμάτια του βίντεο να μην έρθουν από τον server αλλά από άλλους clients. Αυτό τουλάχιστον καταλαβαίνω από τα παρακάτω:

Contrary to many of the completely decentralized solutions of the past, modern WebRTC-based peer-to-peer streaming solutions are hybrid systems. As part of a hybrid delivery network, viewers source video segments from both servers and other viewers watching the same content at the same time.

Χωρίς να έχω ασχοληθεί με το ζήτημα, αυτό το σενάριο μου φαίνεται λογικό. Στο δεύτερο σενάριο έχουμε real-time επικοινωνία ανάμεσα σε πολλούς συμμετέχοντες οι οποίοι την ίδια ώρα μπορούν να έχουν όλοι ανοιχτές κάμερα. Εκεί το να λάβεις την εικόνα ενός Α συμμετέχοντα μέσω ενός άλλου Β μου φαίνεται μη ρεαλιστικό. Αρχικά προστίθεται καθυστέρηση, και έπειτα ο Β θα πρέπει την ίδια στιγμή που σου στέλνει τα δεδομένα που αφορούν τον Α, να στέλνει σε πολλούς και την δική του εικόνα/ήχο. Όπως και να έχει, μια p2p αρχιτεκτονική σε αυτό το σενάριο είναι λογικό να μην κάνει scale. Ένα απλό μα ενδιαφέρον πείραμα έχει κάνει αυτός εδώ ο οποίος βέβαια αναφέρει σαν πρώτο bottleneck που συνάντησε την επεξεργαστική ισχύ, αλλά σε μια "24άρα" DSL στην Ελλάδα νομίζω το upload της σύνδεσης θα ήταν πιο νωρίς το πρόβλημα.

[sys3x]

Ένα stream είναι ένα stream, είτε είναι live είτε είναι προβιντεοσκοπημένο, είναι σαν τα torrents, όσοι περισσότεροι συμμετέχουν τόσο καλύτερα γίνεται ο διαμοιρασμός σε ένα p2p δίκτυο.

1) Εχεις καμμια πηγη οτι το p2p streaming λειτουργει σαν τα τορρεντς; πρωτη φορα το ακουω. Δλδ οταν κανω streaming, ενδεχομενως δεν θα παρω ενα πακετο δεδομενων απο τον original server αλλα απο αλλον client που το εχει ηδη κατεβασει; αυτο δεν γινεται εαν ο client δεν τρεχει ειδικο software και τρεχει απλα μια εφαρμογη αναπαραγωγης βιντεο.

2) στα τα τορρεντς καθε πακετο παει σε καθε client ξεχωριστα. Η αυξηση της ταχυτητας του download δεν ερχεται απο το οτι καθε πακετο στελνεται μονο μια φορα προς ολους τους clients, αλλα απο το οτι καθε client ζηταει ενα πακετο απο διαφορετικους σερβερς.

Νομίζω υπάρχει ένα μπλέξιμο όσον αφορά τα σενάρια. Το πρώτο σενάριο είναι να έχουμε on-demand video streaming και το δεύτερο να έχουμε video conference με πολλούς συμμετέχοντες όπως είναι το θέμα του τόπικ. Στο πρώτο σενάριο από ό,τι βλέπω υπάρχει δυνατότητα για υβριδική υλοποίηση με την έννοια ότι έχουμε έναν σέρβερ που επικοινωνεί με τους client που ζητάνε το βίντεο μέσω ενός λογισμικού (π.χ. το WebRTC που αναφέρθηκε και μπορεί να τρέχει μέσα σε έναν browser). Αυτό το λογισμικό μπορεί να διαχειριστεί το σενάριο ορισμένα κομμάτια του βίντεο να μην έρθουν από τον server αλλά από άλλους clients. Αυτό τουλάχιστον καταλαβαίνω από τα παρακάτω:

Contrary to many of the completely decentralized solutions of the past, modern WebRTC-based peer-to-peer streaming solutions are hybrid systems. As part of a hybrid delivery network, viewers source video segments from both servers and other viewers watching the same content at the same time.

Χωρίς να έχω ασχοληθεί με το ζήτημα, αυτό το σενάριο μου φαίνεται λογικό. Στο δεύτερο σενάριο έχουμε real-time επικοινωνία ανάμεσα σε πολλούς συμμετέχοντες οι οποίοι την ίδια ώρα μπορούν να έχουν όλοι ανοιχτές κάμερα. Εκεί το να λάβεις την εικόνα ενός Α συμμετέχοντα μέσω ενός άλλου Β μου φαίνεται μη ρεαλιστικό. Αρχικά προστίθεται καθυστέρηση, και έπειτα ο Β θα πρέπει την ίδια στιγμή που σου στέλνει τα δεδομένα που αφορούν τον Α, να στέλνει σε πολλούς και την δική του εικόνα/ήχο. Όπως και να έχει, μια p2p αρχιτεκτονική σε αυτό το σενάριο είναι λογικό να μην κάνει scale. Ένα απλό μα ενδιαφέρον πείραμα έχει κάνει αυτός εδώ ο οποίος βέβαια αναφέρει σαν πρώτο bottleneck που συνάντησε την επεξεργαστική ισχύ, αλλά σε μια "24άρα" DSL στην Ελλάδα νομίζω το upload της σύνδεσης θα ήταν πιο νωρίς το πρόβλημα.

Ρίξε μια ματιά εδώ

(αν σε ενδιαφέρει η φασούλα κάτσε δες το από την αρχή)

Αυτό το έχω σετάρει σε ένα rpi4 σπίτι μου και παίζει άψογα, η ποιότητα των βιντεοκλήσεων είναι σαφώς ανώτερη από viber και αντίστοιχες μαλακίες, δεν έχω δοκιμάσει ομαδικές κλήσεις ακόμη αλλά με ένα μεγάλο εύρος συσκευών από xiaomi κινητά και iPhones (για τα οποία παίζει και dedicated app τόσο για τις βιντεοκλήσεις όσο και για την διαχείριση του file sharing) μέχρι MacBook pros, αρχαία και ολοκαίνουρια desktops και laps παίζει ανέλπιστα καλά.
Δεν έχω στήσει επιπλέον μποξάκια για stun/turn καθώς δεν με ενδιαφέρει να κάνω scaling, αλλά από ότι βλέπω εδώ

δεν είναι κάτι που παίρνει πάνω από πεντάλεπτο εφόσον έχεις στημένο το hardware σου.

Και ναι, έχω 120άρα συμμετρική ftth στο σπίτι, αλλά όχι για πολύ καιρό ακόμη διότι μετακομίζω και δεν έχουν σκάψει ακόμη στον συγκεκριμένο δρόμο.

[NoMoreLice]

Δεν βλέπω να κάνει κάτι ριζοσπαστικά διαφορετικό από όσα έχουμε πει. Για p2p telcos με στημένο STUN server και αν έχουν όλοι καλή σύνδεση και χωρίς κάμερα λέει max 20 άτομα (εμέις θέλουμε τουλάχιστον ο δάσκαλος να έχει κάμερα/screen sharing). Από εκεί και πέρα πάει σε server αρχιτεκτονικές.

Easy for private use

Nextcloud Talk is designed for easy installation and operation. Nextcloud hosts a STUN server to facilitate usage behind firewalls and we recommend the installation of a local TURN server to improve connectivity further. Note that calls get fully routed through a TURN server, causing a lot of network traffic. Find documentation on installing a TURN server here.

The peer to peer nature of Talk does inflate network traffic, creating one incoming and sending stream per other participant. This places practical limitations on calls that depend on network capabilities. A typical private Nextcloud Talk setup should handle dozens of calls with each up to 6-10 participants, up to 20 if all participants have a good network connection and do not use video.




Scaling in enterprise setup

To help with scaling, users can disable video. Sending audio and video, as well as the compute power required to decode the video streams on clients, are the biggest limiting factors, with most asymetric internet connections bottlenecked on upstream bandwidth and laptops and mobile devices especially having trouble decoding multiple 480P/30FPS video streams.

The High Performance Back-end offered by Nextcloud partner Struktur includes a Selective Forward Unit (SFU) which solves this bottleneck by receiving one stream from each user and forwarding it as needed. This allows scaling a single call to about 30-50 active participants, up to hundreds when doing a webinar.




Scaling further: webinars, school classes

Webinars and other large scale broadcasting type calls are possible with hundreds of participants. The High Performance Back-end setup includes special features for this.

High Performance Back-end

The HPB also lowers the load from calls on the Nextcloud server, taking care of 'signaling' and optionally enables connecting a SIP bridge so users can dial in by phone into calls.

The HPB runs on-premises, like Nextcloud itself, or through a hosted offering by Struktur AG. Customers should be aware that it has significant dedicated bandwidth and processing needs. The HPB is available through Nextcloud GmbH.

Sign up for a free 30 day test of the hosted HPB offering of Struktur AG in the Talk settings page.