Ανάλυση των προβλημάτων με τις Bittorrent εφαρμογές σε συνδέσεις ΟΤΕ στην Κρήτη

[psyxakias]

Το παρακάτω άρθρο αποτελεί μια τεχνική ανάλυση της ιδιόμορφης συμπεριφοράς ADSL συνδέσεων του ΟΤΕ, στην περιοχή της Κρήτης, όσον αφορά τη διασύνδεση με bittorrent trackers, bittorrent peers καθώς και την ιστοσελίδα του bittorrent client Vuze (πρώην Azureus). Μπορείτε να βρείτε μια απλή αναφορά του προβλήματος σε αυτό το άρθρο, καθώς και να δείτε τι συμβαίνει στην πράξη σε αυτό το video. Αν και η υπόθεση θυμίζει σε κάποια σημεία την μέθοδο της αμερικανικής εταιρείας Comcast και της χρήσης Policy Traffic Switches της Sandvine, για τη μείωση της peer-to-peer κίνησης, δε θα αναλωθούμε σε συνωμοσίες καθώς δεν είναι δυνατόν να γνωρίζουμε με σιγουριά τι συμβαίνει με τα στοιχεία που έχουμε μέχρι τώρα. Αντιθέτως, θα παρουσιάσουμε τα τεχνικά στοιχεία και θα αφήσουμε να βγάλετε τα δικά σας συμπεράσματα.

-- UPDATE 20/01/2011: Απάντηση του ΟΤΕ για τα προβλήματα Bittorrent εφαρμογών στην Κρήτη

[break=Σύντομη περιγραφή πρωτοκόλλων]
Σύντομη περιγραφή πρωτοκόλλων

Προτού παρουσιάσουμε τα στοιχεία, θα θέλαμε να κάνουμε μια σύντομη περιγραφή των πρωτοκόλλων που θα συναντήσουμε.

Θα ξεκινήσουμε με το TCP. Το TCP (Transmission Control Protocol) είναι το πιο διαδεδομένο πρωτόκολλο μεταφοράς δεδομένων του TCP/IP, που χρησιμοποιείται ευρέως στο διαδίκτυο για αξιόπιστη αποστολή και λήψη δεδομένων μεταξύ δύο άκρων, όπου άκρα μπορεί να είναι 2 υπολογιστές. Πρόκειται για connection-oriented πρωτόκολλο που σημαίνει ότι βασίζεται στη λειτουργία μιας ιδεατής σύνδεσης. Προτού ξεκινήσει η ανταλλαγή δεδομένων, μέσω του TCP πρωτοκόλλου, πρέπει να δημιουργηθεί η σύνδεση μεταξύ των 2 άκρων. Για τη δημιουργία της σύνδεσης αυτής γίνεται μια τριμερής επικοινωνία (3-way handshake) με χρήση των tcp flags 'SYN' (synchronization) και 'ACK' (acknowledgement), ξεκινώντας από το άκρο που επιθυμεί πρώτο τη σύνδεση, όπως φαίνεται στο παρακάτω σχέδιο.

Σχέδιο: τριμερής επικοινωνία TCP

Όταν η μεταφορά δεδομένων ολοκληρωθεί και η σύνδεση πρέπει να κλείσει, γίνεται κανονικά μια τετραμερής επικοινωνία (four-way handshake) με χρήση των tcp flags 'FIN' (finished) και 'ACK'.

Ένα άλλο tcp flag που θα συναντήσουμε αρκετά, είναι το 'RST'. Το RST (reset) χρησιμοποιείται για να ενημερώνεται το άλλο άκρο ότι υπάρχει πρόβλημα σύνδεσης και θα πρέπει να κλείσει τη σύνδεση (ή να την επανεκκινήσει). Συνήθως το βλέπουμε είτε στη φάση της δημιουργίας μίας σύνδεσης, όταν ένα από τα δύο άκρα δεν επιθυμεί ή δεν μπορεί να συνδεθεί, είτε στη πορεία της σύνδεσης για να ενημερωθεί το άλλο άκρο ότι διακόπτεται η σύνδεση (πχ λόγω κάποιου προβλήματος). Στη λήψη αυτού του πακέτου, ο παραλήπτης σταματά αμέσως την αποστολή άλλων πακέτων δεδομένων ή ξεκινά νέα σύνδεση αναλόγως την τρέχουσα κατάστασή του.

Το UDP (User Datagram Protocol) είναι το δεύτερο πιο διαδεδομένο πρωτόκολλο μεταφοράς δεδομένων και το κύριο χαρακτηριστικό του είναι η πλήρης απώλεια οποιασδήποτε μορφής ελέγχου. Σε αντίθεση με το TCP, δε χρειάζεται handshake, δε χρειάζεται να κλείσει συνδέσεις διότι πολύ απλά δεν τις άνοιξε ποτέ. Με το UDP, ο αποστολέας στέλνει, ο παραλήπτης "ακούει" για δεδομένα που πιθανώς να τον ενδιαφέρουν και ελπίζουν ότι όλα λειτουργούν όπως πρέπει. Η έλλειψη ελέγχου το καθιστά ταχύτερο από το TCP (μικρότερο overhead) ενώ δίνει τη δυνατότητα σε προγραμματιστές να υλοποιήσουν δικούς τους μηχανισμούς ελέγχου σε υψηλότερα επίπεδα.

Στη συνέχεια, θα ρίξουμε μια γρήγορη ματιά στο IP. Το IP (Internet Protocol) είναι ένα πρωτόκολλο δικτύου και είναι υπεύθυνο για τη μεταφορά των πακέτων από δίκτυο σε δίκτυο. Συγκεκριμένα, για την παρακάτω ανάλυση, μας ενδιαφέρει το πεδίο TTL (Time To Live). Το συγκεκριμένο πεδίο ορίζει τον μέγιστο αριθμό των routers που μπορούν να μεσολαβήσουν μέχρι να φτάσει στον τελικό του προορισμό το κάθε πακέτο. Για την υλοποίηση αυτής της λειτουργίας κάθε ενδιάμεσος router, που προωθεί το πακέτο, μειώνει την τιμή του πεδίου TTL κατά μια μονάδα.

Το HTTP είναι το πρωτόκολλο που χρησιμοποιείται για την επικοινωνία των browsers με τους web servers, κοινώς για να μπορούμε να βλέπουμε ιστοσελίδες. Το πεδίο που μας ενδιαφέρει εδώ είναι το 'Host', που είναι συνήθως μέρος του http header του HTTP 1.1 (της έκδοσης που χρησιμοποιείται, κυρίως, στις μέρες μας). Το περιεχόμενο αυτού του πεδίου είναι το όνομα της σελίδας που μας ενδιαφέρει. Η κύρια χρήση του είναι για να ενημερώσει ο browser τον web server ποια σελίδα θέλουμε να επισκεφθούμε, καθώς υπάρχει περίπτωση να έχουμε πολλές σελίδες πάνω σε μια διεύθυνση IP (virtual hosting).

Το BitTorrent είναι ένα ιδιαίτερα δημοφιλές πρωτόκολλο που αποτελεί, σύμφωνα με στατιστικές, το 27-55% της κίνησης του διαδικτύου (αναλόγως την γεωγραφική θέση). Χρησιμοποιείται για μεταφορές αρχείων μεταξύ χρηστών (peer to peer), χωρίς την μεσολάβηση κεντρικού διακομιστή (server) κατά τη μεταφορά δεδομένων και λειτουργεί ως εξής. Το αρχείο ή τα αρχεία προς μεταφορά χωρίζονται σε μικρά κομμάτια και το κάθε κομμάτι διαθέτει ένα hash κωδικό, που βοηθά στην επιβεβαίωση ορθής μεταφοράς. Ο αρχικός κάτοχος των αρχείων δημιουργεί ένα αρχείο torrent που περιέχει τον αριθμό των κομματιών, το hash του κάθε κομματιού (που δημιουργείται κατά τον αρχικό διαχωρισμό) καθώς και τις διευθύνσεις των trackers. Οι trackers απλά κρατάνε αρχείο για την κατάσταση του συνόλου των χρηστών. Συγκεκριμένα, γνωρίζουν ποια κομμάτια διαθέτει κάθε χρήστης και ενημερώνουν τους χρήστες για το που μπορούν να βρουν τα κομμάτια που τους λείπουν. Για την επικοινωνία χρηστών και trackers, χρησιμοποιείται σε επίπεδο εφαρμογής (application layer) το HTTP πρωτόκολλο ενώ σε επίπεδο μεταφοράς δεδομένων (transport layer) το TCP ή το UDP. Επίσης, για την παραπάνω επικοινωνία, μπορεί να χρησιμοποιηθεί και κρυπτογράφηση.




[break=Περιγραφή προβλημάτων σε συνδέσεις ΟΤΕ στην Κρήτης]
Περιγραφή προβλημάτων σε συνδέσεις ΟΤΕ στην Κρήτης

Όπως προαναφέρθηκε, το άρθρο ασχολείται με μια σειρά προβλημάτων που μέχρι τώρα έχουν παρατηρηθεί μόνο στην περιοχή της Κρήτης και παρουσιάζονται σε ένα απροσδιόριστο αριθμό συνδέσεων ενώ παράλληλα έχουν μεγάλη πιθανότητα να λυθούν προσωρινά αν ο χρήστης προκαλέσει ppp session reset (αποσύνδεση & επανασύνδεση μέσω του router).

Με τη βοήθεια μερικών εθελοντών, που αντιμετώπιζαν παρόμοια προβλήματα, επιβεβαιώσαμε σε πολλαπλές γραμμές 3 συγκεκριμένα προβλήματα που αναλύονται παρακάτω.



[break=Πρόβλημα #1: Αδυναμία επίσκεψης σε announce URLs]
Πρόβλημα #1: Αδυναμία επίσκεψης σε announce URLs

Το πρώτο πρόβλημα που παρατηρήθηκε ήταν ύστερα από αναφορές μερικών χρηστών ότι δεν μπορούν καν να συνδεθούν σε bittorrent trackers. Ακολουθεί packet capture που δείχνει τι ακριβώς συμβαίνει, σε αυτή τη περίπτωση, και από τα δύο άκρα.

Πρόβλημα #1: Packet capture από τον client


Πρόβλημα #1: Packet capture από τον server

Αμέσως μετά την δημιουργία μίας TCP σύνδεσης, βλέπουμε να φτάνει και στα 2 άκρα ένα πακέτο με RST flag. Το πακέτο αυτό και στις δυο περιπτώσεις έχει σαν source ip (πηγή) το άλλο άκρο, αλλά σύμφωνα με τα captures δε φαίνεται να το έστειλε κανένα από τα δύο. Εξετάζοντας περαιτέρω τα πακέτα, βλέπουμε ότι και τα δυο RST έχουν το εξής περιεχόμενο:

00000000000000000000000000000000000000000000

Η πλειοψηφία των RST πακέτων που θα συναντήσει κάποιος, έχουν κενό περιεχόμενο. Αν δεν έχουν κενό, συνήθως αναφέρεται ο λόγος για το οποίον έγινε reset η σύνδεση (π.χ. "Access Denied"). Επίσης, κοιτώντας το Time To Live πεδίο του RST πακέτου, που έλαβε ο client, παρατηρούμε ότι έχει διαφορετική τιμή από τα υπόλοιπα πακέτα που είχε λάβει νωρίτερα από τον server. Για την ακρίβεια έχει την τιμή 30, ανεξάρτητα από τη γεωγραφική θέση του server και τον αριθμό τον ενδιάμεσων routers, κάτι που δημιουργεί ερωτήματα. Παρόμοια περίπτωση με σταθερές TTL τιμές (πχ 30 ή 123) είχανε παρατηρηθεί το 2007 σε καταγγελίες συνδρομητών της Comcast.

Με τη μέθοδο του trial & error, προσεγγίσαμε το πλησιέστερο regular expression που ικανοποιεί το HTTP request για να εμφανιστεί το εν λόγω φαινόμενο και καταλήξαμε στο εξής:

^GET[ ]\{1,\}/announce.*?info_hash=.\{191,\} HTTP.*$

Με απλά λόγια, εάν ο bittorrent client προσπαθήσει να στείλει ένα GET request που ξεκινά με το resource '/announce', έχει ως πρώτη παράμετρο την 'info_hash' και περιέχει μια σειρά από τουλάχιστον 191 χαρακτήρες, παρουσιάζεται το πρόβλημα. Το παραπάνω regular expression καλύπτει την πιο συνηθισμένη εκδοχή σύνταξης του announce URL (μαζί με μια σειρά περίπου 10 παραμέτρων, πέρα του info_hash) που χρησιμοποιούν οι bittorrent clients. Ενδεικτικό παράδειγμα HTTP request από bittorrent client:

GET /announce.php?info_hash=%XXX%XXXXXX%XX%XX%XX%XX%XX%XX%XX%XX%XXX%XX%XX%XX&XX&peer_id=-XXXXXX-%XX%XX%XXX%XX%XXX%XX%XX%XX%XXX&port=XXXXX&uploaded=XXXXXXXX&downloaded=X&left=X&corrupt=X&key=XXXXXXXX&numwant=XXX&compa ct=X&no_peer_id=X&ipv6=XXXX%XXX%XXXXXX%XXXXXX%XXXXXX%XXXXXX%XXXXXX%XXXXXX HTTP/1.1
Host: www.XXXXXXXXXXXXXXXX.com

Οι μόνες εξαιρέσεις που παρατηρήθηκαν είναι στα torrents κάποιων private trackers που τα announcements περιέχουν την 'passkey' παράμετρο πριν από την 'info_hash' ή με οποιαδήποτε αλλαγή της σειράς των παραμέτρων (με πρώτη κάποια άλλη αντί της info_hash), που μπορεί να υλοποιηθεί αλλάζοντας τον κώδικα κάποιων bittorrent clients. Σε αυτές τις 2 περιπτώσεις, δεν παρουσιάζεται καθόλου το πρόβλημα διότι δεν καλύπτεται από το regular expression που αναφέραμε παραπάνω.

Επίσης, το πρόβλημα δεν φαίνεται να εξαρτάται από συγκεκριμένο αριθμό port (πχ 80/TCP) του server ή του χρήστη, ενώ το regular expression δείχνει να βασίζεται σε αλληλουχία των πακέτων. Εάν μετά το αρχικό άνοιγμα της σύνδεσης, ο server μας στείλει δεδομένα πριν στείλουμε εμείς το request τότε το πρόβλημα δεν εμφανίζεται. Επιπροσθέτως το πρόβλημα δε δείχνει να επηρεάζει συνδέσεις με τον tracker όταν αυτές χρησιμοποιούν UDP ή HTTPS trackers (HTTP με χρήση κρυπτογράφησης).

Ο τρόπος για να επιβεβαιώσετε το συγκεκριμένο πρόβλημα είναι αρκετά απλός. Ανοίξτε στο browser σας ένα URL που να ικανοποιεί το παραπάνω regular expression, όπως για παράδειγμα το:

http://www.adslgr.com/announce?info_...89012345678901

Αν λάβετε απάντηση από τον webserver ("Object not found! και "Error 404" στη συγκεκριμένη περίπτωση), δεν επηρεάζεστε. Αν λάβετε μήνυμα λάθους που να αναφέρει "Connection Reset", τότε επηρεάζεστε. Αντί για το adslgr, μπορείτε να ορίσετε στο URL οποιονδήποτε webserver της επιλογής σας. Αντί για κάποιον web broswer, μπορείτε αντίστοιχα να χρησιμοποιήσετε το telnet (θυμηθείτε να ορίσετε πόρτα προορισμού 80 και να χρησιμοποιήσετε HTTP σύνταξη) ή καλύτερα την εφαρμογή wget.

Πρόβλημα #1: Δοκιμή με web browser


Πρόβλημα #1: Δοκιμή με wget client


Πρόβλημα #1: Δοκιμή με telnet client

Το συγκεκριμένο πρόβλημα δεν είναι γνωστό αν εμφανιζόταν στην περίπτωση της Comcast.

[break=Πρόβλημα #2: Αδυναμία σύνδεσης με bittorrent peers]
Πρόβλημα #2: Αδυναμία σύνδεσης με bittorrent peers

Tο δεύτερο πρόβλημα που παρατηρήσαμε, έχει να κάνει με αδυναμία σύνδεσης σε bittorrent peers, όταν δεν χρησιμοποιείται encryption. Για την ανάλυση του προβλήματος, ανεβάσαμε ένα πολύ μικρό αρχείο σε 2 άκρα για να γίνουν οι seeds του swarm. Τα άκρα αυτά είχαν απευθείας πραγματικές IP, για να αποφύγουμε πιθανά προβλήματα NAT, και ήταν ρυθμισμένα να μην υποστηρίζουν encryption. Μετά φτιάξαμε το torrent, χρησιμοποιήσαμε έναν ανοιχτό tracker που υποστηρίζει UDP (για να αποφύγουμε το πρόβλημα #1) και το δώσαμε στον client. Ξεκινήσαμε να καταγράφουμε πακέτα και περιμέναμε. Αρκετή ώρα μετά, ο client δεν είχε λάβει ούτε ένα byte του αρχείου. Σταματήσαμε τις προσπάθειες και κοιτάξαμε τα packet captures.

Πρόβλημα #2: Packet capture από τον peer


Πρόβλημα #2: Packet capture από τον seeder

Παρατηρήσαμε πάλι τα ίδια RST πακέτα με το ίδιο περιεχόμενο και την ίδια σταθερή τιμή στο TTL πεδίο (30) για κάθε RST πακέτο που έλαβε ο client. Ξαναδοκιμάζοντας, αυτή τη φορά με forced encryption, το αρχείο κατέβηκε άμεσα.

Πέρα από την καταγραφή πακέτων, ο μόνος τρόπος να λάβουμε μια ένδειξη για το αν μας συμβαίνει αυτό είναι, μετά από προσπάθειες χρήσης του πρωτοκόλλου bittorrent να δώσουμε την εντολή "netstat -s" και να δούμε το νούμερο των 'Reset Connections' για TCP/IPv4. Tο παραπάνω αποτελεί ένδειξη και όχι απόδειξη καθώς μπορεί να έχουμε πολλά reset connections για άλλους λόγους.

Το συγκεκριμένο πρόβλημα εμφανιζόταν στην περίπτωση της Comcast.

[break=Πρόβλημα #3: Αδυναμία επίσκεψης στη σελίδα γνωστού bittorrent client]
Πρόβλημα #3: Αδυναμία επίσκεψης στη σελίδα γνωστού bittorrent client

Το τρίτο και τελευταίο πρόβλημα έχει να κάνει με αδυναμία σύνδεσης στη σελίδα του γνωστού bittorrent client: Vuze (πρώην Azureus). Κοιτώντας το capture που προέκυψε από την προσπάθεια να φορτώσουμε το www.vuze.com βλέπουμε πάλι ένα εισερχόμενο RST πακέτο με source IP που δείχνει να είναι του webserver.

Πρόβλημα #3: Packet capture από τον client

Πάλι βλέπουμε ακριβώς το ίδιο περιεχόμενο, με πριν, ενώ το TTL περιέργως πάλι έχει την τιμή 30. Με trial & error προσεγγίσαμε το πλησιέστερο regular expression που ικανοποιεί το Host πεδίο του GET request στο εξής:

^[Hh][Oo][Ss][Tt]:.*\.vuze.com$

Θα μπορούσε κάλλιστα να σκεφτεί κάποιος ότι το πρόβλημα σχετίζεται με τη συγκεκριμένη ιστοσελίδα και όχι με τη σύνδεσή μας. Όμως ύστερα από μια σειρά δοκιμών, φάνηκε πως παρουσιάζεται στην επικοινωνία με οποιονδήποτε server (είτε με telnet, είτε ρυθμίζοντας την IP στο HOSTS file). Μόλις στείλουμε Host header που καλύπτεται από το παραπάνω regular expression, η σύνδεση αμέσως κλείνει αντί να μας ενημερώσει ότι δεν υπάρχει η σελίδα.

Οι τρόποι επιβεβαίωσης είναι ακόμα πιο απλοί. Αν σας ανοίγει σωστά η σελίδα www.vuze.com, δεν επηρεάζεστε. Αν όχι, τότε πιθανόν να επηρεάζεστε.

Πρόβλημα #3: Δοκιμή με web browser


Πρόβλημα #3: Δοκιμή με wget client


Πρόβλημα #3: Δοκιμή με telnet client

Το συγκεκριμένο πρόβλημα δεν είναι γνωστό αν εμφανιζόταν στην περίπτωση της Comcast.

[break=Λοιπές δοκιμές, Παρατηρήσεις, Επίλογος, Credits]
Λοιπές δοκιμές, Παρατηρήσεις, Επίλογος, Credits

Πέρα από τα προβλήματα που διερευνήθηκαν, μετά από αναφορές στο forum του adslgr.com, κάναμε και μερικές δοκιμές για να ικανοποιήσουμε την περιέργεια μας. Από αυτές καταλήξαμε στα εξής:

• Οι συνδέσεις ΑΡΥΣ στην ίδια γεωγραφική περιοχή δεν επηρεάζονται.
• O bras δεν αποτελεί κριτήριο για την εμφάνιση του προβλήματος.
• Το δίκτυο στο οποίο ανήκει η IP , τουλάχιστον μέχρι και /24 (X.X.X.*), δεν αποτελεί κριτήριο για την εμφάνιση του προβλήματος. Αν και στο αντίστοιχο νήμα γίνεται λόγος για "προβληματικές" σειρές διευθύνσεων IP (IP ranges), δεν πιστεύουμε ότι αυτές αποτελούν το πιο πιθανό κριτήριο. Δεν είναι απίθανο να υπάρχει μια τυχαία λίστα με συγκεκριμένες IPs (/32) που επηρεάζονται, αλλά αυτό δεν είναι κάτι το εύκολα διαχειρίσιμο. Πιο πιθανό κριτήριο θεωρούμε κάποια Layer2 πληροφορία (πχ. svlan/vlan) ή κάποιο καθαρά Layer2 μονοπάτι. Ανάλυση των traceroutes από hosts που επηρεάζονται δεν είχε κάποιο αποτέλεσμα. Όλα αυτά βέβαια είναι υποθετικά και είναι δύσκολο να κάνουμε ορθές υποθέσεις χωρίς να γνωρίζουμε την ακριβή τοπολογία δικτύου του παρόχου.
• Αν τα 2 άκρα βρίσκονται στην Κρήτη και η δρομολόγηση γίνεται απευθείας από bras σε bras, το φαινόμενο δεν φαίνεται να εμφανίζεται ποτέ. Αντιθέτως, εάν η δρομολόγηση γίνεται μέσω Αθήνας ή ένα από τα δυο άκρα βρίσκεται εκτός Κρήτης, ακόμα και αν είναι στο δίκτυο του ΟΤΕ, το πρόβλημα εμφανίζεται με κάποιες IPs. Σύμφωνα με αυτή τη συμπεριφορά, αν υπάρχει κάποια "προβληματική συσκευή", αυτή πιθανώς να βρίσκεται μεταξύ των bras Κρήτης και Αθήνας.

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

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

• BlindG -- επιμέλεια κειμένων
• eLeKtriK EyE -- βοήθεια σε δοκιμές
• haris_led -- βοήθεια σε δοκιμές
• mpetou -- αρχική διερεύνηση του προβλήματος, βοήθεια σε δοκιμές
• mrsaccess -- βοήθεια σε δοκιμές, καταγραφή & επιμέλεια video
• nm96027 -- επιμέλεια κειμένων
• psyxakias -- διερεύνηση & τεχνική ανάλυση των προβλημάτων, επιμέλεια κειμένων
• Someonefromhell -- διερεύνηση & τεχνική ανάλυση των προβλημάτων
• Συντονιστική Ομάδα ADSLgr -- φιλοξενία και συμβουλές
• Όλους όσους συμμετείχαν στο thread συζήτησης και στις δοκιμές

Πηγές Πληροφόρησης

• ADSLgr είδηση: Προβλήματα με Bittorrent εφαρμογές σε συνδέσεις ΟΤΕ στην Κρήτη
• Youtube: Προβλήματα με Bittorrent σε συνδέσεις ΟΤΕ στην Κρήτη
• ADSLgr: conn-x και φιλτράρισμα torrent;
• DSLReports: Comcast is using Sandvine to manage P2P connections
• Wikipedia: BitTorrent(protocol)
• Wikipedia: Hypertext Transfer Protocol (HTTP)
• Wikipedia: Internet Protocol
• Wikipedia: Packet information technology
• Wikipedia: TCP/IP Model
• Wikipedia: Time to live (TTL)
• Wikipedia: Transmission Control Protocol (TCP)
• Wikipedia: User Datagram Protocol (UDP)

[villager]

psyxakias μπράβο για την πολύ καλή δουλειά σας πραγματικά

Ελπίζω αυτό να μην είναι κάποιο προμήνυμα για κακά νέα του torrent!!

Edit: Μπράβο σε όλους που ασχολήθηκαν με το περιεργο αυτό θέμα.
* BlindG -- επιμέλεια κειμένων
* eLeKtriK EyE -- βοήθεια σε δοκιμές
* haris_led -- βοήθεια σε δοκιμές
* mpetou -- αρχική διερεύνηση του προβλήματος, βοήθεια σε δοκιμές
* mrsaccess -- βοήθεια σε δοκιμές, καταγραφή & επιμέλεια video
* nm96027 -- επιμέλεια κειμένων
* psyxakias -- διερεύνηση & τεχνική ανάλυση των προβλημάτων, επιμέλεια κειμένων
* Someonefromhell -- διερεύνηση & τεχνική ανάλυση των προβλημάτων
* Συντονιστική Ομάδα ADSLgr -- φιλοξενία και συμβουλές
* Όλους όσους συμμετείχαν στο thread συζήτησης και στις δοκιμές

[psyxakias]

Off Topic

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

[euri]

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

[Seitman]

Εξαιρετική δουλειά

[SfH]

Να προσθέσω ότι μέχρι χτες, το πρόβλημα εμφανιζόταν και σε μια connx@work με static ip. Σήμερα δείχνει να μην εμφανίζεται. Εκτώς αν άλλαξε κάτι πιο γενικό, θα το θεωρούσα πια σχεδόν απίθανο το πρόβλημα να έχει να κάνει με συγκεκριμένες IPs.

EDIT : Χρμ, τελικά ίσως και το πρόβλημα να "λύθηκε" γενικά

[Gdrdasky]

Πολύ καλή παρουσίαση....

[vlad]

πολυ καλο το βιντεο παιδια,απλο και κατανοητο