Θα ήθελα να ρωτήσω, έχουν αναφερθεί προβλήματα στη λειτουργία των Sockets του .net framework εντός VPN (hardware VPN routers);

Ένα suite αποτελούμενο από ένα σύνολο εφαρμογών τις οποίες αναπτύξαμε και επικοινωνούν μεταξύ τους μέσω sockets, μας δημιουργεί πρόβλημα σε ότι αφορά την επικοινωνία μεταξύ των μερών του, όταν παρεμβάλλεται VPN.
Συγκεκριμέναμ τα λάθη που λαμβάνω, αφορούν στην αδυναμία εύρεσης του remote host. Εν τω μεταξύ, όλες οι άλλες εφαρμογές (από remote desktop, μέχρι και ftp), καθώς και το ping, λειτουργούν κανονικά.

Υπάρχει κάτι που μπορεί να μου διέφυγε; Απ' όσο ξέρω, στο VPN έχουν ενεργοποιηθεί τα πρωτόκολλα IPSEC, PPTP & L2TP, αλλά δυστυχώς, δε διαθέτω περισσότερα στοιχεία αυτή τη στιγμή για το ακριβές setup του. Επίσης, οι εφαρμογές αυτές καθ' αυτές, χρησιμοποιούν τις τυπικές μεθόδους του System.Net.Sockets.Socket, καθώς και κάποια από τα static methods του Dns (πχ GetHostEntry).

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Post απο το 2006 ......... μάλιστα. Έχω και εγω το ίδιο πρόβλημα με sockets και VPN.
Βασικά είναι ένα client-server application που επικοινωνούν με TCP σε μια port. Το πρόβλημα δεν υπήρχε στο τοπικό δύκτιο, αλλά όταν έβαλα το VPN στη μέση είχα απώλια πακέτων.
Στην εξίσωση τελικά έβαλα τον καλό μου φίλο Wireshark. Η απάντηση που μου έδωσε καθόλου δεν μου άρεσε, βασικά τα πακέτα έρχονταν κανονικά και το application απλά τα αγνοούσε!!!!!!!
WTF? why is that?
Τελίκα η λύση ήταν στο port. Όταν έκανα το request στο port (π.χ. 2025) η απάντηση δεν έρχοταν στο port (π.χ. 2024) που έιχα τον listener αλλα σε ένα random port στο οποίο έγινε το πρώτο request.
Βασικα κάνω και σχεδιάγραμα γιατί καλύτερη επεξήγηση.
SENT "HI" on port 2025                                   
                                                                      Received "Hi" on port 2025 from port 32444   (!!!!!! ναι ναι σωστό, οταν ο client στέλνει στο port 2025 δεν συνεπάγετε ότι στέλνει και απο αυτο)
                                                                      SENT RESPONSE "EISAI KALA?" on port 32444  (και εδώ ειναι το λάθος!!!, o client δεν ακουει αυτο το port)
(client σφυρίζει αδιάφορα)

Τώρα εν κατακλίδη αυτο γιατί δεν το κάνει στο local LAN, "εννα σπάση η κκελε μου"

---

http://www.iezekiel.com

Τα sockets είναι ο πιο low-lever τρόπος επικοινωνίας που μπορεί να χρησιμοποιήσει κανείς και απαιτεί να ορίσεις τα πάντα, όπως διαπίστωσες κι εσύ. Επίσης, οι ρόλοι client/server δεν είναι σταθεροί και εναλλάσσονται ανάλογα με το ποιός μιλάει σε ποιόν. Όταν ένα μηχάνημα μιλάει σε ένα άλλο φέρεται ως client και το άλλο μηχάνημα ως server και απλά στέλνει πληροφορίες. Όταν το δεύτερο μηχάνημα απαντάει αναλαμβάνει αυτό πλέον ρόλο client και μιλάει στο server. Για να έχεις αμφίδρομη επικοινωνία θα πρέπει κάθε υπολογιστής να έχει και ένα TcpListener και ένα TcpClient που θα αναλαμβάνουν ο καθένας το άκου και το στείλε.
Θα μπορούσες πάντως να είχες αποφύγει το πρόβλημα αν είχες ρίξει μία ματιά στα παραδείγματα του documentation των κλάσεων TcpClient, TcpListener, NetworkStream καθώς παρουσιάζουν και τις δύο περιπτώσεις.

Τέλος, στις περισσότερες εφαρμογές η χρήση των sockets δεν βοηθάει, καθώς απαιτεί να υλοποιήσεις πολλά πράγματα που σε άλλες τεχνολογίες είναι έτοιμα. Τα Web Services και το WCF παρέχουν ασφάλεια, έλεγχο του πότε και ποιός μιλάει σε ποιό port και με τί σειρά, έλεγχος ότι ολόκληρες οι κλήσεις έφτασαν, ποιό είναι το encoding των δεδομένων κλπ., κλπ. Αυτός είναι και ο λόγος που η απευθείας χρήση sockets έχει πλέον περιοριστεί σε εξαιρετικά ειδικές περιπτώσεις.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos