DDS "History QoS" - Tarihçe

Giriş

Benim gibi DDS'e aşina olmayan insanların karşılaştıkları sıkıntılardan birisi de History QoS'in nasıl çalıştığı konusundaki kafa karışıklığıdır.

History Qos, DataWriter ve DataReader sınıflarının etkiler. Bu sınıflar daha ellerindeki veriyi gönderip almamış iken DDS ara katmanına yeni bir güncelleme mesajı gelince o instance için kaç tane geçmiş güncelleme mesajını saklamak istediğimizi bildirir.

Aşağıda CorexDDS'in sayfasında bunu gösteren güzel bir resim var. Eğer Topic bir anahtar (key) alanına sahipse History Qos resimde de gösterildiği gibi instance başına kaç tane mesajın bellekte tutulacağını belirtir.

 

Yine aynı şekilde benzer bir çizimi burada buldum .

KEEP_ALL Seçeneği
Eğer History QoS KEEP_ALL ise DataWriter ve DataReader cacheleri birer LinkedList gibi çalışırlar ve en son gelen mesajları saklamaya devam ederler.

Keep_All ile Reliable Reliability beraber kullanılırsa etkileri aşağıdaki gibi olur.

Keep_All + Reliable : Tüm mesajlar mutlaka gönderilir. Gerekirse DataWriter bir süre bloke edilir. Buna absolute veya strict reliability deniyor. Güncellik problemi olmayan ve mutlaka işlenmesi gereken durumlarda kullanır. Örneğin bir müşterinin verdiği sipariş emirleri hiç bir zaman kaybolmamalıdır ve uygulama okuyuncaya kadar saklanmalıdır. JMS tabanlı ara katman yazılımları genellikle bu modeli benimsemişlerdir ve gönderilen mesajlar birisi okuyuncaya kadar saklanılır.

Keep_All ile Unreliable Reliability beraber kullanılırsa etkileri aşağıdaki gibi olur.

Keep_All + Unreliable : Tüm mesajlar gönderilmeye çalışılır. Güncellik problemi olmayan ve mesajın mutlaka işlenmesi de gerekmeyen durumlarda kullanılabilir. Kullanım şekli biraz UDP broadcast'i andırıyor. Broadcast için gönderilen tüm paketlerin mümkün olduğunca gönderilmeye çalışılması gibi.

KEEP_LAST Seçeneği
Eğer History QoS KEEP_LAST ise DataWriter ve DataReader cacheler birer circular buffer gibi çalışırlar ve en son gelen N tane mesajı  saklamaya devam ederler.

Keep_Last ile Reliability beraber kullanılırsa etkileri aşağıdaki gibi olur.

Keep_Last + Reliable    : En son N tane mesaj mutlak gönderilir. Eğer henüz gönderilmemiş mesaj varsa silinir ve gönderilmeye çalışılmaz. Buna reduced reliability deniyor.

Bu kısmı daha iyi açıklayan bir cümleyi şuradan aldım

"Or, as a tradeoff for less memory, CPU, and network usage, you can choose a reduced level of reliability where only the last N values are guaranteed to be delivered reliably to DataReaders (where N is user-configurable). In the reduced level of reliability, there are no guarantees that data sent before the last N are received; only the last N data packets are monitored and repaired if necessary."

Keep_Last ile Unreliable Reliability beraber kullanılırsa etkileri aşağıdaki gibi olur.  

Keep_Last + Unreliable : En son N tane mesaj gönderilmeye çalışılır. Eğer henüz gönderilmemiş mesaj varsa silinir ve gönderilmeye çalışılmaz. Örneğin radardan gelen en son N tane plot'ın tracker'a sokulması için kullanılabilir.

KEEP_LAST kullanılırken OpenDDS'te circular buffer dolu ise ve yer açmak gerekiyorsa bu durum kabaca şöyle kodlanmıştır.

DataWriterImpl::write()->
WriteDataContainer::obtain_buffer()->
WriteDataContainer::remove_oldest_sample()->//En eski instance silinir
WriteDataContainer::enqueue()->//Silinen instance'a ait daha gönderilmemiş mesaj silinir
PublicationInstance->enqueue_tail_next_instance_sample ()//listenin sonuna eklenir