Mitsaras wrote:

Ουχ, και άρχισα να νομίζω ότι εγώ ήμουν ο παλαβός που έφτιαξα 7 intercommunicating εφαρμογές αποκλειστικά με sockets!

Χεχε σκεπτόμαστε .... .net για αυτό... Παντως για την ιστορία όλες πιο παλιές εκδόσεις, είναι με sockets (υπάρχει έκδοση και με χρησιμοποίηση του VBI του τηλεοπτικού σήματος όπως ανέφερε ο pkanavos).

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

Ευχαριστώ,

kosdian

anjelinio wrote:

Και στην τελική, δε νομίζω οτι κάποιος θα σκεφτόταν ποτέ να γράψει κάτι real-time, ένα messenger στην τελική βρε αδερφέ με ... web services ή remoting ...

Εγώ όχι μόνο έχω σκεφτεί να γράψω real-time εφαρμογή με remoting αλλά το έχω υλοποιήσει κιόλας και ομολογώ ότι με προβλημάτισες λιγάκι μήπως και κάτι μου έχει διαφύγει σχετικά με τον τρόπο λειτουργίας του Remoting.

Οταν μετέφερα τις εφαρμογές μου από VB6 σε .ΝΕΤ, επειδή σε άλλες περιπτώσεις την Remote επικοινωνία στο Internet την έκανα με XMLΗttp και σε άλλες με Sockets, αντικατέστησα το XMLHttp με Web Services και τα Sockets με Remoting (το οποίο ουσιαστικά για την μεταφορά δεδομένων αν δεν κάνω λάθος χρησιμοποιεί Sockets). Τα Sockets τα χρησιμοποιούσα σε περιπτώσεις που ο Server χρειαζόταν να στείλει κάποια messages σε clients. Οταν ο Client λάμβανε το μύνημα τότε πάλι έπερνε τα Data με XMLHttp.

Την απόφαση αυτή την πήρα επειδή θεώρησα ότι οι εφαρμογές μου (με real time απαιτήσεις) μου επέτρεπαν να θυσιάσω την μικρή διαφορά του χρόνου απόκρισης (real-time), για να έχω flexibility στην διαχείρηση Remote Objects.
Ομολογώ ότι δεν σκέφτηκα (προφανώς γιατί οι εφαρμογές μου μου το επέτρεπαν) να ξαναγράψω τα προγράμματα για την επικοινωνία του Client με τον Server αφού το κάνει από μόνο του το Remoting.

Αλλωστε για να διατηρήσω το business logic σε οποιδήποτε εφαρμογή μου έπρεπε πριν στείλω ένα object με sockets να το κάνω serialization και να το μετατρέψω σε binary και αφού το λάβω στον Client να το κάνω deserialization σε object. Οτι κάνω δηλαδή και στο Remoting. Ετσι λοιπόν η ΣΥΝΟΛΙΚΗ διαφορά του χρόνου απόκρισης μειώνεται δραματικά. Μία από τις εφαρμογές μου μεταφέρει πολύ μεγάλους όγκους δεδομένων (15 περίπου φωτογραφίες πραγματογνωμόνων σε κάθε request, από ατυχήματα και προασφαλιστικό έλεγχο με Web Service) σε κάποιον Server και αυτός με τη σειρά του με Remoting στέλνει message στην εφαρμογή  που βρίσκεται στην Ασφαλιστική εταιρία για να τραβήξει τα δεδομένα.
Αυτό το σύστημα λειτουργεί εδώ και ενάμιση χρόνο αψογα.

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

Βεβαίως οι ιδέες και οι αντιρρήσεις είναι πάντα πάντα, πάρα πολύ χρήσιμες.

 

---

Σταύρος Βαλσάμης
Προγραμματιστής

Όταν μίλησα για real-time, είχα στο μυαλό μου ένα socket μονίμως ανοιχτό απο client σε server. Απ'το output stream γράφεις πρός τον server, απ'το input stream διαβάζεις απ'τον server .. και τα τούμπαλιν απ'την άλλη μεριά.

Web Services, Remoting κτλ, λειτουργούν μια χαρά, αλλά η διαφορά (ίσως καθαρά ακαδημαική βέβαια, είναι οτι είναι request/response oriented. Ήτοις, όχι "καθαρά" real time.

Επίσης, αν μπλέξεις με object (de)serialization over those sockets, τότε φυσικά καλύτερο είναι να κοιτάξεις προς το remoting & W/S, αφού στην ουσία καλείσαι να υλοποιήσεις πάνω κάτω το ίδιο stack ως ένα βαθμό.

Αν λοιπόν το real time & to performance είναι κύρια προτεραιότητα, εγώ θα έγραφα sockets. Δεύτερος υποψήφιος το remoting, και πολύ πίσω τα Web Services.

Καλό βράδυ μας

---

Angel
O:]

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

Η λύση του ενός TCP connection από τον client στο server φαίνεται να είναι η απλούστερη σαν ιδέα, αν και δεν θα είναι και η αποδοτικότερη όσον αφορά το bandwidth. Απλά θέλει λίγη προσοχή στο concurrency, καθώς θα πρέπει να ενημερώνονται μερικές χιλιάδες connections ταυτόχρονα.

Μια καλύτερη λύση θα ήταν να στέλνονται UDP πακέτα στους clients και να χρησιμοποιείται error correction. Δυστυχώς, δεν ξέρω κάποιο έτοιμο component ή βιβλιοθήκη που να το κάνει αυτό σε .NET. Άρθρα και βιβλία, υπάρχουν άπειρα. Αν έχει όρεξη κανένας, αξίζει να ψάξει για αλγόριθμους LDPC, Reed-Solomon, Turbocodes. Και αν γνωρίζει κανείς κανένα component να το φωνάξει!

---

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

pkanavos wrote:

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

Και η συγκεκριμένη υλοποίηση έχει τα προβλήματά της, όπως την κακή ποιότητα του τηλεοπτικού σήματος όπου αντιμετωπίζεται με error correction κλπ, άλλα το ποιό σημαντικό είναι οτι έχουμε να κάνουμε πλέον με μονόδρομη επικοινωνία, έτσι έχουμε τα προβλήματα οτι πρέπει να στέλνεις data περιοδικά, τα ιστορικά στο τέλος της συνεδρίασης με intervals κλπ. Μια ακόμη λύση παρόμοια με την VBI και με παρόμοια μειονεκτήματα αλλά ποιο αξιόπιστη είναι με datacasting μέσω δορυφορικού σήματος.

Kosdian

Ή περιμένεις μερικούς μήνες για την ψηφιακή τηλεόραση . Δεν έχω ψάξει το DVB-T αλλά το δορυφορικό DVB-S χρησιμοποιεί turbocodes.

Έχεις σκεφτεί να συνδιάσεις τις δύο λύσεις? Τηλεοπτικό (ή ότι άλλο) feed για αυτούς που απαιτούν real-time επιδόσεις, και τα περιοδικά data κλπ μέσω internet? Αν δεν έχετε πρόβλημα με το bandwidth του server και την ισχύ των μηχανημάτων, η λύση με τα TCP connections από τους clients στο server φαίνεται εύκολη στην υλοποίηση.

Αν βέβαια είχε κανείς υπόψη μια (έτοιμη κατά προτίμηση) λύση για datacasting, θα ήταν πολύ πιο ενδιαφέρον. Τώρα που άρχισα να το (ξανα)ψάχνω το θέμα έχει ενδιαφέρον. Το πρόβλημα είναι, ότι χρειάζεται χρόνο και διάβασμα για να καταλάβεις τους αλγόριθμους και το τί κάνουν, και ποιός είναι κατάλληλος για την περίπτωση σου.
Μέχρι στιγμής έχω καταλάβει ότι ζητάμε αλγορίθμους για bit-erasure ή καλύτερα, packet-erasure channels, κανάλια δηλαδή τα οποία δεν εμφανίζουν λάθη αλλά απορρίπτουν ολόκληρα bits ή πακέτα. Αν κωδικοποιήσεις το feed με αυτό τον τρόπο και το στείλεις με multicast σαν UDP, για κάθε πακέτο θα φύγουν 2 ή περισσότερα. Το καλό είναι ότι μπορούν να χαθούν πολλά πακέτα (πάνω από 50% νομίζω) αλλά ο αλγόριθμος θα καταφέρει να ξαναφτιάξει όλα τα αρχικά πακέτα.

Αν θες να το σκαλίσεις, δες το MCLv3: an Open Source Implementation of the ALC and NORM Reliable Multicast Protocols, το οποίο είναι σε C++.

Α! Τώρα που σκάλιζα, είδα ότι στα Windows 2003 υπάρχει και το PGM, ένα πρωτόκολλο για reliable multicasting. Μόνο για 2003 δυστυχώς. Δεν ξέρω αν μπορείς να απαιτήσεις από τους πελάτες σου να έχουν Windows 2003 αλλά είναι και αυτό μια δυνατότητα. Αν πας στη σελίδα του Microsoft Research για Multicasting θα βρεις link για ένα implementation σε κώδικα, καθώς και ότι το πρωτόκολλο αυτό υποστηρίζεται από Cisco routers.
Το PGM χρησιμοποιείται και από το MSMQ v3 για real-time multicasting. Υποψιάζομαι μάλιστα ότι όταν εγκαθιστάς το MSMQ στα XP προστίθεται και το PGM, αλλά δεν ξέρω αν θα μπορέσεις να το καλέσεις από τα sockets.

ΑΜΑΝ! Ψάχνω για υλοποιήσεις εδώ και 3 ώρες! Λοιπόν, το κόβω, για να κάνω και άλλες δουλειές! Να' σαι καλά βρε kosdian, αυτό το θέμα έχει πολύ ενδιαφέρον!

 

---

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

Τώρα που το ξανασκέφτομαι, το streaming δεν ακούγεται και τόσο καλή ιδέα. Αυτό τον καιρό τουλάχιστον οι επιδόσεις των γραμμών ADSL στη μεταφορά πακέτων UDP μικρού μεγέθους είναι το λιγότερο χάλια. Γι αυτό και τόσος κόσμος έχει πρόβλημα στη χρήση του VoIP. Αν ο ΟΤΕ δεν μπορεί να κάνει τις σωστές ρυθμίσεις QoS στο δίκτυο του, η χρήση UDP είναι επισφαλής το λιγότερο.

---

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

Δυστηχώς το συγκεκιμένο πρόβλημα με τον περιορισμό των πακέτων θα μας παιδεύει πολύ καιρό. Και ολά αυτά γιατί ο ΟΤΕ έχει αδυναμία να ρυθμίσει τα DSLAM. Ευτυχώς που υπάρχει και η Vivodi και έλυσα τα προβλήματά μου που εκ των πραγμάτων είναι υποχρεωμένη να έχει το συγκεκριμένο πρόβλημα λυμένο μιας και σου δίνει DSLPhone το οποίο δεν θα δούλευε σωστά με την ύπαρξη τέτοιων προβλημάτων.

kosdian wrote:

Και ολά αυτά γιατί ο ΟΤΕ έχει αδυναμία να ρυθμίσει τα DSLAM.

Έχει αδυναμία ή μήπως...

---

Vir prudens non contra ventum mingit

Ελληνικό "δαιμόνιο". Βασιζόμενοι στη δικαιολογία της μη εγγυημένης ταχύτητας, μπορεί να πέσει η ταχύτητά σου μέχρι και στο 1/4 (πχ από τα 40KB/s στα 10), είναι αναγκασμένοι να πληρώνουν λιγότερα για νέες επενδύσεις και DSLAM.

Α, και αν κάποιος δύσμοιρος τους τηλεφωνήσει για να διαμαρτυρηθεί επειδή η 384 σύνδεσή του κατεβάζει με 15KB/s και ζητήσει τεχνικό, την πάτησε. Στην ουσία τον απειλούν, με την εξής δικαολογία: "η ταχύτητα θεωρείται φυσιολογική, και αν ο τεχνικός όντως διαπιστώσει ταχύτητα παρόμοιου επιπέδου, θα χρεωθείτε την επίσκεψη".

Άντε μην αρχίσω σε ότι αφορά τον ΟΤΕ, γιατί τα έχω πολλά και μαζεμένα...

---

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

Το θέμα δεν είναι η περιορισμένη ταχύτητα αλλά η κακή ρύθμιση του δικτύου. Ό,τι ταχύτητα και να έχεις, αν χρησιμοποιείς εφαρμογή που στέλνει πολλά μικρά πακέτα θα έχεις πρόβλημα. Αν αντίθετα στέλνεις μεγάλα πακέτα δεν έχεις πρόβλημα. Για να το δοκιμάσεις, τρέξε
ping -t κάποια διεύθυνση
και μετά ξεκίνα κάποιο πρόγραμμα που δημιουργεί πολλά μικρά πακέτα, π.χ. μια οποιαδήποτε εφαρμογή VoIP. Θα διαπιστώσεις ότι το response time του ping θα αρχίσει να ανεβαίνει μέχρι που θα αρχίσουν τα request timeout.

Στην περίπτωση του real-time feed η κατάσταση αυτή είναι καταστροφική, γιατί η το feed λογικά θα είναι πολλά μικρά πακέτα. Εκτός και αν χρησιμοποιούνται μεγαλύτερα πακέτα γεμάτα nulls απλά και μόνο για να αποφευχθεί το φρακάρισμα. Έτσι όμως πάει χαμένο το bandwidth αλλά μειώνεται και η αντοχή σε χαμένα πακέτα.

---

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

Η περιορισμένη ταχύτητα μπορεί να είναι (και συνήθως είναι) αποτέλεσμα κακής ρύθμισης, αλλά και περιορισμένου bandwidth (γνωστό και ως "ο πνιγμός των SYN πακέτων").

Να προσδιορίσουμε όμως το τι εννοούμε με την έννοια μικρά και μεγάλα πακέτα. Θεωρητικά, 1472 είναι αυτό του LAN. Οτιδήποτε μεγαλύτερο θα κατακερματίζεται (sic). Οπότε μιλάμε για πακέτα μικρότερα του 1,5KΒ;

---

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