Όταν βάζουμε ένα web reference σε ένα project μας, το VS δημιουργεί μια proxy class. Για κάθε method του web service δημιουργεί μια αντίστοιχη μέθοδο στην proxy class και άλλη μια μέθοδο που τελειώνει σε async.

Όταν καλέσουμε μια async class, υπάρχει κάποιο timeout ή κάτι άλλο που μπορεί να δημιουργήσει πρόβλημα σε περίπτωση που ο server αργήσει να απαντήσει; Π.χ. αν ο server απαντήσει μετά από 10 λεπτά!; Εννοείτε βέβαια ότι ο server θα αργήσει για συγκεκριμένο λόγο και όχι λόγω φόρτου και ο client θα το ξέρει αυτό και θα μπορεί να περιμένει τόσο. Απλά το ερώτημά μου είναι αν κάτι στο .net framework ή στην proxy class θα δημιουργήσει πρόβλημα αν χρειαστεί να περιμένει τόσο πολύ.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Σίγουρα θα πρέπει να προσέξεις το timeout του Web Service, που ορίζεται στο Web.Config. Από εκεί και πέρα δεν νομίζω ο client να έχει πρόβλημα...

---

Στερνή μου γνώση να σε είχα πρώτα...

Έχεις δύο timeouts που πρέπει να προσέξεις. Το ένα είναι το timeout του response που κάνει γενικότερα ο server και ορίζεται μέσα από το web.config (πόσο χρόνο επιτρέπει ο server να καταναλώσει η server εφαρμογή μέχρι να απαντήσει) και το άλλο είναι το timeout που έχει ο client στον proxy του service και το οποίο ορίζεται από την αντίστοιχη παράμετρο του service instance (πόσο χρόνο θέλεις να περιμένει ο client μέχρι να του απαντήσει ο server).

Επιπροσθέτως, αν εμπλέκεται και βάση δεδομένων στη μέση η οποία προκαλεί την καθυστέρηση, θα πρέπει να δεις και το time out του connection που κάνεις στη βάση (ορίζεται είτε από το connection string, είτε άπό το open connection command που κάνεις στη βάση)

Συνοψίζοντας δηλαδή, έχεις να προσέχεις ουσιαστικά τρία timeouts. Το πιο μικρό είναι αυτό που σε περιορίζει, αλλά μην τα μεγαλώσεις και υπερβολικά. Ουσιαστικά όπου νιώθεις ότι πρέπει να βάλεις extreme τιμές για να αποφύγεις τα timeout errors, είναι περιπτώσεις που πρέπει να σκεφτείς λίγο διαφορετικές αρχιτεκτονικές με ουρές κλπ.

Για περισσότερες λεπτομέρειες google, γιατί είμαι σε διακοπές :-)

---

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

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

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Στην περίπτωση που άρχιζα να αναρωτιέμαι τέτοια "φιλοσοφικά" ερωτήματα, θα άλλαζα την αρχιτεκτονική της εφαρμογής μου.

Π.χ. ... αν η διαδικασία στο server κρατάει ένα ν διάστημα, και εμπλέκονται client timeout , web server timeout, db timeout κτλ κτλ, η καλύτερη λύση είναι το web service call να είναι σύγχρονο, και στο server πλέον αυτό να ξεκινάει μια ασύγχρονη διαδικασία ( πιθανώς σωσμένη στο application ή κάτι αντίστοιχο ). Το αποτέλεσμα του call θα ήταν ένα token για τον client το οποίο κάνει identify το process αυτό στην cache του server, και θα είχα τον client να κάνει poll μέχρι να τελειώσει η δεδομένη διαδικασία, στην οποία περίπτωση και θα λάβει πίσω το actual αποτέλεσμα της διαδικασίας.

Timeout safe, αλλά λίγο πιο ... involved στην υλοποίηση.

---

Angel
O:]

Ορίστε τι θέλω να κάνω: Θέλω ο server να μπορεί να στείλει στον client ένα μήνυμα. Επειδή δεν θέλω να ανοίξω κάποιο κανάλι επικοινωνίας μεταξύ τους, πλην του web service, θέλω ο client να κάνει μια ασύγχρονη κλήση, ο server να κρατάει αυτή την κλήση ενεργή και να απαντά σε αυτή, μετά από ώρα όταν θέλει να στείλει κάτι στον client. Το ερώτημά μου είναι αν υπάρχει κάποιο timeout μετά από το οποίο ο client θα πάψει να περιμένει απάντηση από τον server, για την ασύγχρονη κλήση που έκανε.

Δεν εμπλέκονται άλλα timeout, ούτε βάση δεδομένων. Γενικά το έχω δοκιμάσει και δουλεύει καλά. Όσο ο client περιμένει δεν υπάρχει activity ούτε στο δίκτυο, ούτε στον client, ούτε στον server. Σε περίπτωση που "πέσει" ο server κατάλληλος κώδικας στον client το εντοπίζει και ξανακαλεί χωρίς να γίνει αντιληπτό στον χρήστη. Απλά ήθελα μια γνώμη μήπως και έχει κάνει κάτι αντίστοιχο κάποιος και συνάντησε κάποιο πρόβλημα.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Χμμμ ... ίσως είναι καθαρά υποκειμενικό το θέμα, αλλά νομίζω οτι το client polling είναι η "ορθότερη" λύση αρχιτεκτονικά στο σενάριό σου αν είσαι πεπεισμένος οτι θές μόνο web service interface στο server φίλε papadi. To να κρύβεις timeout exceptions στο server και στον client είναι κατα την ταπεινή μου γνώμη waste or resources.

Αν είναι πολύ σημαντικό το μήνυμα του server να έρχεται στον client ASAP, δηλαδή ο χρόνισμός του notification στον client είναι τόσο σημαντικός ώστε να αποκλείει τη λύση του polling λόγω του ότι ίσως χάσεις κάποια δευτερόλεπτα / λεπτά, εγώ θα κοίταγα λύσεις queue, remoting ή ακόμη και sockets.

Φυσικά, μιλάω μην έχοντας ξεκάθαρη εικόνα για τον αριθμό των clients, το τί κάνει ο server ( ως processing logic ) τι requirements έχεις όσον αφορά το βαθμό synchronicity μεταξύ τους κτλ κτλ ... αλλά σε γενικότερα πλαίσια, η πρακτική του να αφήσω ένα process στο server να τρέχει, ακόμη και τόσο ώστε να σκάσει timeout στο process αυτό, είναι απλώς .. επικίνδυνη.

Μπορεί λαμβάνοντας υπ'όψην το περιβάλλον της συγκεκριμένης εφαρμογής να μη δείς ποτέ κάτι κακό να συμβαίνει, παρ'όλα αυτά ... "εγώ θα σε συμβούλευα κάτι άλλο ν'αγοράσεις" όπως λέει κι ένα σοφό ποίημα :D

Καλή μας μέρα

---

Angel
O:]

papadi wrote:

Ορίστε τι θέλω να κάνω: Θέλω ο server να μπορεί να στείλει στον client ένα μήνυμα. Επειδή δεν θέλω να ανοίξω κάποιο κανάλι επικοινωνίας μεταξύ τους, πλην του web service, θέλω ο client να κάνει μια ασύγχρονη κλήση, ο server να κρατάει αυτή την κλήση ενεργή και να απαντά σε αυτή, μετά από ώρα όταν θέλει να στείλει κάτι στον client. Το ερώτημά μου είναι αν υπάρχει κάποιο timeout μετά από το οποίο ο client θα πάψει να περιμένει απάντηση από τον server, για την ασύγχρονη κλήση που έκανε. Δεν εμπλέκονται άλλα timeout, ούτε βάση δεδομένων. Γενικά το έχω δοκιμάσει και δουλεύει καλά. Όσο ο client περιμένει δεν υπάρχει activity ούτε στο δίκτυο, ούτε στον client, ούτε στον server. Σε περίπτωση που "πέσει" ο server κατάλληλος κώδικας στον client το εντοπίζει και ξανακαλεί χωρίς να γίνει αντιληπτό στον χρήστη. Απλά ήθελα μια γνώμη μήπως και έχει κάνει κάτι αντίστοιχο κάποιος και συνάντησε κάποιο πρόβλημα.

Σκέψου το εξής: Έχεις αφήσει ανοικτό το call μήπως και ο server αποφασίσει να στείλει κάτι στον client. Και έρχεται η ώρα και η στιγμή που το στέλνει. Ο client πως θα το καταλάβει ότι τέλειωσε η αποστολή αφού το connection συνεχίζει να παραμένει ανοικτό; (γιατί υποθέτω ότι θέλεις να το κρατήσεις ανοικτό μήπως και ο server στείλει κάτι άλλο) Θα πρέπει να πέσεις αρκετά low level για να κάνεις κάτι τέτοιο. Σίγουρα όπως λέει ο anjelinio θα έχεις προβλήματα και με το performance του web server, ο οποίος πολύ απλά δεν είναι σχεδιασμένος για να δουλεύει έτσι.. Γενικά για κάθε προϊόν ισχύει το "Χρησιμοποίησέ το όπως σκεφτόντουσαν ότι θα χρησιμοποιηθεί αυτοί που το έφτιαξαν" αν δεν θέλεις να μπλέκεις υπερβολικά. Δες άλλα προϊόντα / τεχνολογίες / αρχιτεκτονικές που είναι φτιαγμένα για αυτό το σκοπό.

---

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

Χμμμ... Αν υπήρχε μια βάση και αν αυτή η βάση ήταν SQL Server 2005 θα ήταν πολύ καλό σενάριο για Depedencies/Notification Services

---

Vir prudens non contra ventum mingit

Αν δεν σας κάνει κόπο τρέξτε αυτό

http://www.papadi.gr/test1/clickonce/publish.htm

για να το δείτε στην πράξη...

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Εκτελέστε το περισσότερες από μια φορές ταυτόχρονα...

Ελπίζω μόνο να μην είστε πίσω από proxy γιατί λόγω clickonce θα έχει πρόβλημα με http://support.microsoft.com/kb/917952!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

+ Downloading http://www.papadi.gr/test1/clickonce/Extended.WebServices.SimpleWebChat_1_0_0_14/App.ico.deploy did not succeed.

+ The remote server returned an error: (404) Not Found.

---

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

Αν θέλεις ξαναδοκίμασε. Σε ευχαριστώ!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Με την λύση που έχω επιλέξει έχω τα εξής:

- Τα μηνύματα μεταφέρονται άμεσα

- Όσο ο server δεν έχει να στείλει κάτι στον client, υπάρχει μια κλήση web service από τον client στον server ανά 1 λεπτό (αυτό είναι και το timeout που ψάχνω. Θα δοκιμάσω να το αυξήσω περισσότερο).

- Στο μεταξύ τόσο ο client, όσο και ο server, καθώς και το δίκτυο μεταξύ τους δεν έχουν καθόλου activity.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

:D ... μα τί έχουν πάθει όλοι πια με τα chats με web services, δε μπορώ να καταλάβω. Γαιτί ρε παιδιά δεν αποδέχεστε απλώς οτι το HTTP είναι client request - server response μοντέλλο, το οποίο δε μπορεί να εξυπηρετήσει τα πάντα as is;

Φίλε papadi, νομίζω οτι με remoting over http channels θα είσαι μια χαρά με τα firewalls, και θα κάνει και το implementation σου πολύ πιο καθαρό. Ίσως και πιο performant για το server σου.

Όλα αυτά βέβαια, αν δε θες να μπλέξεις λίγο με sockets στην πόρτα 80, η οποία είναι βέβαια η πιο low-level, αλλα και πιο performant λύση. Ο πιο παιδικός, inefficient, μπάχαλος chat server που έχει γραφτεί με sockets θα σου εξυπηρετεί 50 με 100 χρήστες οι οποίοι τον "λιώνουν" στα requests, αγώγκιστα. Το ξέρω, γιατί εγώ τον έγραψα, στο πανεπιστήμιο, και κοιτάω τώρα τον κώδικά του και γελάω ( σε Java παιδιά, δεν είχαμε .NET τότε .. ) :D

Σαν afterthought βέβαια, σκέφτομαι οτι αν όλοι χρησιμοποιούσαν τα πάντα με τον τρόπο που περίμεναν αυτοί που τα γράψανε ... δε θα βλέπαμε ποτέ καμμία πρόοδο, σε κανένα προϊόν ... food for thought i guess.

Άντε, πάω διακοπές τώρα !

---

Angel
O:]