Skip to main content

Bir bakışta

Hem v1 hem de v2, size çözümlenmiş işlemi verir: imzalar, hesap anahtarları, talimatlar, mesaj başlığı ve herhangi bir adres arama tablosu başvurusu. v2’nin eklediği şey, bunun üzerine zenginleştirmedir (yukarıdaki önceden hesaplanmış alanlar), ayrıca canlı abonelik, slot ve canlılık özellikleridir. Zenginleştirme isteğe bağlıdır; aşağıya bakın.

Daha fazla veri, daha az RPC çağrısı

v1 ile çözümlenmiş işlemi alırsınız ve gerisini kendiniz hesaplarsınız. Temel alanların ötesindeki her şey size kalmıştır: ücreti kimin ödediği, belirlediği işlem birimi fiyatı, hangi hesapların yazılabilir olduğu ve sürümlenmiş bir işlemin arama tablolarının arkasındaki gerçek hesaplar. v2 bu işi sizin için yapabilir. Zenginleştirmeyi açın ve her işlem aşağıdaki alanları da taşısın.
compute_unit_price, işlem birimi fiyatıdır; SetComputeUnitPrice içindeki CU başına mikro-lamport değeridir, toplam öncelik ücreti değil. Lamport cinsinden toplam öncelik ücreti için işlem birimi limitiyle çarpın ve 1.000.000’e bölün: compute_unit_price × compute_limit / 1e6. compute_limit yalnızca açık bir SetComputeUnitLimit değerini yansıtır (işlem hiçbiri belirlemezse 0).
Arama tablosu satırı en önemlisidir. Sürümlenmiş bir işlem, tam hesap listesini taşımaz. Zincir üstündeki bir arama tablosuna bir referans artı bir dizi indeks taşır. v1’de, işlemin gerçekte hangi hesaplara dokunduğunu öğrenmek için, her işlem için o tabloyu getirmek üzere tam bir RPC çağrısı yapar ve ardından indeksleri kendiniz çözümlersiniz; akışın kendisinden çok daha yavaş olan ve tam kritik yolunuzun üzerinde duran ek bir istek ve yanıt. v2 zenginleştirmesi açıkken, bu çözümlenmiş adresler zaten dahildir, bu nedenle bu arama kritik yolunuzun dışındadır. Diğer satırlar, istemcinizin aksi takdirde her işlemde tekrarlayacağı işlerdir; v2 bunun yerine yanıtları satır içinde sunar.
Sürümlenmiş bir işlem için çözümlenmiş arama tablosu adresleri dahil edilir. Herhangi biri tam olarak dahil edilemezse, o işlemde alt_resolution_incomplete ayarlanır, böylece bunları kendiniz çözümlersiniz (tabloları RPC yoluyla getirin); sessiz boşluklar yok.
Zenginleştirme isteğe bağlıdır ve varsayılan olarak kapalıdır. Ek alanları istediğinizde abonelik başına açın (bir filtrede include_enrichment: true); açmak akışa hiç gecikme eklemez; tek fark biraz daha büyük bir mesajdır. Abonelik genelindedir: aktif filtrelerden herhangi biri açarsa, oturumun aldığı her işlem zenginleştirilir.

Yeniden bağlanmadan akışınızı yönetin

v1’de filtrelerinizi bir kez, akışı açan mesajda ayarlarsınız. Farklı bir şey izlemek için bağlantıyı bırakır ve yeni bir tane açarsınız, yeniden bağlanırken canlı akışı kaybedersiniz. v2, akışı açık tutar ve ilerledikçe filtre eklemenize ve kaldırmanıza olanak tanır. Her filtreye kendi filter_id değerinizi verirsiniz, sunucu her ekleme ve kaldırmayı onaylar (ve birini reddederse nedenini söyler) ve her işlem, eşleştiği filter_id değerlerini listeler. Tek bir bağlantıda birkaç filtre çalıştırın, bunları anında değiştirin ve belirli bir işlemi hangi filtrenin ürettiğini her zaman bilin. Hesap include / exclude / required, tam olarak v1’deki gibi davranır; required herhangi-biri anlamındadır (bir işlem, listelenen en az bir hesaba başvuruyorsa eşleşir), hepsi değil.

Slot olaylarıyla zinciri takip edin

v2, v1’de benzeri olmayan ikinci, ayrı bir akış olan SubscribeSlots ekler. Bir slot başladığında (ALIVE), bittiğinde (COMPLETE) veya atlandığında ya da tamamlanmadan sonraki slotlar tarafından geçersiz kılındığında (DEAD) o slotun lideri ve üstü ile birlikte bir olay alırsınız. Bu, zincirin nerede olduğunu işlem akışından çıkarım yapmak yerine izlemenin ucuz bir yoludur.

Bir şeyi kaçırdığınızı bilin

v1’in size hiç vermediği iki şey:
  • Her v2 mesajı, işlemler ve slot olayları aynı şekilde, birer birer artan bir sequence numarası taşır. Bir boşluk görürseniz bir mesaj bıraktığınızı bilirsiniz.
  • Bir işlem akışı sessizleştiğinde, v2 sunucunun saatiyle damgalanmış, her 60 saniyede bir Heartbeat gönderir. Bu, yük dengeleyici boşta zaman aşımları boyunca bağlantıyı canlı tutar ve sessiz bir akışı ölü bir akıştan ayırt eder.

Bunun neden daha hızlı bir sonuca yol açtığı

  • Kritik yolunuzun dışında bir gidiş-dönüş. v1’de bir arama tablosunu çözümlemek, akışın kendisinden çok daha yavaş olan tam bir RPC isteği ve yanıtıdır. v2 zenginleştirmesi açıkken, sürümlenmiş bir işlemin çözümlenmiş adresleri satır içinde gelir, böylece o çağrı asla bir işlemin gelmesi ile sizin harekete geçmeniz arasında durmaz.
  • Sizin tarafınızda işlem başına daha az iş. Zenginleştirme alanları zaten hesaplanmış olarak gelir, böylece istemciniz bunları her işlemde yeniden türetmez.
  • Yeniden bağlanma boşlukları yok. Filtreleri canlı değiştirmek, yeniden abone olmak için akışı asla bırakmadığınız anlamına gelir.
  • Kayıp ve durmalar hemen görünür sonradan çıkarım yapmak yerine sıra numaraları ve kalp atışları aracılığıyla.

Hangisini kullanmalısınız

Yeni entegrasyonlar için v2 kullanın. Zenginleştirme, slot olayları, canlı filtreler ve canlılık sinyallerinin bulunduğu ve her yeni yeteneğin geldiği yerdir. v1 tam olarak desteklenmeye devam eder ve henüz belirlenmiş bir emeklilik tarihi yoktur, bu nedenle mevcut bir v1 istemcisi olduğu gibi çalışmaya devam edebilir. Yine de geçmenizi teşvik ediyoruz: daha fazla trafik v2’de birleştikçe, bugün v1’e ayırdığımız kapasiteyi bir sonraki nesil OrbitFlare akışı için serbest bırakır. Her iki durumda da geçiş, bağlantınızda değil istemci kodunuzda bir değişikliktir: aynı uç noktalar, aynı kimlik doğrulama, yan yana çalışır.

Ayrıca Bakınız

Jetstream v2 Genel Bakış

Akış modeli, bağlanma ve en iyi uygulamalar.

v2 Protokol Referansı

Tam v2 Protocol Buffer belirtimi, uç noktalar ve kod oluşturma.

Jetstream (v1)

v1 genel bakışı, istemci örnekleri ve filtreleme kılavuzu.

Destek

Jetstream v2 hakkında teknik destek veya sorularınız için lütfen destek ekibimizle iletişime geçin ya da Discord topluluğumuza katılın.