Arıza durumunda çift yönlü bir kanalı nasıl otomatik olarak yeniden kurarım?

Question

WCF kullanarak .Net 3.5'te bir istemci/sunucu uygulaması geliştiriyorum. Temel olarak, uzun süredir çalışan bir istemci hizmeti (birkaç makinede), netTcpBinding üzerinden sunucuya çift yönlü bir bağlantı kurar. Daha sonra sunucu, istemcinin asenkronize bir şekilde yanıt verdiğini düşündüğüm belirli isteğe bağlı işlemleri gerçekleştirmek için istemcinin geri çağrı sözleşmesini kullanır (sanırım oldukça standart şeyler). İletişimin çoğunu işlemek için DuplexClientBase sınıfını alt sınıf olarak yapıyorum.

şey iki ucunda yanlış gittiğinde Maalesef (bir ağ hatası, beklenmedik istisna, vs gibi), kanal/durduruldu hatalı alır ve sonraki tüm işlemler başarısız. İstemci hata yaptığı ve işlemi yeniden denediğinde otomatik olarak açılan bir RecoveringClientBase sınıfı oluşturarak dupleks olmayan kanallarda bu sınırlamayı aştım.

Benim sorum şu ki, bir dubleks kanalın ne zaman arızalandığını belirlemenin yerleşik bir yolu var mı? Bunu sunucuda ya da istemcide nerede kontrol etmeliyim? Başarısız olursak, bağlantının yeniden kurulmasını sağlamak için hangi seçeneklere ihtiyacım var?

Güncelleme: Sunucunun hatalı bir geri arama kanalı kullanmaya çalışabileceği dubleks kanallara özel öneriler arıyorum. Bu nedenle, kanala bir şey olduğunda hemen yeniden bağlanacak/yeniden gönderilecek bir şeye ihtiyacım var. Şu anda kanalın Kapanış etkinliğini dinliyorum ve devlet bir şey Kapalı ise yeniden oluşturuyorum. WCF ekibinden, ...

Answer 1

Nicolas Allen Bir çeşit çalışır, ancak hacky hissediyor bu önerileri vardır:

http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx

O'nun öneri kanal düzeyinde bu idare etmektir. Kanal seviyesi biraz daha hoştur, çünkü özel bir istemci taban sınıfı gerektirmek yerine, davranışlar aracılığıyla herhangi bir bağlayıcı yığına bağlayabilirsiniz.

Answer 2

Bazı benzer sorunlar yaşadım ve bana göre bu uzun süren aramalar az çok desteklenmiyor. WCF, kısa süreli aramalar için kullanılacak şekilde tasarlanmış gibi görünüyor. Arayan, bazı küçük şeyler yapmak ve bitmiş.

Uygulamalarımı daha küçük iş öğelerine dönüştürdüm. Yani bir büyük uzun koşu öğesi yerine şimdi çok daha küçük parçalar aldım. Tabi ki, bazen bu elde etmek mümkün değildir. O zaman istikrarlı ağ bağlantıları için dua etmeliyim (istisnalar yakalanabilir, bu yüzden hatalar sanırım gerçekten sorun değil).

Answer 3

Uzun koşu seanslarında (dakika-saat) flaklık yaşadım. WCF'den emin olamıyorum, ağ seviyesinden eminim.

Dubleks ile tamamen uzaklaşmayı düşünüyorum. Bağlantının durumunu yönetmeye çalışan gerçek bir sıkıntıdır.

Şu anda geri arama sözleşmesinin bir parçası olan işlemler için istemci üzerinde bir hizmet bitiş noktası barındırmayı düşünüyorum. İstemci sunucuyla uç nokta detayları ile iletişim kurar, sunucu bunları bir yerde saklayabilir (ısrarlı veya herhangi bir yerde). Sunucunun istemciyle iletişim kurması gerektiğinde, istemciye tıkanmış son nokta ayrıntıları aracılığıyla bir bağlantı açar. Temel olarak, çift yönlü bağlantıyı 2 istemci-sunucu bağlantısına dönüştürmek.

Sorunuzu cevaplamıyor, ama acınızı hissediyorum.

Answer 4

Hatalı olayı gerçekten dinlemelisiniz. Her iki ucunda da dinleyebilirsiniz, istemcinin sonuna baktığını düşünüyorum, sunucunun sonu OperationContext.Current.Channel.events.

Geri arama kanalınız zaten hatalı olduğundan ve henüz yeni geri arama kanalı bilmediğinizden, ancak istemcinin yeniden bağlanmasına kadar sunucuda bir yerlerde arama yapmaları gerektiğinden otomatik olarak bir iletiyi yeniden göndermenin bir yolunu bulamadım.

İstemciler en sonunda arızalanır ve sunucuyla el sıkışmalarını yeniden yapmalıdır; bu, nokta sunucusunun gönderilmemiş çağrıları göndermesidir.

Temelde, arızalı/kapalı bir kanaldan kurtarmanın tek yolu yenisiyle değiştirmektir, bununla birlikte, en önemli kısım gerçekten bağlantıyı kesmelisiniz, ON TIME, güvenilir oturumun etkinleştirildiğini buldum. vakanın çoğu zamanı. Alternatif olarak, "test" kanalının arızalanması için her iki uçta da kalp atışı mesajları gönderebilirsiniz.