Web programlamasında neden oylama kabul edilir?

Şu anda görüntülerin listesini gösteren bir Ruby on Rails projesi üzerinde çalışıyorum .

Bu proje için sahip olması gereken, web sayfasını yenilemeye gerek kalmadan gerçek zamanlı olarak yeni gönderileri göstermesidir. Bir süre aradıktan sonra, PubNub gibi bazı JavaScript çözümlerine ve servislerine rastladım; Ancak, sağlanan çözümlerin hiçbiri hiçbir anlam ifade etmedi.

JavaScript çözümünde ( yoklama ) aşağıdakiler gerçekleşir:

• Kullanıcı 1, fotoğrafların listesini görüntüler.
• Arka planda JavaScript kodu her saniye yeni bir gönderi olup olmadığını görmek için bir son noktaya oy veriyor.
• Kullanıcı 2, yeni bir fotoğraf ekler.
• Yeni çevrim tetiklenmeden ve yeni verileri getirmeden önce 50 ms'lik bir gecikme olur.
• Yeni içerik DOM'a yüklenir .

Gerçek bir dünya örneğine tercüme edildiğinde bu garip görünüyor:

• Kullanıcı 1, masasında bir yığın fotoğraf tutar.
• Her saniye fotoğrafçıya yürür ve yenisi olup olmadığını sorar.
• Fotoğrafçı yeni bir fotoğraf çeker.
• Bu saniye içeri girdiğinde fotoğrafı çekip yığına koyabilir.

Bence çözüm şu şekilde olmalı:

• Kullanıcı 1, masasında bir yığın fotoğraf tutar.
• Fotoğrafçı yeni bir fotoğraf çeker.
• Fotoğrafçı yığına yürür ve geri kalanıyla birlikte koyar.

PubNub çözümü temelde aynıdır, ancak bu kez verileri paylaşmak için taraflar arasında yürüyen bir stajyer vardır.

Söylemeye gerek yok, her iki çözüm de yüklenecek veri olmadığında bile tetiklendiklerinden çok enerji tüketirler.

Bilgim devam ettiği sürece, bu tür bir uygulama yönteminin neredeyse her gerçek zamanlı uygulamada kullanılmasının neden hiçbir mantığı yoktur.

İtme 1 veya sınırlı sayıda kullanıcı için iyi sonuç verir.

Şimdi senaryoyu bir fotoğrafçı ve hepsinin resmin kopyasını isteyen 1000 kullanıcıyla değiştirin. Fotoğrafçının 1000 kazağa yürümek zorunda kalacak. Bazıları kilitli ofisinde olabilir ya da her yere yayılmış olabilir. Veya kullanıcıları tatilde ve şu anda yeni resimlerle ilgilenmiyor.

Fotoğrafçı sürekli yürümekle meşgul olacak ve yeni fotoğraflar çekmeyecekti.

Temel olarak: bir çekme / anket modeli, gerçek zamanlı gereklilikleri gevşek olan birçok güvenilmez okuyucu için daha iyi ölçeklendirilebilir (eğer bir resmin bir yığına ulaşması 10 saniye sürerse, bu sorun ne?).

Bununla birlikte, bir itme modeli birçok durumda hala daha iyidir. Gecikme süresine ihtiyacınız varsa (çekildikten sonra yeni fotoğrafa 5s gerekir) veya güncellemeler nadirdir ve sık ve öngörülebilir olmasını ister (bir fotoğrafçı günde yeni bir resim oluştururken her 10 saniyede bir sormaya devam edin), o zaman çekmek uygun değildir. Ne yapmaya çalıştığınıza bağlı. NASDAQ: itin. Hava durumu hizmeti: çekin. Düğün fotoğrafçısı: muhtemelen çekin. Haber fotoğraf ajansı: muhtemelen itin.

Sadece bir kişinin WebSockets'ten bahsetmesine şaşırdım . Destek, temelde her büyük tarayıcıda gerçekleştirilir .

Aslında PubNub onları kullanır. Uygulamanız için tarayıcı muhtemelen yeni bir fotoğraf mevcut olduğunda yayın yapacak bir sokete abone olacaktır. Soket fotoğrafı göndermezdi, dikkat et, ama tarayıcının senkronize olmayan bir şekilde indirebilmesi için bir link.

Örnekte şöyle bir şey hayal edin:

1. Kullanıcı (lar) fotoğrafçının gelecekteki tüm fotoğraflar hakkında bilmek istediğini bilmesini sağlar
2. Fotoğrafçı, hoparlörden yeni bir fotoğrafın mevcut olduğunu söylüyor
3. Kullanıcı fotoğraf için fotoğrafçı ister

Bu, orijinal örnek çözümünüze benziyor. Oy vermekten daha etkilidir, çünkü müşterinin sunucuya herhangi bir veri göndermesi gerekmez ( kalp atışları hariç ).

Ayrıca, diğerlerinin de belirttiği gibi, eski tarayıcılarda çalışan basit oylamadan daha iyi başka yöntemler de vardır ( longpolling, et al .)

Bazen yeterince iyi, yeterince iyidir.

Bir "gerçek zamanlı" iletişim sürecini uygulamak için mümkün olan bütün yollar arasında, yoklama belki de en basit yoldur. Yoklama aralığı nispeten uzun olduğunda (yani anlık değil saniyeler, dakikalar veya saatler) olduğunda ve bağlantı veya kaynağın kontrol edilmesiyle tüketilen saat döngüleri gerçekten önemli değilken, yoklama etkin bir şekilde kullanılabilir.

HTTP protokolü, istemcinin isteği başlatan OLMASI nedeniyle sınırlıdır. Bir müşterinin isteğine cevap vermedikçe sunucu müşteri ile iletişim kuramaz.

Dolayısıyla gerçek dünyadaki örneğinizi ayarlamak için aşağıdaki kısıtlamayı ekleyin:

• Kullanıcı 2, SADECE Kullanıcı 1'in sorularına tek bir cümle cevabı ile cevap verebilir, daha sonra Kullanıcı 1'in bırakması gerekir. Kullanıcı 2'nin başka bir iletişim yolu yoktur.

Bu yeni kısıtlamayla, yoklama dışında nasıl yaparsın?

Yoklama neden kabul edilir? Çünkü gerçekte her çözüm aslında düşük seviye sorgulamadır!

Sunucunun yeni resimler kullanılabilir olur olmaz sizi güncellemesi gerekiyorsa, genellikle sizinle bir bağlantısı olması gerekir - çünkü IP adresleri sık sık değişir ve birileri artık ilgilenmiyorsa asla bilemezsiniz, bu nedenle müşterinin bir form göndermesi gerekir. canlı tutma sinyali, örneğin, "Hala buradayım, çevrimdışı değilim"

Tüm durum bilgisi olan bağlantılar (örneğin, TCP / IP) aynı şekilde çalışır, çünkü yalnızca İnternet üzerinden tekil veri paketleri gönderebilirsiniz; karşı tarafın hala orada olup olmadığını asla bilemezsiniz.

Yani her protokolün bir zaman aşımı vardır. Bir işletme X saniye içinde cevap vermezse, öldüğü varsayılır. Dolayısıyla, sunucu ile istemci arasında yalnızca açık bir bağlantınız olsa bile, herhangi bir veri göndermeden, sunucunun ve istemcinin düzenli canlı tutma paketleri göndermesi gerekir (aralarında bir bağlantı açarsanız bu düşük seviyede ele alınır) - ve Sonunda bu seçimden farklı mı?

Bu yüzden en iyi yaklaşım muhtemelen uzun sürecek:

Müşteri siteyi yükledikten hemen sonra bir istek gönderir (örneğin, fotoğrafçıya "Yeni resim olup olmadığını söyle"), ancak yeni resim yoksa sunucu yanıt vermez. Talep zaman aşımına uğradığı anda müşteri tekrar sorar.

Sunucunun şimdi yeni resimleri varsa, yeni resimler için sıraya giren tüm istemcilere hemen cevap verebilir. Dolayısıyla, yeni bir resimden sonraki tepki süreniz itme işlemine göre daha kısa sürüyor, çünkü müşteri hala bir cevap için açık bir bağlantıda bekliyor ve müşteriyle bir bağlantı kurmak zorunda değilsiniz. Ve istemciden sorgulama istekleri, bir cevap için istemci ile sunucu arasındaki sürekli bir bağlantıdan daha fazla trafik değildir!

Oy verme işleminin bir avantajı, bir mesajın kaybolması veya bir şeyin durumuna yol açması durumunda oluşabilecek zararı sınırlandırmasıdır. Eğer X her beş saniyede bir Y durumu isterse, bir isteğin veya bir cevabın kaybedilmesi yalnızca X'in bilgisinin 5 yerine on saniyenin 10 saniye olmasına neden olur. Y süresi, X'in mesajlarından birine cevap verebilir. Eğer X yeniden başlatılırsa, daha sonra herhangi bir şey için Y'yi istemekten asla rahatsız olmaz, ancak X'in durumunu gözlemleyen kişi yeniden başlatıldığını kabul etmelidir.

X'in Y yoklaması yerine, X, durumu ne zaman değiştiğini bildirmek için Y'ye güvenirse, o zaman Y'nin durumu değiştiyse ve X'e bir mesaj gönderirse, ancak bu mesajın alınmamasının sebebi ne olursa olsun, X asla değişimin farkına varmayabilir . Aynı şekilde, Y yeniden başlatılırsa ve X'e herhangi bir şey hakkında bir mesaj göndermek için hiçbir neden olmazsa.

Bazı durumlarda, X'in Y'nin durumuyla, periyodik olarak veya değiştiğinde kendi durumuyla özerk olarak mesaj göndermesini istemesi ve Y'den hiçbir şey duymadan çok uzun sürerse X anketinin yapılmasını istemek yararlı olabilir. X'in iletilerinin çoğunu göndermesi gerekebilir (tipik olarak, X en azından bazen Y'ye hala ileti almakla ilgilendiğini bildirmeli ve herhangi bir ilgi belirtisi olmadan çok uzun sürerse ileti göndermeyi durdurmalıdır). Bununla birlikte, böyle bir tasarım Y'nin ısrarla olmasını gerektirirX ile ilgili bilgileri saklamak yerine, basitçe kime cevap verenlere bir cevap gönderebilmek yerine, kim olduğunu hemen unut. Eğer Y gömülü bir sistem ise, böyle bir basitleştirme daha küçük ve daha ucuz bir kontrol cihazının kullanımına izin vermek için bellek gereksinimlerini yeterince azaltmaya yardımcı olabilir.

Yoklama, potansiyel olarak güvenilmez bir iletişim ortamı (örneğin, UDP veya radyo) kullanıldığında ek bir avantaja sahip olabilir: bağlantı katmanı onaylama ihtiyacını büyük ölçüde ortadan kaldırabilir. X, Y'ye bir durum isteği gönderirse, Y, R durum raporuna yanıt verir ve X, R duyarsa, X'in alındığını bilmesi için, Q için herhangi bir tür bağlantı katmanı onayını duyması gerekmez. Bunun tersine, Y R gönderdiğinde, X'in alıp almadığını bilmesi ya da önemsemesi gerekmez. X bir durum isteği gönderir ve yanıt alamazsa, başka bir tane gönderebilir. Y bir rapor gönderirse ve X duymazsa, X başka bir istek gönderir. Her istek bir kez dışarı çıkarsa veya bir yanıt verirse veya vermezse, taraflardan herhangi birinin belirli bir mesajın alıp alınmadığını bilmesi veya umursaması gerekir. Bir onay gönderme, bir durum isteği veya rapor kadar neredeyse bant genişliği tüketebileceğinden, bir istek raporu turu kullanmak, istenmeyen bir rapordan ve onaydan daha pahalıya mal olmaz. X yanıt vermeden birkaç istek gönderirse, bazı dinamik olarak yönlendirilmiş ağlarda, bağlantı düzeyinde onaylamaların etkinleştirilmesi gerekebilir (ve isteğinde Y'nin de aynı şekilde yapılmasını isteyin) böylece altta yatan protokol yığını teslimat sorununu tanıyabilir ve arama yapabilir. yeni bir rota, ancak işler çalıştığında, bir istek raporu modeli bağlantı düzeyinde onaylar kullanmaktan daha etkili olacaktır.

Asıl soru, gereksiz baskı miktarını ve gereksiz baskı miktarını dengelemek.

Eğer anket yaparsanız:

• Şu anda bir cevap alıyorsunuz. Sadece ara sıra sormak ya da bu anı ayarlamak için bir veriye ihtiyacınız varsa iyi.
• "İçeriksiz" cevabını bulabilir ve hatta çizgide anlamsız yüklere neden olabilirsiniz.
• Yükü, yalnızca yoklama yaptığınızda, ancak her zaman yoklama yaptığınız zaman hatta yüklersiniz.

İtersen:

• Cevabı, uygun olduğunda, müşteri tarafında anında işlem yapılmasını sağlayan bir şekilde teslim edersiniz.
• Bu verilerle ilgilenmeyen istemcilere veri iletebilir, hatta hatta anlamsız yüke neden olabilirsiniz.
• Her yeni veri olduğunda, hatta yalnızca yeni veriler olduğunda yükü yüklüyorsunuz.

Çeşitli senaryolar ve bunların dezavantajları ile nasıl başa çıkılacağına dair çeşitli çözümler vardır; örneğin, anketler, ana sistemden yük almak için yalnızca anketler arasındaki asgari süre, veya - ittirmeler için - kayıt ve belirtme için bir düzenleme İstenen verileri takiben oturum kapatma kaydının silinmesini takiben Hangisinin en iyi uyduğu, genel olarak söyleyebileceğiniz hiçbir şey değildir, sisteme bağlıdır.

Örneğinizde yoklama en etkili çözüm değil, en pratik çözümdür. JavaScript'te bir sorgulama sistemi yazmak çok kolay ve bunu teslim tarafında da uygulamak çok kolay. Görüntü verilerini iletmek için yapılan bir sunucu, ekstra istekleri yerine getirebilmelidir ve verilmezse, veriler çoğunlukla statik olduğundan ve bu nedenle kolayca önbelleğe alınabildiği için doğrusal olarak ölçeklendirilebilir.

Bir oturum açma, istenen verilerin tanımı ve son olarak oturum kapatma işlemlerini uygulayan bir itme yöntemi en verimli olur, ancak ortalama "script-kiddy" için çok karmaşıktır ve şu soru ile ilgilenmesi gerekir: kullanıcı ne olursa olsun sadece tarayıcıyı kapatır ve oturumu kapatılamaz?

Belki başka bir önbellek sunucusunda biraz para kazanmaktan daha fazla kullanıcıya sahip olmak (erişim kolaydır) daha iyidir.

Bazı nedenlerden dolayı, bu günlerde, tüm genç web geliştiricileri geçmişin derslerini ve bazı şeylerin neden bu şekilde geliştiğini unutmuş gibi görünüyor.

1. Bant genişliği bir sorun oldu
2. Bağlantı kesintili olabilir.
3. Tarayıcılar kadar bilgi işlem gücüne sahip değildi
4. İçeriğe erişmenin başka yöntemleri vardı. Web w3 değil.

Bu kısıtlamalar karşısında, sürekli bir 2 yönlü iletişimin olmayabilir. Ve eğer OSI modeline bakacak olursanız, kaygıların temelini oluşturan bağlantı ile kalıcı kılmayı amaçladıklarını göreceksiniz.

Bunu akılda tutarak, bilgi çekme yöntemi, müşteri tarafında bant genişliğini ve hesaplamayı azaltmanın harika bir yoludur. İtişin yükselişi, gerçekten sadece müşterinin sürekli oylama ya da web soketleri yapmasıdır. Şahsen, dışarıdaki herkes olsaydı, zaman zaman GET / POST isteğinin bir tür orta durumdaki bir erkeğe işaret vereceği, sorgulamanın düzenini trafik analizi aracı olarak takdir ederdim.