Χαιρετώ την εκλεκτή παρέα.

Θα ήθελα να σας ρωτήσω όταν κάποιος θέλει να έχει μια εφαρμογή server/client η οποία έχει μεγάλο όγκο δεδομένων που παίζουν real time, ποια θα ήταν η καλύτερη επιλογή? Να χρησιμποποιεί την πόρτα 80 (αλλά όχι http) ή να χρησιμοποιεί μια πόρτα πχ την 7000 για να μπορεί εύκολα να παίζει σε ένα εταιρικό δύκτιο. Εννοείται πως το server κομμάτι της εφαρμογής θα είναι κάπου στο Internet. Στην 80 δεν θα υπάρχουν περισσότερα προβλήματα λόγω του filtering που κάνουν τα περισσότερα firewalls κλπ?

Ευχαριστώ

Αν κατάλαβα θέλεις να φτιάξεις μια εφαρμογή client η οποία θα επικοινωνεί με το server μέσω tcp ή udp connections και δικού σου πρωτοκόλου? Και υποθέτω ότι οι clients θα έχουν χαμηλές ταχύτητες? Διαφορετικά θα ήταν προτιμότερο να χρησιμοποιήσεις web services. Όχι μόνο θα χρησιμοποιούσες ένα στανταρ τρόπο επικοινωνίας, αλλά δεν θα είχες να ασχοληθείς και με την υλοποίηση του πρωτοκόλου, τη δοκιμή του, την ασφάλεια, το stress test και ένα κάρο άλλους μπελάδες.

Τώρα, το ποιά πόρτα θα χρησιμοποιήσεις εξαρτάται από το πως είναι ρυθμισμένα τα firewall και οι router μπροστά από το server σου. Αν δεν έχεις κάποιο web server στο ίδιο μηχάνημα μπορείς να χρησιμοποιήσεις και το port 80. Τους ελέγχους και τα φιλτραρίσματα τους χρειάζεσαι ακόμα και αν χρησιμοποιήσεις κάποιο άλλο port για να εμποδίσεις τυχόν επιθέσεις. Η καλύτερη λύση είναι να ορίζεις το port στο configuration της εφαρμογής και να το αλλάζεις ανάλογα με το αν θα τρέχει σε περιβάλλον internet ή intranet.

Έχω και μια άλλη απορία. Αν χρησιμοποιείς δικό σου πρωτόκολλο για τις κλήσεις, τί θα κάνεις για την ασφάλεια των μηνυμάτων? Θα χρησιμοποιήσεις VPN? Δικιά σου κρυπτογράφηση?

Μήπως θα ήταν καλύτερο να χρησιμοποιήσεις Web Services ή ακόμα και Remoting για να αποφύγεις τους πονοκεφάλους?

---

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

Η εφαρμογή είναι εφαρμογή real time μετάδοσης Stock Data, απαιτεί μεγάλο όγκο δεδομένων, τα οποία και θα συμπιέζονται και θα κρυπτογραφούνται απο τον server. Τα data streams πρέπει να μεταδίδονται real time, και θα γίνονται γίνονται άλλοτε push από τον server και άλλοτε pull απο τον client (π.χ. στην εκκίνηση του) και για αυτό και τα Web Services μου φαίνονται λίγο δύσκολο να χρησιμοποιηθούν στην πρώτη περίπτωση.

 Επίσης το Remoting το έχω χρησιμοποιήσει σε διάφορες intranet εφαρμογές αλλα διστάζω να το χρησιμοποιήσω σε Internet Applications και διστάζω να το κάνω λόγω του overhead που ενδεχομένως να προκαλεί το serialization (έστω και binary), ενώ σε δικό μου πρωτόκολο θα μεταφέρονται μόνο τα pure data και θα έχω το έλεγχο του τι μεταδίδεται.

Το πρόβλημα με τα ports προέκυψε απο συζήτηση με τεχνικούς για το default port εποικινωνίας γιατί αν θα χρησιμοποιηθεί η  80 πόρτα η οποία είναι συνήθως ανοικτή στα εταιρικά δύκτια. Δηλαδή θέλω όσο δυνατό να μην αναγκάζω τον  κάθε admin  να αλλάζει το υπάρχον setup στο εταιρικό του δύκτιο.

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

Ευχαριστώ,

kosdian

Χμμμ κάτι Original μου θυμίζει ... έπιασα το περιβάλλον! Δεν σου λέω να χρησιμοποιήσετε κωδικοποιημένο τηλεοπτικό σήμα γιατί είμαι σίγουρος ότι το έχετε τουλάχιστον σκεφτεί!

Υποθέτω ότι θα έχετε διάφορα κανάλια για να μεταδίδετε την πληροφορία και με διαφορετικές χρεώσεις και καθυστερήσεις, τα φθηνότερα με pull, τα ακριβότερα με push και real-time. Ειδικά στην υλοποίηση της τελευταίας υπάρχουν διάφορες δυνατότητες.
Πέρα από την χρήση TCP συνδέσεων μεταξύ client και server, μπορείς να ρυθμίσεις το QoS των router σου έτσι ώστε τα πακέτα των real-time stream να φεύγουν με μεγαλύτερη προτεραιότητα.
Αν η ταχύτητα είναι το σημαντικότερο, μπορείς να στέλνεις UDP πακέτα στους clients και αυτοί να ζητούν με pull όσα πακέτα τους λείπουν. Μια πιο ελαφριά έκδοση αυτής της τεχνικής είναι να στείλεις UDP πακέτα για να ειδοποιήσεις μόνο τους client, και αυτοί μετά ζητούν τα δεδομένα που πραγματικά τους ενδιαφέρουν.
Μια πιο extreme λύση είναι να χρησιμοποιήσεις UDP πακέτα και αλγορίθμους ανάκτησης πακέτων (turbocodes, LDPC). Η τεχνική αυτή χρησιμοποιείται στα κινητρά 3G και τις ψηφιακές δορυφορικές μεταδόσεις (DVB-S)

Για τα ports τώρα. Το port 80 (και συνήθως όλα τα ports) είναι ανοιχτό στα firewalls για κλήσεις προς τα έξω, όχι προς τα μέσα. Είτε το 80 χρησιμοποιήσεις είτε το 7000 ο admin του πελάτη σου θα πρέπει να ανοίξει το port και να το κάνει redirect στο μηχάνημά του client.
Μία λύση θα ήταν ο κάθε client να ξεκινάει τη σύνδεση με το server σε όποιο port θέλεις και μετά να ακούει τί θα του στείλει ο server. Έτσι όμως ο κάθε client θα κρατάει ένα connection ανοικτό στο server. .

---

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

kosdian wrote:

Το πρόβλημα με τα ports προέκυψε απο συζήτηση με τεχνικούς για το default port εποικινωνίας γιατί αν θα χρησιμοποιηθεί η  80 πόρτα η οποία είναι συνήθως ανοικτή στα εταιρικά δύκτια. Δηλαδή θέλω όσο δυνατό να μην αναγκάζω τον  κάθε admin  να αλλάζει το υπάρχον setup στο εταιρικό του δύκτιο.

Εδώ υπάρχει μια παραπλάνηση. Ο καιρός των εταιρικών δικτύων που ότι ήθελε έμπαινε από την πόρτα 80 έχει περάσει. Θα πρέπει να λαφθεί υπόψη ότι πλέον τα firewall είναι "έξυπνα" και επειδή είναι η πόρτα 80 δεν σημαίνει ότι μπαίνει ότι θέλει από εκεί. Τα "έξυπνα" firewall κάνουν ανάλυση των πακέτων του application πρωτοκόλλου, δηλαδή HTTP/SMTP/POP3, οπότε το "μπορείς να περάσεις ότι θες" από την πόρτα 80, είναι λίγο έως πολύ, ουτοπικό.

Θα πρέπει να σκεφτείς σοβαρά την χρήση των WebServices, και τον extensions τους που υποστηρίζουν και κρυπτογράφηση, και συμπίεση, έστω και αν σημαίνει ότι πρέπει να έχεις ένα πολύ δυνατό μηχάνημα από πίσω, ή και web farm.

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

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Οι μεγάλες ποσότητες δεδομένων που περίπου κυμαίνονται; Και οι χρόνοι καθυστέρησης για να το θεωρούμε real-time ποιοι είναι;

Πάντως κι εγώ δεν μπορώ να σκεφτώ κάποιον λόγο που να μην παίζει με web services. Εκτός των άλλων προτερημάτων, με web services μπορείς να έχεις έτοιμη και μια αρκετά καλή πλατφόρμα caching, η οποία είναι μεγάλο avantage.

Για τις πόρτες, ο server μπορεί να ακούει σε όποια πόρτα θέλει (οπότε ανοίγεις την αντίστοιχη πόρτα στο firewall) και οι clients του μιλάνε απ' ευθείας σ' αυτήν την πόρτα χωρίς να χρειάζεται άλλη τροποποίηση.

---

Χρήστος Γεωργακόπουλος

Συμφωνώ με τον cgeo.
Ο μόνος λόγος που εγώ ίσως προβληματιζόμουνα στο να χρησιμοποιήσω Web Services, είναι η περίπτωση που η μετάδοση δεδομένων δεν είναι On Demand από τον Client, αλλά ακόμη και έτσι να είναι, έχει να κάνει με το χρόνο καθυστέρησης γιατί μπορείς να κάνεις από το Web service περιοδικά Requests.
Οσο για τον όγκο των δεδομένων (σε περίπτωση που το firewall ή το σύστημα έχει περιορισμό), μπορείς να σπάσεις το request σε κομμάτια και με SessionEnabled WebMethods στο Server και CookieContainer στο WebService μπορείς να το στείλεις κομματιαστά.

---

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

Στη συγκεκριμένη περίπτωση το real-time είναι αρκετά real-time.

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

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

Το Χρηματιστήριο παρέχει σε κάποιες εταιρείες τις κινήσεις καθώς αυτές γίνονται. Οι εταιρείες αυτές παρέχουν μετά διάφορα feeds στο κοινό σε διάφορες τιμές. Τα φθηνότερα feeds έχουν σημαντική καθυστέρηση, ενώ το real-time είναι το ακριβότερο feed.
Φανταστείτε τώρα μερικές εκατοντάδες πελάτες να καλούν συνέχεια το server για να πάρουν τις τελευταίες κινήσεις! Δεν είναι και πολύ ωραία εικόνα.

Τον καιρό της φούσκας (και σήμερα απ' όσο ξέρω) το real-time feed μεταδιδόταν σαν ειδικά κωδικοποιημένο σήμα παράλλημα με το τηλεοπτικό σήμα. Οι πελάτες είχαν μια client εφαρμογή η οποία έπαιρνε το feed από τον αποκωδικοποιητή και το έστελνε σε όσα workstations είχαν license. Η λύση αυτή ήταν πραγματικά real-time και δεν επιβάρυνε το server των εταιρειών που τη χρησιμοποιούσαν. Το πρόβλημα ήταν ότι έπρεπε ο τεχνικός τους να πηγαίνει σε κάθε πελάτη και να στείνει αποκωδικοποιητές, clients και licenses. Με άλλα λόγια, το deployment των clients ήταν δύσκολο. Άσε που δεν ήταν και πολλές οι εταιρείες που μπορούσαν να πληρώσουν τα απαραίτητα χρήματα για να μεταδώσουν το κωδικοποιημένο feed!

Η μετάδοση του real-time feed μέσω internet θα έλυνε το πρόβλημα του deployment των clients. Το πρόβλημα όμως είναι πως θα to μεταδώσεις το real-time feed! Δεν μπορείς να βάλεις κάθε client να καλεί τον feed server κάθε δευτερόλεπτο. Και θα φόρτωνες το server και real-time feed δεν θα είχες.
Ούτε μπορείς να στήσεις ένα web server σε κάθε client για να τον καλέσει ο feed server. Αυτό θα έκανε πάλι το deployment των clients δύσκολο.

Το σενάριο του kosdian είναι ένα από αυτά που πραγματικά δεν ταιριάζει με τα web services. Ευτυχώς, αντίστοιχες απαιτήσεις έχουν και ... τα massively multiplayer online παιχνίδια! Και σε αυτή την περίπτωση μια σειρά "κινήσεων" πρέπει να μεταδωθεί με ελάχιστη καθυστέρηση σε μεγάλο αριθμό clients.

---

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

pkanavos wrote:

Το σενάριο του kosdian είναι ένα από αυτά που πραγματικά δεν ταιριάζει με τα web services. Ευτυχώς, αντίστοιχες απαιτήσεις έχουν και ... τα massively multiplayer online παιχνίδια! Και σε αυτή την περίπτωση μια σειρά "κινήσεων" πρέπει να μεταδωθεί με ελάχιστη καθυστέρηση σε μεγάλο αριθμό clients.

Δεν θα συνεισφέρω στην κουβέντα με το σχόλιο μού αλλά...

Ναί, δεν έχει καθόλου πλάκα να τρέχεις και όλοι οι παίκτες γύρω σου και το περιβάλλον να έχουν παγώσει! Τώρα μου θύμισες πόσο καιρό έχω να παίξω...

---

Vir prudens non contra ventum mingit

Εάν είναι εφικτή μια καθυστέρηση της τάξης των 600-800ms, είναι πρόβλημα; Χοντρικά εγώ τόσο υπολογίζω τον ελάχιστο χρόνο σε ένα φυσιολογικό περιβάλλον για clients μέσω internet. Από μετρήσεις που έχω κάνει κάθε request θέλει 200 ms να πάει και άλλα τόσα να έρθει (δοκιμές μεταξύ Αθήνας - Θεσσαλονίκης), και υπολογίζω και 200-400ms ανάλογα με τα δεδομένα και το processing (τα δεδομένα πάντα συμπιεσμένα εννοείται).

Από την άλλη, το να δεχτεί ο server 1000 requests ανά δευτερόλεπτο, δεν είναι τόσο extreme νούμερο. Τα δεδομένα είναι τα ίδια, όσους clients και να έχουμε και υπάρχουν μεγάλα περιθώρια για caching.

(Δεν κολάω στο ντε και καλά web services, απλά το ψάχνω γιατί είναι ενδιαφέρον)

---

Χρήστος Γεωργακόπουλος

Στην συγκεκριμένη περίπτωση  όταν μια εταιρία έχει πχ 10 clients, αυτά δεν έχουν άμεση σύνδεση με τον feed server. Τα clients συνδέονται με ένα local server ο οποίος έχει την άμεση σύνδεση και κρατά τα κλείσίματα, ιστορικά κλπ σε μια τοπική βάση δεδομένων.
 Έτσι το feed χρησιμοποιείται μόνο για τις κινήσεις των μετοχών κατά την ώρα της συνεδρίασης, καθώς και για κάποια άλλες επιμέρους εργασίες (split μετοχών, διάφορα ενημερωτικά άρθρα κλπ). Επίσης όταν ένα client ζητά μια πληροφορία απο τον local server όταν αυτός δεν την έχει στην τοπική του βάση τότε την ζητά απο τον feed server. Αυτό που θεωρώ ανασταλτικό παράγοντα για την χρησιμοποίηση web services εκτός των άλλων (ταχύτητα, overhead soap messages κλπ) είναι η ανάγκη του feed server να κάνει push κάποια data και αυτή η ανάγκη δεν καλύπτεται με πολύ συχνά requests απο τον client γιατί έχει μεγάλη σημασία η αμεσότητα (Βέβαια αυτό προϋποθέτει συνεχή σύνδεση client με server).

gcapnias wrote:

Εδώ υπάρχει μια παραπλάνηση. Ο καιρός των εταιρικών δικτύων που ότι ήθελε έμπαινε από την πόρτα 80 έχει περάσει. Θα πρέπει να λαφθεί υπόψη ότι πλέον τα firewall είναι "έξυπνα" και επειδή είναι η πόρτα 80 δεν σημαίνει ότι μπαίνει ότι θέλει από εκεί. Τα "έξυπνα" firewall κάνουν ανάλυση των πακέτων του application πρωτοκόλλου, δηλαδή HTTP/SMTP/POP3, οπότε το "μπορείς να περάσεις ότι θες" από την πόρτα 80, είναι λίγο έως πολύ, ουτοπικό. Θα πρέπει να σκεφτείς σοβαρά την χρήση των WebServices, και τον extensions τους που υποστηρίζουν και κρυπτογράφηση, και συμπίεση, έστω και αν σημαίνει ότι πρέπει να έχεις ένα πολύ δυνατό μηχάνημα από πίσω, ή και web farm. Αυτό που μάλλον θα παίξει καθοριστικό ρόλο, από ότι φαίνεται, είναι και η ποιότητα δικτύου που προσφέρει το ίδιο το internet. Ο μεγάλος όγκος δεδομένων και γρήγορα, απαιτούν ποιότητα στο δίκτυο. Οπως λέει και ο Παναγιώτης θα πρέπει να λάβετε σοβαρά υπόψη, να χρησιμοποιήσετε γρήγορα κανάλια που προσφέρουν ποιότητα γραμμής μέσα από το internet, αλλά που έχουν σοβαρό κόστος.

Συμφωνώ με την παραπάνω παρατήρηση για αυτό προβληματίζομαι με το θέμα της πόρτας. Στην  80 οι περισσότεροι πλέον έχουν κλειστά τα tcp/ip connections και επιτρέπουν μόνο τα http. Άρα άμα απενεργοποιήσουν το web filtering στην 80 δεν θα έχουν πλέον τον έλεγχο του τι μπαίνει και τι βγαίνει, ενώ σε μια άλλη πόρτα η οποία θα έχει ανοιχθεί ειδικά για αυτόν τον λόγο, τα πράγματα θα είναι ποιο απλά.
Ευχαριστώ πολυ για την συμμετοχή σας στην συζήτηση η οποία ξεκίνησε απο μια απλή απορία και εξελίχθηκε σε ένα πολύ ενδιαφέρων γενικότερο θέμα. Το web service or not ? Ιδού η απορία.

kosdian

Προφανώς στην περίπτωση αυτή, ίσως να ήταν προτιμότερο το Remoting με κάποιο event handler στον Client.
Ρίξε μια ματιά σε αυτό το άρθρο http://www.codeproject.com/csharp/RemotingAndEvents.asp,
όπως επίσης και σε αυτό http://www.developer.com/net/net/article.php/2201701

 

 

---

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

Παραξενεύομαι πολύ που η λέξη sockets δεν έχει αναφερθεί ακόμη απο κανέναν;

'Εχοντας ένα socket ανα client, ναί μεν έχεις 1 SOCKET ΑΝΑ CLIENT στο server σου πάντα ανοιχτό, ναί μεν αυτό ίσως έχει περισσότερες δυσκολίες στην υλοποίηση, αλλά είσαι real time και σε push καί σε pull mode. Μέσα απο το ίδιο socket ...

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

Αυτά τα φιλοσοφικά μου σχόλια για τώρα :) ... flame me ...

---

Angel
O:]

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

---

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

anjelinio wrote:

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

Μπααααα.... μη το λές, άβυσος η ψυχή του developer...

---

Χρήστος Γεωργακόπουλος