2011-08-16 13 views
5

Şu anda gerçek zamanlı bir sürece komutlar göndermesi ve alması gereken bir C# soket sunucusu geliştiriyorum. Müşteri bir android cihazdır. Şu anda gerçek zamanlı gereksinimler "yumuşak", ancak gelecekte daha katı zamanlama gereksinimleri ortaya çıkabilir. Gelecekte, potansiyel olarak tehlikeli olabilecek bir vincin komutlarını göndermek olduğunu söyleyebiliriz.Eşzamansız ve gerçek zamanlı uygulama için eşzamanlı soket sunucusu

Sunucu şu anki senkron soket sunucu tasarımımda çalışıyor ve çok iyi görünüyor. Veri almak ve göndermek için ayrı iş parçacıklarım var. Eşzamansız sunucu soket yaklaşımını denemek için herhangi bir neden olup olmayacağını merak ediyorum? Daha fazla stabilite ve/veya daha hızlı performans sağlayabilir mi?

+1

async design yalnızca yararınıza olacaktır. Birden fazla istemci ve/veya birden fazla ileti/bağlantıya sahip olduğunuz için, bu tür durumlarda uyumsuz tasarımınız sunucunuzu çok daha iyi ölçeklenebilir hale getirir – Yahia

cevap

6

Gerçek zaman tanımının üzerinde duracağım ve uyumsuz soketlerin istek sürecinin gövdesini daha hızlı yapamayacağını, ancak eşzamanlılığı artıracağını (herhangi bir zamanda alabileceğiniz isteklerin sayısını) söyleyeceğim. Tüm işlemciler birşeyi işliyorsa, hiç kazanç elde edemezsiniz. Bu, yalnızca bir işlemcinin bir soket almak için bir soket beklediği oturduğu zaman kazanmanızı sağlar.

Gerçek zamanlı gereksinimleriniz, gerçek zamanlı gereksinimleriniz x zamanındaki bir yanıtı garantilemek gibi bir şeyse, C# ve .NET size böyle bir garanti vermez. Ancak bu, mevcut ve gelecekteki "yumuşak" tanımlarınıza bağlıdır. İyi yanıt süreleri almak için 'un olmasını sağlayın, ancak gerçek gerçek zamanlı sistemlerle karıştırmayın.

+1

Cevabınız için teşekkürler! Async soket sunucuları ile ilgili tüm mesajların daha hızlı olduğunu sanıyorum ama şimdi hangi durumlarda olduklarını biliyorum. Ve notunuza tamamen katılıyorum, C# gerçek zamanlı gereksinimler için iyi bir seçim değil. Muhtemelen reqs söz konusuysa, C yerine bir sunucu yapacağım. Başka bir şey, gerçek zamanlı iletişim için geçerli bir seçenek olan TCP soketleri mi yoksa başka bir şey mi düşünmeliyim? – Cartaya

+1

Senkronize olmayan C# ile senkronize C yapıyorsanız, kendinize büyük bir misfavor imo yapıyorsunuz demektir. – Henrik

+0

Gizli ortamdaki (ör. Ağ) her türlü iletişim, gerçek zamanlı sistemler için parlak olmayacaktır. Güvenilirlik istiyorsanız, TCP yeterince iyi bir seçimdir. –

1

Uygulamalarınızda asenkronize olan bir şeyin yararlılığından kuşku duyuyorsanız, o zaman kesinlikle this'u okumalısınız. Eşzamansız çözümlerin uygulamalarınıza ne ekleyebileceği konusunda net bir fikir verir

+0

LMAX referansını gönderdiğiniz için teşekkür ederiz. Çok ilginç. – kakridge

+0

http://disruptor.googlecode.com/files/Disruptor-1.0.pdf - okuyacağınız kağıt bu, Fowler'in kesik kopyala-yapıştırması sadeleştirme değil;) – Henrik

0

Daha fazla kararlılık veya daha hızlı performans elde edeceğinizi sanmıyorum. Eğer gerçekten "gerçek zamanlı" bir sistemse, o zaman senkronize olmalıdır. "Gerçek zamana yakın" tahammül edebilecek ve uzun süreli veya pahalı hesaplama işlemleri yapabiliyorsanız, asenkron bir yaklaşım düşünebilirsiniz. Gerçi gerekli değilse karmaşıklığı eklemem.

0

Gerçek zaman ise, o sırada iletişiminizin bir sıra tarafından desteklenmesini ve böylece bu sıradaki mantıksal mantığı kanıtlamanızı kesinlikle istiyorsunuz. Bu nio/io-tamamlama-portları/async size verir. Senkronize programlama kullanıyorsanız, veriyi RAM'den ağ kartına kopyalarken CPU'nuzu boşa harcarsınız.

Ayrıca, sunucunuzun kesinlikle tek iş parçacıklı olduğu anlamına gelir. Async ile bile tek bir iş parçacığınız olabilir, ancak yine de binlerce istekte bulunabilirsiniz. Örneğin bir istemcinin bir DOS saldırısı yapmak istediğini varsayalım. Bir bayt veri toplayıp gönderirdi. Uygulamanız artık, bu bağlantının zaman aşımı için daha büyük komutlar alabilecek başka komutlar alamadı. Eşzamansız olarak SYN paketini geri alırsınız, ancak kodunuz tüm iletimi beklemez.

+0

UDP kullanıyor. ACK saldırıları geçerli değil. Tavsiyeniz, başvurusunun gerçek zamanlı doğasını güçlendirmez; CPU performansını ve ağ güvenliğini artırır. Zaman uyumsuz bir ileti sırasındaki zamansal mantık açısından yazabilme, yalnızca, hizmet oranınız geride kalırsa, kuyruğun içeriğini 'yakalamak' için işlemek için enleminiz varsa pratik olur; ve senkronize bir çözümün önlenebileceği servis hızında pseudorandom dalgalanmasına neden olur (ancak bu, 'vinç' bağlantısının tamamen adanmış/öngörülebilir şekilde gizlendiyse, bu gerçekten geçerli olacaktır). –

+0

UDP'yi nerede kullandığını söylüyor? Bundan bahsetmiyorum. Sizinle aynı fikirde olmadığımdan emin değilim, ancak birden fazla bağlantı verildiğinde senkronizasyon soketleri yerine uyumsuzluk kullanmak, gecikmeyi azaltacak ve bu da internet üzerinden katil olacak - ve internet, tahminen gizli paketleri sürecinize göndermiyor - - yani ne hakkında konuştuğunuzu anlamıyorum. Ayrıca, dalgalanma varsa ne fark eder - ve bu ne anlama geliyor? - burada tahmin - paketler düzenin dışına çıkabilir ve keyfi olarak gecikebilir. – Henrik

+0

UDP'den bahsetmediğinden haklısınız. Bunu neden kabul ettiğimi bilmiyorum, belki de bir endüstriyel uygulama (vinç) referansı onu kafama koydu. –