IoT / Mosquitto Nedir ?

Eclipse Mosquitto bir açık kaynaklı (EPL/EDL lisanslı) bir message broker'ıdır.  Az yer kaplayan her sisteme uygun ve kartta çalışan bir sistemdir.

https://github.com/eclipse/mosquitto

MQTT Nasıl çalışır?

MQTT bir mesajlaşma protokolüdür, yani mesajları aktarmak için tasarlanmıştır ve bir yayınlama ve abone olma modeli kullanır.

Bu model 0,1 veya birden fazla istemciye mesaj göndermeyi mümkün kılar.

Yararlı bir benzetme, TV veya radyodur.

Bir TV yayıncısı, belirli bir kanalı kullanarak bir TV programını yayınlar ve bir izleyici, yayını izlemek için bu kanalı açar.

Yayıncı ile izleyici arasında doğrudan bir bağlantı yoktur.

MQTT'de bir yayıncı bir konu hakkında mesajlar yayınlar ve bir abonenin mesajı görüntülemek için o konuya abone olması gerekir.

MQTT, aşağıdaki şemada gösterildiği gibi merkezi bir Broker kullanılmasını gerektirir:

Dikkat Edilmesi Gereken Önemli Noktalar 

1. İstemcilerin e-posta sistemlerindeki gibi adresleri yoktur ve istemcilere mesaj gönderilmez.
2. Mesajlar, bir konu hakkında bir brokera yayınlanır. 
3. Bir MQTT aracısının işi, mesajları konuya göre filtrelemek ve ardından bunları abonelere dağıtmaktır. 
4. Bir client, aynı brokerda o konuya abone olarak bu mesajları alabilir 
5. Bir yayıncı ile abone arasında doğrudan bir bağlantı yoktur. 
6. Tüm clients yayınlayabilir ve abone olabilir. 
7. MQTT aracıları normalde iletileri saklamaz.

MQTT Client-Broker Connections

• MQTT, brokera bağlanmak için TCP / IP kullanır. 
• TCP, hata düzeltme özelliğine sahip bağlantı odaklı bir protokoldür ve paketlerin sırayla alınmasını garanti eder. 
• Bir TCP / IP bağlantısının telefon bağlantısına benzer olduğunu düşünebilirsiniz. Bir telefon bağlantısı kurulduktan sonra, bir taraf telefonu kapatana kadar bunun üzerinden konuşabilirsiniz. 
• Çoğu MQTT istemcisi, brokera  bağlanacak ve veri göndermiyor olsalar bile bağlı kalacaktır.
• Bağlantılar, aracı tarafından bir Bağlantı onay iletisi kullanılarak onaylanır. Bağlanmadıkça yayınlayamaz veya abone olamazsınız.

MQTT istemcileri, aracıya istemcinin hala bağlı olduğunu bildiren düzenli aralıklarla (genellikle 60 saniye) bir canlı tutma iletisi yayınlar.

The Client Name or Client ID

• Tüm clientların bir client name veya ID'ye sahip olması gerekir. 
• Client (istemci) adı, MQTT broker (aracı) tarafından abonelikleri vb. izlemek için kullanılır. 
• İstemci adları da benzersiz olmalıdır. 
• Mevcut bir istemciyle aynı ada sahip bir MQTT aracısına bağlanmaya çalışırsanız, mevcut istemci bağlantısı kesilir. Çoğu MQTT istemcisi bir bağlantı kesildikten sonra yeniden bağlanmayı deneyeceğinden, bu bağlantı kesilme ve bağlanma döngüsüne neden olabilir. 

Aşağıdaki ekran görüntüsü, mevcut bir bağlı istemciyle aynı istemci kimliğini kullanarak bir istemciyi aracıya bağlamaya çalıştığımda ne olduğunu gösteriyor.

Clean Sessions

• MQTT istemcileri varsayılan olarak bir aracı ile temiz bir oturum oluşturur. 
• Temiz bir oturum, aracının bağlantısı kesildiğinde istemci hakkında hiçbir şey hatırlamasının beklenmediği bir oturumdur. 
• Temiz olmayan bir oturumda aracı, müşteri aboneliklerini hatırlar ve müşteri için teslim edilmemiş mesajları saklayabilir. 
• Ancak bu, konulara abone olurken kullanılan hizmetin kalitesine ve bu konuları yayınlarken kullanılan hizmetin kalitesine bağlıdır.

Last Will Messages

• Last Will mesajının fikri, bir aboneye ağ kesintisi nedeniyle yayıncının müsait olmadığını bildirmektir. 
• Son istek mesajı yayıncı müşteri tarafından belirlenir ve konu bazında belirlenir, bu da her konunun kendi son mesajına sahip olabileceği anlamına gelir. 
• Bu, her konu kabininin kendisiyle ilişkilendirilmiş kendi son istek mesajına sahip olduğu anlamına gelir. 
• Mesaj, aracıda depolanır ve yayıncı ile bağlantı kurulamazsa abone olan herhangi bir müşteriye (bu konuya) gönderilir. 
• Yayıncı normalde bağlantıyı keserse, son Will Mesajı gönderilmez. Gerçek irade mesajları, bağlanma talebi mesajıyla birlikte verilir.

Understanding MQTT Topics

• MQTT konuları, MQTT istemcilerinin bilgi paylaşmasına olanak tanıyan bir adresleme biçimidir. 
• MQTT Konuları, sınırlayıcı olarak eğik çizgi (/) kullanan bir dosya sistemindeki klasörlere ve dosyalara benzer bir hiyerarşi içinde yapılandırılmıştır. 
• Bu sistemi kullanarak, kendi seçtiğiniz, kullanıcı dostu ve kendi kendini tanımlayan bir adlandırma yapısı oluşturabilirsiniz. 
• Konu adları şunlardır: Büyük / küçük harfe duyarlı UTF-8 dizelerini kullanır. 
• Geçerli olması için en az bir karakterden oluşmalıdır.

$ SYS konusu dışında varsayılan veya standart bir konu yapısı yoktur. 

Yani, $ SYS konusu haricinde bir brokerda varsayılan olarak oluşturulan konu yoktur. 

Tüm konular abone veya yayın yapan bir client tarafından oluşturulur ve kalıcı değildir. 

Bir konunun mevcutluğu ancak bir client konuya subscribe olmuşsa veya bir brokker o konu için saklanan veya son istek mesajlarına sahipse olur.

Aşağıda $ SYS konusunu izleyen ve aşağıda gösterildiği gibi bir görüntü oluşturan node-red programıyla bir gösterge tablosu oluşturulmuş:

Wildcard character

Yazılımda joker karakter, bir dizi değişmez karakter veya boş bir dize olarak yorumlanabilen yıldız işareti (*) gibi tek bir karakterle temsil edilen bir tür yer tutucudur. Genellikle dosya aramalarında kullanılır, bu nedenle tam adın yazılmasına gerek yoktur.

Subscribing to Topics

Bir müşteri, bir veya birden fazla konuya abone olabilir. 

Birden fazla konuya abone olurken iki joker karakter kullanılabilir. Bunlar: 

• # (karma karakter) - çok seviyeli joker karakter 
• + (artı karakter) - tek seviyeli joker karakter 

Joker karakterler, yalnızca bir seviyeyi veya çoklu seviyeleri, yani / house / # belirtmek için kullanılabilir ve birden çok karakteri belirtmek için adın bir parçası olarak kullanılamaz Örneğin hou # geçerli değil.

Topic naming Examples:

Valid Topic subscriptions

Tek konu abonelikleri

 

• /
• /house
• house/room/main-light
• house/room/side-light

Using Topic Wildcards

Subscribing to topic house/#

Covers

• house/room1/main-light
• house/room1/alarm
• house/garage/main-light
• house/main-door
• etc

Subscribing to topic house/+/main-light

covers

• house/room1/main-light
• house/room2/main-light
• house/garage/main-light

but doesn’t cover

• house/room1/side-light
• house/room2/side-light

Invalid Topic Subscriptions

• house+ – Reason- no topic level
• house# – Reason- no topic level

Publishing to Topics

Bir client yalnızca tek bir konuda publish yapabilir. Yani, yayınlamaya izin verilmediğinde joker karakterlerin kullanılması. 

E.G- İki konuya bir mesaj yayınlamak için, mesajı iki kez yayınlamanız gerekir. 

When are Topics Created

Başlıklar şu durumlarda dinamik olarak oluşturulur: 

• Birisi bir konuya abone olduğunda 
• Birisi, tutulan mesajı True olarak ayarlanmış bir konuya bir mesaj yayınlar. 

When are Topics Removed from a Broker

• Bu brokera subscribe olan son client bağlantısı kesildiğinde ve temiz oturum doğruysa.
• Bir client True olarak ayarlanmış temiz oturumla bağlandığında. 

Republishing Topic Data

Bu, büyük olasılıkla adlandırma şemalarını değiştirirken veya birleştirirken yapılır. 

Buradaki fikir, bir müşterinin bir konuya abone olmasıdır, ör. hub1 / sensor1 ve house1 / main-light gibi yeni bir konu adı kullanarak verileri yeniden yayınlayın.

$SYS/MQ branch of queue manager topic tree

Kuyruk yöneticisi konu ağaçlarındaki sistem konuları, kaynak izleme ve uygulama etkinliği izleme için kullanılır.

Her kuyruk yöneticisinin konu ağacı, $ SYS / MQ dalını içerir. Kuyruk yöneticisi bu daldaki konu dizilerini yayınlar. Yetkili bir kullanıcı, kuyruk yöneticisi ve bunun üzerindeki etkinlik hakkında bilgi almak için bu konu dizilerine abone olabilir. Bu sistem konuları, uygulama etkinliği izleme ve izleme için kullanılır. 

Topic trees

Tanımladığınız her konu, konu ağacındaki bir öğe veya düğümdür. Konu ağacı başlamak için boş olabilir veya MQSC veya PCF komutları kullanılarak önceden tanımlanmış konuları içerebilir. Konu oluştur komutlarını kullanarak veya bir yayın veya abonelikte ilk kez konuyu belirterek yeni bir konu tanımlayabilirsiniz. Bir konunun konu dizesini tanımlamak için herhangi bir karakter dizesi kullanabilmenize rağmen, hiyerarşik ağaç yapısına uyan bir konu dizisi seçmeniz önerilir. Konu sokmalarının ve konu ağaçlarının dikkatlice tasarlanması aşağıdaki işlemlerde size yardımcı olabilir: 

• Birden fazla konuya abone olmak. 
• Güvenlik politikalarının oluşturulması. 

Bir konu ağacını düz, doğrusal bir yapı olarak oluşturabilseniz de, bir veya daha fazla kök konu içeren hiyerarşik bir yapıda konu ağacı oluşturmak daha iyidir. 

Şekildeki her karakter dizisi konu ağacındaki bir düğümü temsil eder. Konu ağacındaki bir veya daha fazla seviyeden düğümlerin toplanmasıyla eksiksiz bir konu dizesi oluşturulur. Seviyeler, "/" karakteriyle ayrılır. Tam olarak belirtilmiş bir konu dizesinin biçimi: "kök / düzey2 / düzey3" şeklindedir. 

Şekil 1'de gösterilen konu ağacındaki geçerli konular şunlardır:

• "USA"
• "USA/Alabama"
• "USA/Alaska"
• "USA/Alabama/Auburn"
• "USA/Alabama/Mobile"
• "USA/Alabama/Montgomery"
• "USA/Alaska/Juneau"

Konu dizelerini ve konu ağaçlarını tasarlarken, kuyruk yöneticisinin konu dizesinin kendisini yorumlamadığını veya ondan anlam çıkarmaya çalışmadığını unutmayın. Seçili mesajları o konunun abonelerine göndermek için sadece konu dizisini kullanır. Bir konu ağacının yapısı ve içeriği için aşağıdaki ilkeler geçerlidir: 

• Bir konu ağacındaki düzeylerin sayısında bir sınır yoktur. 
• Bir konu ağacındaki bir seviyenin adının uzunluğunda bir sınır yoktur. 
• Herhangi bir sayıda "kök" düğüm olabilir; yani, herhangi bir sayıda konu ağacı olabilir.

MESSAGE BROKER Nedir?

Message Broker;  uygulamaların, sistemlerin ve hizmetlerin birbirleriyle iletişim kurmasını ve bilgi alışverişi yapmasını sağlayan bir yazılımdır. Bu birbirlerine bağlı sistemler farklı dillerde yazılmış veya farklı platformlarda uygulanmış olsalar bile, birbirleriyle doğrudan "konuşmalarına / (talk)" izin verir.

Mesaj broker, mesajlaşma middleware veya mesaj odaklı middleware (MOM) çözümleri içindeki yazılım modülleridir. Bu tür ara yazılım, geliştiricilere bir uygulamanın bileşenleri arasındaki veri akışını işlemenin standartlaştırılmış bir yolunu sağlar, böylece temel mantığına odaklanabilirler. Birden çok platforma yayılan uygulamaların dahili olarak iletişim kurmasına izin veren dağıtılmış bir iletişim katmanı görevi görebilir. Mesaj aracıları mesajları doğrulayabilir, depolayabilir, yönlendirebilir ve uygun hedeflere iletebilir. Gönderenlerin alıcıların nerede olduğunu, aktif olup olmadıklarını veya kaç tane olduğunu bilmeden mesaj göndermelerine izin vererek diğer uygulamalar arasında aracı görevi görürler. Bu, sistemler içindeki süreçlerin ve hizmetlerin ayrıştırılmasını kolaylaştırır.

Mesaj aracıları mesajları doğrulayabilir, depolayabilir, yönlendirebilir ve uygun hedeflere iletebilir. Gönderenlerin alıcıların nerede olduğunu, aktif olup olmadıklarını veya kaç tane olduğunu bilmeden mesaj göndermelerine izin vererek diğer uygulamalar arasında aracı görevi görürler. Bu, sistemler içindeki süreçlerin ve hizmetlerin ayrıştırılmasını kolaylaştırır.

ASYNCHRONOUS MESSAGE Nedir?

Asynchronous mesajlaşma, mesajların doğru sırada (ve yalnızca bir kez) teslim edilmesini garanti eder. Mesaj brokerları, birden çok mesaj kuyruğu arasındaki etkileşimleri idare etmek için queue managerlerinin yanı sıra veri yönlendirme, mesaj çevirisi, kalıcılık ve client state management işlevlerini sağlayan hizmetler içerebilir.

Bir asynchrone mesaj talep edicisi, bir program tarafından başlatılan bir rutindir. Ancak bu daha sonra mesajları talep eden ve işleyen orijinal programdan bağımsız çalışır. 

Herhangi bir mesaj HERHANGİ kuyruğa geldiğinde uygulamanın "uyanmasına" izin verilmez. Z / OS'de, SIGNAL ile bekle seçeneğinin bunu elde etmek için kullanılabileceğini, ancak yalnızca z / OS'de kullanılabileceğini unutmayın.

Z/OS Nedir? 

Z/OS, IBM tarafından Ekim 2000'de piyasaya sürülen IBM ana bilgisayarları için 64 bitlik bir işletim sistemidir. Z/OS, modern işletim sistemlerinin özniteliklerine sahiptir, ancak aynı zamanda 1960'lardan beri ortaya çıkan ve hala düzenli kullanımda olan eski işlevlerin çoğunu da korur.

QoS Nedir?

IP ağlarında yeterli Hizmet Kalitesi (Quality of Service-QoS) sağlamak günümüzün kurumsal IT altyapısının giderek daha önemli bir yönü haline gelmektedir. QoS sadece ağ üzerinden ses ve video akışı için değil, son zamanlarda büyüyen Nesnelerin İnternet’inin (Internet of Things-IoT) desteklenmesinde de önemli bir faktördür.

‘QoS’, bir port önceliği tekniğidir ve ‘paket önceliklendirme’, ‘uygulama sınıflandırma’ ya da ‘tıkanıklık noktalarında sıraya girme’ gibi çeşitli trafik şekillendirme teknikleriyle geliştirilmiştir.

Ağınızda çalışan bazı uygulamalar gecikmeye duyarlıdır. Bu uygulamalar genellikle TCP protokolünün aksine UDP protokolünü kullanır. Zaman farkına bağlı olarak TCP ve UDP arasındaki temel fark; TCP'nin geçiş sırasında kaybedilen paketleri yeniden iletmesidir. Bir bilgisayardan diğerine dosya aktarımı için, TCP paketleri kullanılmalıdır, çünkü TCP paketleri herhangi bir paketin kaybolması, yanlış biçimlendirilmesi veya sıradan çıkarılması durumunda, paketleri hedef PC'de yeniden oluşturmak için yeniden gönderebilir ve yeniden düzenleyebilir.

Ancak UDP uygulamaları için (IP telefon aramaları gibi), herhangi bir kayıp paket yeniden iletilemez. Bunun sebebi de ses paketlerinin sıralı bir akış olarak gelmesinden kaynaklanmaktadır, yeniden ileten paketler kullanışsızdır burada. Bu yüzden de UDP protokolünü çalıştıran uygulamalar için herhangi bir kayıp veya gecikmiş paket gerçek bir sorundur. Sesli çağrılar üzerinden örnek verecek olursak, arama esnasında birkaç paketin bile kaybedilmesi, ses kalitesinin kesik ve anlaşılmaz hale gelmesine neden olacaktır. Ek olarak, paketler jitter’lara karşı hassastır. 

Jitter (seyirme), bir akış uygulamasının gecikmesindeki değişiklik, çeşitliliktir.

Ağınızda çok fazla bant genişliği (bandwidth) varsa ve üstesinden gelebilecek trafiğe sahipse, paket kaybı, gecikme veya titreme ile ilgili bir sorun yaşamayacaksınız. Ancak birçok kurumsal ağda, yönlendiricilerin (routers) ve anahtarların (switches) aşırı derecede tıkanmaya başladıkları zamanlar olacak ve bu noktada paketleri bırakmaya başlayacaklardır, çünkü işlenirken geçen süreden daha hızlı giriş/çıkış yaparlar. Bu durumda, akış uygulamalarınız zarar görmeye başlar. QoS işte tam burada devreye girer.

Gecikme: Kaynaktan hedefe doğru gerçekleşen veri iletimindeki gecikme
Güvenilirlik: Router-yönlendirici tarafından ıskartaya çıkarılan paketlerin oranı
İnternet protokollerini geliştirmek ve standartlaştırmakla görevli ‘İnternet Mühendisliği Görev Grubu (Internet Engineering Task Force – IETF)’, ‘QoS’ standardını 2 ana model olarak tanımlar: Integrated Services (Intserv) ve Differentiated Services (Diffserv).
Bu iki model, tercih edilen trafik türünü sağlayan mekanizmaların kategorilerini kapsamaktadır.

QoS’un Kullanımı ve Faydaları
Ağ yöneticileri, kritik öneme sahip uygulamaların aktarım işleminin kabul edilebilir bir zaman içinde sağlanabilmesini garanti etmek için ‘QoS’ kullanabilir. Aynı zamanda ağ yöneticileri ‘QoS’u, Kullanıcı Veri Protokolü’nü (UDP) yönetmek için de tercih edebilir.

QoS Nasıl Çalışır?

QoS, ağ altyapınızdaki paket kaybı, gecikme ve titreşim sorunlarını yönetmeye yardımcı olur. Sonlu bir bant genişliği ile çalıştığımız için, ilk işimiz, bu üç şeyin yönetilmesinde hangi uygulamaların daha çok fayda sağlayacağını tanımlamaktır. Ağ ve uygulama yöneticileri ağdaki bant genişliğine göre öncelikli olması gereken uygulamaları belirledikten sonra bu trafiği tanımlamak gerekecektir. Trafiği tanımlamanın veya işaretlemenin birkaç yolu vardır. Hizmet Sınıfı (Class of Service-CoS) ve Farklı Hizmetler Kod Noktası (Differentiated Services Code Point-DSCP) iki örnektir. CoS, 2. katmanın (layer) paket başlığında bir veri akışını işaretlerken, DSCP 3. katmanın (layer) paket başlığında bir veri akışını işaretleyecektir. Uygulamalar farklı olarak işaretlenebilir, bu da ağ ekipmanının verileri farklı gruplara sınıflandırmasını sağlar.

Artık veri akışlarını farklı gruplara ayırabildiğimize göre, bu bilgileri bazı veri akışları arasında öncelik sıralamasını sağlamak için kullanabiliriz. Bu durum queuing (kuyruklama, sıraya alma) olarak bilinir. Örneğin, ses trafiği etiketlendiyse ve bir bağlantı üzerindeki ağ bant genişliğinin çoğuna erişim sağlamak için ilke oluşturulursa, yönlendirme (route) veya anahtarlama (switch) aygıtı bu paketleri sıranın önüne taşır ve hemen iletir. Ancak standart bir TCP veri aktarım akışı daha düşük bir önceliğe sahipse, iletilecek bant genişliği yeterli olana kadar bekleyecektir (sıraya alınacaktır). Sıra çok fazla dolarsa, bu düşük öncelikli paketler ilk bırakılır.

‘TCP’nin aksine ‘UDP’ doğal olarak daha az güvenilir bir protokoldür ve ağ üzerinden geri bildirim almaz. Bu yüzden de ağ tıkanıklıklarını fark edebilme yetisi yoktur. Ağ yöneticileri ise ‘QoS’u kullanarak ‘UDP’ üzerindeki uygulamaların öncelik sıralamasını yönetebilirler. Buna multimedya uygulamaları da dahildir. Böylece ağın tıkandığı vakitlerde dahi yeterli bant genişliği sağlanır ve ağa da yüklenilmemiş olur.

Kısaca, QoS’un temel faydaları şunlardır:
• Ağ yöneticilerine, ağ kaynakları üzerinde kontrol imkanı tanır.
• Kritik göreve ve zaman hassasiyetine sahip uygulamaların yeterli kaynağa sahip olmasını sağlar.
• Kullanıcı tecrübesini arttırır.
• Kaynakların verimli şekilde kullanımını sağlar.

Message Flow and QOS on Published Messages Nedir?

MQTT, 0, 1, 2, 3 QOS seviyesini destekler. 

• QOS -0 - Varsayılan ve mesaj teslimini garanti etmez. 
• QOS -1 - Mesaj teslimini garanti eder, ancak yinelenen mesajlar alabilir. 
• QOS -2 - Yinelenmeyen ileti teslimini garanti eder. 

QOS seviyesi 0 varsayılan olmak üzere bu seviyelerden biri kullanılarak bir mesaj yayınlanır. 

Abonenin çevrimiçi olmasa bile bir mesaj almasını sağlamak istiyorsanız, 1 veya 2 hizmet kalitesinde yayınlamanız gerekir. 

Aşağıdaki şema, QOS ile mesajlar için istemci ve aracı arasındaki mesaj akışını gösterir. 0, 1 ve 2.

QOS 1 ve 2 ile yayınlanan mesajlar, sunucu tarafından onaylanır. Bu, birkaç mesajın gönderilmesine neden olur. QOS 0 ile yayınlanan mesajlar yalnızca 1 mesaj gerektirir ve sunucu tarafından onaylanmaz. QOS değeri 1 veya 2 olan yayınlanmış mesajların ayrıca mesajı izlemek için kullanılabilen bir Mesaj ID numarası vardır.

Publishing Messages and The Retain Flag Nedir?

Bir istemci (client) bir aracıya bir mesaj yayınladığında, göndermesi gereken: 

• Mesaj konusu 
• Mesaj QOS 
• Mesajın saklanıp saklanmayacağı. - Tutma Bayrağı (retain flag) 

Tutma Bayrağı normalde False olarak ayarlanır, bu da aracının mesajı saklamadığı anlamına gelir.

Tutma bayrağını True olarak ayarlarsanız, aracı tarafından o konuda alınan ve tutulan bayrak ayarlı son ileti saklanacaktır. 

Yayınlanan mesajın QOS'unun saklanan mesaj üzerinde hiçbir etkisi yoktur. 

Bunun ana kullanımı, çok fazla değişmeyen ve durumlarını seyrek olarak yayınlayan sensörler içindir. Örneğin, bir kapı sensörünüz varsa, neredeyse her zaman aynı olduğu halde her saniye durumunun yayınlanması pek mantıklı olmaz. 

Ancak, yalnızca yayınlarsa, bir abone sensöre abone olduğunda olanları değiştirdiğinde durumu değişir. Bu durumda, son durum koruma bayrağı ayarlanmadan yayınlanmışsa, abone tekrar yayınlayana kadar sensörün durumunu bilemez.

https://tr.wikipedia.org/wiki/%C4%B0nternet_ileti%C5%9Fim_kurallar%C4%B1_dizisi

1. Publish–subscribe pattern Nedir?

Yazılım mimarisinde, publish-subscribe, mesaj şablonunda mesaj gönderenler publishers bir alıcıya, mesaj alınıyorsa bu kısımada subscriberlar denir. Özel olarak bir subscribera mesaj göndermeyip bunun yerine mesajlara "class"lanmalıdır. Benzer şekilde, subscribers bir veya daha fazla sınıfla ilgilendiklerini ifade ederler ve eğer varsa, hangi publishers olduğunu bilmeden, yalnızca ilgilendikleri mesajları alırlar. Publisch-subscribe, message queue paradigmasının bir kardeşidir ve genellikle daha büyük bir ileti yönelimli middleware sisteminin bir parçasıdır. Çoğu mesajlaşma sistemi API'lerinde hem pub / sub hem de message queue modellerini destekler, ör. Java Mesaj Hizmeti (JMS).

Bu model, daha fazla ağ ölçeklenebilirliği ve daha dinamik bir ağ topolojisi sağlar ve bunun sonucunda, publisher ve published data yapısını değiştirme esnekliği azalır.

1. 1 Message filtering

Publish-subscriber modelinde, aboneler tipik olarak yayınlanan toplam mesajların sadece bir alt kümesini (subset) alırlar. Alma ve işleme (Reception and processing) için mesaj seçme işlemine filtreleme adı verilir. İki yaygın filtreleme biçimi vardır: konu tabanlı ve içerik tabanlı (topic-based and content-based). Konu tabanlı bir sistemde, mesajlar "konulara (topics)" veya adlandırılmış mantıksal (logical) kanallara yayınlanır. 

Konu bazlı (topic based) bir sistemdeki aboneler, abone oldukları konularla ilgili yayınlanan tüm mesajları alacaklardır. Yayıncı, abonelerin abone olabileceği konuları tanımlamaktan sorumludur. 

İçerik bazlı (content based) bir sistemde, mesajlar bir aboneye sadece bu mesajların öznitelikleri veya içeriği abone tarafından tanımlanan kısıtlamalara uyuyorsa teslim edilir. Abone, mesajların sınıflandırılmasından sorumludur. 

Bazı sistemler ikisinin bir karışımını destekler; yayıncılar bir konuya mesaj gönderirken, aboneler bir veya daha fazla konuya içerik tabanlı abonelik kaydeder.

1. 2 Topologies

Birçok pub / sub sisteminde, yayıncılar mesajları bir ara mesaj brokerveya olay veri yoluna gönderir ve aboneler bu aracıyla abonelikleri kaydederek aracının filtrelemeyi gerçekleştirmesine izin verir. Aracı, normal olarak mesajları yayıncılardan abonelere yönlendirmek için bir saklama ve iletme işlevi gerçekleştirir. Ek olarak, aracı, yönlendirmeden önce bir kuyruktaki iletilere öncelik verebilir.

Aboneler, derleme zamanında, başlatma zamanında veya çalışma zamanında belirli mesajlar için kayıt olabilir. GUI sistemlerinde, aboneler, oluşturma süresi kaydına karşılık gelen kullanıcı komutlarını (örneğin, bir düğmeye tıklama) işlemek üzere kodlanabilir. Bazı çerçeveler ve yazılım ürünleri, aboneleri kaydetmek için XML yapılandırma dosyalarını kullanır. Bu konfigürasyon dosyaları, başlangıç ​​zamanında okunur. En karmaşık alternatif, abonelerin çalışma zamanında eklenebildiği veya kaldırılabildiği zamandır. Bu ikinci yaklaşım, örneğin, veritabanı tetikleyicilerinde, posta listelerinde ve RSS'de kullanılır.

Veri Dağıtım Hizmeti (DDS) ara yazılımı, ortada bir aracı kullanmaz. Bunun yerine, pub / sub sistemindeki her yayıncı ve abone, IP multicast yoluyla birbirleriyle ilgili meta dataları paylaşır. Yayıncı ve aboneler bu bilgileri yerel olarak önbelleğe alır ve paylaşılan bilişte birbirlerinin keşfine dayalı olarak mesajları yönlendirir. Gerçekte, aracısız mimariler, yayıncılardan abonelere verimli ve merkezi olmayan yönlendirmeye izin veren bir üst üste bindirme ağı oluşturmak için yayınlama / abone olma sistemi gerektirir. Jon Kleinberg, verimli merkezi olmayan yönlendirmenin Navigable Small-World topolojileri gerektirdiğini göstermiştir. Bu tür Küçük Dünya topolojileri genellikle merkezi olmayan veya federe yayın / abone sistemleri tarafından uygulanır. Yerelliğe duyarlı yayınlama / abone olma sistemleri, abonelikleri kısa mesafeli ve düşük maliyetli bağlantılar aracılığıyla yönlendiren ve böylece abonelik teslim sürelerini azaltan Küçük Dünya topolojileri oluşturur.

• Metadata

Meta veriler, "diğer veriler hakkında bilgi sağlayan verilerdir". Başka bir deyişle, "verilerle ilgili veriler" dir. Açıklayıcı meta veriler, yapısal meta veriler, yönetim meta verileri, referans meta verileri ve istatistiksel meta veriler dahil olmak üzere birçok farklı meta veri türü mevcuttur. Açıklayıcı meta veriler, bir kaynak hakkında açıklayıcı bilgidir. Keşif ve kimlik tespiti için kullanılır. Başlık, özet, yazar ve anahtar sözcükler gibi öğeleri içerir. Yapısal meta veriler, veri kapları hakkında meta verilerdir ve bileşik nesnelerin nasıl bir araya getirildiğini, örneğin sayfaların bölümleri oluşturmak için nasıl sıralandığını gösterir. Dijital malzemelerin türlerini, sürümlerini, ilişkilerini ve diğer özelliklerini açıklar. Yönetim meta verileri, kaynak türü, izinler ve ne zaman ve nasıl oluşturulduğu gibi bir kaynağı yönetmeye yardımcı olan bilgilerdir. Referans meta veriler, istatistiksel verilerin içeriği ve kalitesi hakkındaki bilgilerdir. İşlem verileri olarak da adlandırılan istatistiksel meta veriler, istatistiksel verileri toplayan, işleyen veya üreten süreçleri tanımlayabilir.

1. 3  Advantages

• Loose coupling

Yayıncılar abonelere gevşek bir şekilde bağlıdır ve onların varlığından haberdar olmaları bile gerekmez. Konunun odak noktası olmasıyla, yayıncıların ve abonelerin sistem topolojisinden habersiz kalmalarına izin verilir. Her biri diğerinden bağımsız olarak normal şekilde çalışmaya devam edebilir. Gevşek eşleşme [değiştir] Yayıncılar abonelere gevşek bir şekilde bağlıdır ve onların varlığından haberdar olmaları bile gerekmez. Konunun odak noktası olmasıyla, yayıncıların ve abonelerin sistem topolojisinden habersiz kalmalarına izin verilir. Her biri diğerinden bağımsız olarak normal şekilde çalışmaya devam edebilir. Geleneksel sıkıca bağlı istemci-sunucu paradigmasında, istemci, sunucu işlemi çalışmıyorken sunucuya mesaj gönderemez veya istemci çalışmadığı sürece sunucu mesajları alamaz. Birçok pub / sub sistemi yalnızca yayıncıların ve abonelerin konumlarını ayırmakla kalmaz, aynı zamanda bunları geçici olarak da ayırır. Bu tür pub / sub sistemlerde ara yazılım analistleri tarafından kullanılan yaygın bir strateji, abonenin biriktirme listesi (bir tür bant genişliği daraltma) boyunca çalışmasına izin vermek için bir yayıncıyı devreden çıkarmaktır.

• Scalability

Pub / sub, paralel işlem, mesaj önbelleğe alma, ağaç tabanlı veya ağ tabanlı yönlendirme vb. Yoluyla geleneksel istemci-sunucuya göre daha iyi ölçeklenebilirlik fırsatı sağlar. pub / sub altyapısını paylaşan binlerce sunucuyla veri merkezleri haline gelmek için ölçeklendirin, mevcut vendor systems genellikle bu avantajı kaybeder; Bu bağlamlarda yüksek yük altındaki pub / sub ürünleri için ölçeklenebilirlik bir araştırma zorluğudur. Öte yandan, kurumsal ortamın dışında, pub / sub paradigması, RSS ve Atom gibi web sendikasyon protokolleri aracılığıyla İnternet çapında dağıtılmış mesajlaşma sağlayarak, tek bir veri merkezinin çok ötesinde hacimlere ölçeklenebilirliğini kanıtlamıştır. Bu sendikasyon protokolleri, düşük kaliteli bir web sunucusunun bile mesajları (potansiyel olarak) milyonlarca ayrı abone düğümüne dağıtma yeteneği karşılığında daha yüksek gecikme ve teslimat eksikliği garantilerini kabul eder.

• Disadvantages

 

Pub / sub sistemleriyle ilgili en ciddi sorunlar, ana avantajlarının bir yan etkisidir: yayıncının aboneden ayrılması.

• Message delivery issues                                

Bir pub / sub sistemi, garantili teslimat gibi belirli bir uygulamanın gerektirebileceği daha güçlü sistem özelliklerini sağlayabilmek için dikkatlice tasarlanmalıdır. 

• Bir pub / sub sistemindeki simsar, mesajları belirli bir süre için göndermek üzere tasarlanabilir, ancak daha sonra, mesajın tüm aboneler tarafından başarılı bir şekilde alındığına dair onay almış olsun ya da olmasın, teslimat girişimini durdurur. Bu şekilde tasarlanmış bir pub / sub sistemi, mesajların bu tür garantili teslimatı gerektirebilecek herhangi bir uygulamaya teslim edilmesini garanti edemez. Bu tür bir yayıncı ve abone çiftinin tasarımlarının daha sıkı bağlanması, bu tür garantili teslimatı gerçekleştirmek için (örneğin abonenin alındı ​​mesajlarını yayınlamasını zorunlu kılarak) yayın / alt mimarisinin dışında uygulanmalıdır.

• Bir pub / sub sistemindeki bir yayıncı, aslında dinlemediği halde bir abonenin dinlediğini varsayabilir. Bir fabrika, ekipmanın sorunları veya arızaları bir aboneye, bu sorunları görüntüleyen ve kaydeden bir aboneye yayınlayabileceği bir pub / sub sistemi kullanabilir. Kaydedici başarısız olursa (çökerse), ekipman sorunu yayıncıları günlük kaydedici hatasıyla ilgili bir bildirim almayacaktır ve hata mesajları pub / sub sistemindeki herhangi bir ekipman tarafından görüntülenmeyecek veya kaydedilmeyecektir. Bu aynı zamanda bir istemci / sunucu sistemi gibi alternatif mesajlaşma mimarileri için bir tasarım zorluğudur. Bir istemci / sunucu sisteminde, bir hata kaydedici başarısız olduğunda, sistem hata kaydedici (sunucu) arızasının bir göstergesini alacaktır. Bununla birlikte, istemci / sunucu sistemi, bu hatayı, yedekli günlük kaydı sunucularına çevrimiçi olarak sahip olarak veya dinamik olarak geri dönüş günlükleme sunucularını oluşturarak ele almak zorunda kalacaktır. Bu, istemci ve sunucu tasarımlarının yanı sıra bir bütün olarak istemci / sunucu mimarisine karmaşıklık katar. Bununla birlikte, bir pub / sub sistemde, sistemdeki diğer ekipmanlara herhangi bir etki yapmadan kayıt güvenilirliğini artırmak için mevcut kaydedicinin tam olarak kopyası olan yedek kayıt aboneleri sisteme eklenebilir. Bir pub / sub sistemde, garantili hata mesajı günlüğü özelliği, ekipman sorunu mesaj günlüğünün temel işlevselliğinin uygulanmasının ardından aşamalı olarak eklenebilir. 

Pub / sub modeli, az sayıda yayıncı ve abone düğümü ve düşük mesaj hacmi olan küçük ağlar için iyi ölçeklenir. Bununla birlikte, düğümlerin ve mesajların sayısı arttıkça, kararsızlık olasılığı artar ve bir pub / alt ağın maksimum ölçeklenebilirliğini sınırlar. Büyük ölçeklerdeki örnek aktarım hızı dengesizlikleri şunları içerir: 

• Yük artışları - abonenin doygun ağ verimini talep ettiği dönemler ve ardından düşük mesaj hacmi dönemleri (yetersiz kullanılan ağ bant genişliği) 

• Yavaşlamalar - giderek daha fazla uygulama sistemi kullandıkça (ayrı yayıncılarda iletişim kuruyor olsalar bile) alt kanallar) bireysel bir aboneye mesaj hacmi akışı yavaşlayacaktır

 

Aracıları (sunucular) kullanan pub / alt sistemler için, bir aracının bir aboneye mesajlar göndermesi için argüman bant içindedir ve güvenlik problemlerine tabi olabilir. Aracılar, müşteriye karşı hizmet reddi taleplerini artırarak yanlış istemciye bildirim göndererek kandırılabilir. Oluşturulan abonelikleri izlemek için kaynakları ayırdıklarından, aracıların kendileri aşırı yüklenebilir. Aracılara dayanmayan sistemlerde bile, bir abone almaya yetkili olmadığı verileri alabilir. Yetkisiz bir yayıncı, pub / sub sistemine yanlış veya zarar veren mesajlar ekleyebilir. Bu, özellikle mesajlarını yayınlayan veya çok noktaya gönderen sistemler için geçerlidir. Şifreleme (ör. Taşıma Katmanı Güvenliği (SSL / TLS)) yetkisiz erişimi engelleyebilir, ancak zarar verici mesajların yetkili yayıncılar tarafından sunulmasını engelleyemez. İstemci / sunucu sistemleri gibi pub / sub dışındaki mimariler de kötü niyetli davranan yetkili ileti göndericilerine karşı savunmasızdır.

Client–server model

İstemci-sunucu, istemciyi (genellikle bir grafik kullanıcı arayüzü-GUI) sunucudan ayıran bir ağ mimarisidir. Her bir istemci yazılımı, sunucuya ya da uygulama sunucusuna isteklerini (request) gönderir. Bir web sayfası incelenirken, bilgisayar ve web tarayıcısı istemci olarak adlandırılır. Web sayfasını oluşturan gelişmiş bilgisayarlar, veritabanları ve uygulamalar da sunucu olarak adlandırılır. Web tarayıcısı, web sitesinden bir istekte bulunur ve sunucu istenen bilgileri toplar ve onu bir web sitesi şekline getirerek web tarayıcısına geri yollar, kullanıcılar da ekranda web sitesini görmüş olur.

Bir istemci/sunucu mimarisi, ölçeklenebilir bir mimari sunmayı amaçlar. Böylece ağdaki her bir bilgisayar bir istemci ya da sunucu rolünü üstlenir. Sunucu yazılımı genelde, fakat her zaman değil, bir iş yazılımı için adanmış güçlü bir bilgisayarda çalışır. İstemci yazılımı ise genelde sıradan bir PC veya işistasyonunda çalışır. İstemciler gerek duydukları verinin pek çoğunu ya da tamamını uygulama sunucusundan isterlerler. Mesela; ayar dosyaları, stok verileri, iş uygulama yazılımları gibi.

Sunucu'nun özellikleri:

• Pasif (köle)
• İstekleri bekler
• İstek olduğunda bilgiyi sunar ve cevap yollar

İstemcinin özellikleri:

• Aktif (efendi)
• İstekleri gönderir
• Cevap dönene kadar bekler

Sunucular durumsuz (stateless) veya durumlu (stateful) olabilir. Durumsuz bir sunucu, istekler arasında bilgi tutmaz. Mesela statik HTML sayfalarını sunan bir HTTP sunucusu gibi. Fakat durumlu bir sunucu, kendisine gelen istekler arasında bilgi tutar. Bu bilgi küresel (global) veya oturum (session) bazlı olabilir. Örneğin Apache Tomcat sunucusu gibi.

İstemci ve sunucu arasındaki ilişki genelde ardışık diyagramlar (sequence diagram) ile belirlenir ve bu diyagramlar UML standardına uygun yapılır.

Bir diğer ağ mimarisi ise peer-to-peer yapılar olarak karşımıza çıkar. Burada her bir düğüm, hem istemci hem de sunucudur ve hepsi de aynı sorumluluğa sahiptirler. Hem istemci/sunucu mimarisi hem de peer-to-peer mimarisi günümüzde çok fazla kullanılmaktadır. Her ikisinin de avantaj ve dezavantajları vardır.

Genel bir istemci/sunucu mimarisinde iki adet düğüm vardır ve bu yüzden iki-katmanlı mimari olarak adlandırılır. Bazı ağlarda üç düğümlü bir yapı olabilir. Mesela islemci, uygulama sunucusu ve veritabanı sunucusundan müteşekkil bir ağda üç adet düğüm vardır ve bu yapı üç-katmanlı mimari olarak adlandırılır.

Genelde n-katmanlı ya da çok-katmanlı mimarilerde iş mantığının farklı fonksiyonları için her bir hizmetle sorumlu ayrı bir sunucu görevlendirilir. Çok-katmanlı mimarinin iki-katmanlı mimariye göre avantajı daha iyi yük dengeleme sunması ve daha çok ölçeklenebilir olmasıdır. Dezavantajları ise ağa daha fazla yük getirmesi ve programlama ve test aşamalarının daha zor gerçekleştirilmesidir.

İstemci Nedir?

İstemci (İngilizce Client), Bir ağ üzerinde, sunucu bilgisayarlardan hizmet alan kullanıcı bilgisayarlarıdır. Bilgiye erişim yetkileri sunucu tarafından belirlenir.

Değişik çeşitleri olmakla birlikte önemli sınıflaması

• Şişman/Zengin istemci (İngilizce Fat/Rich client): Yazılımın her seferinde sunucudan bütün istemcilere yüklenmesi ya da bir başka medyadan yüklenmesi gerekir. Örnek: Microsoft Outlook.
• Zayıf istemci (İngilizce Thin client): Sâdece sunumla ilgili grafik birimleri (İngilizce widget) ve onların denetim yazılımını içerir. İşle ilgili yazılım sunucudadır. Haberleşme kanalından gönderilen bilgi az olmasına dikkat edilir. Yazılımının bilgisayara yüklenmesi problemi yoktur. Zengin istemciye nazaran daha değişik bilgisayarlarda, hatta mobil gereçlerde de kullanılabilir. Örnek: J2EE/J2ME mimârîsiyle yapılmış bir sitenin istemcisi. WEB istemci-sunucu (client-server) sistemi olarak bilinir.

Middleware

İşletim sisteminden sağlananların ötesinde yazılım uygulamalarına hizmet sağlayan bilgisayar yazılımıdır. "Yazılım tutkalı" olarak tanımlanabilir. Ara yazılım, yazılım geliştiricilerin iletişim ve girdi / çıktı uygulamalarını kolaylaştırır, böylece uygulamalarının özel amacına odaklanabilirler. 1980'lerde yeni uygulamaların eski sistemlere nasıl bağlanacağı sorununa bir çözüm olarak popülerlik kazandı.

Terim, en yaygın olarak dağıtılmış uygulamalarda veri iletişimi ve yönetimini sağlayan yazılım için kullanılır. Terim, en yaygın olarak dağıtılmış uygulamalarda veri iletişimi ve yönetimini sağlayan yazılım için kullanılır. 2000 yılında bir IETF atölyesi, ara yazılımları "taşıma (yani TCP / IP üzerinden) hizmet katmanı kümesinin üzerinde ancak uygulama ortamının altında bulunan hizmetler" (yani uygulama düzeyindeki API'lerin altında) olarak tanımladı. Bu daha spesifik anlamda ara yazılım, istemci-sunucuda tire ("-") veya -to-in-peer-to-peer olarak tanımlanabilir. Ara yazılım, web sunucularını, uygulama sunucularını, içerik yönetim sistemlerini ve uygulama geliştirme ve dağıtımını destekleyen benzer araçları içerir. ObjectWeb, ara yazılımı şöyle tanımlar: "Bir ağdaki dağıtılmış bir bilgi işlem sisteminin her iki tarafında bulunan işletim sistemi ile uygulamalar arasında yer alan yazılım katmanı." Ara yazılım olarak kabul edilebilecek hizmetler arasında kurumsal uygulama entegrasyonu, veri entegrasyonu, mesaj odaklı ara yazılım (MOM), nesne istek aracıları (ORB'ler) ve kurumsal hizmet veriyolu (ESB). Veritabanı erişim hizmetleri genellikle ara yazılım olarak nitelendirilir. Bazıları dile özgü uygulamalardır ve heterojen özellikleri ve diğer ilgili iletişim özelliklerini destekler. Veritabanı yönelimli ara yazılım örnekleri arasında ODBC, JDBC ve işlem işleme monitörleri bulunur. Dağıtılmış bilgi işlem sistemi ara yazılımları, genel olarak iki kategoriye ayrılabilir: insan zamanı hizmetleri sağlayanlar (web isteği hizmeti gibi) ve makine zamanında gerçekleştirenler. Bu ikinci ara yazılım, Hizmet Kullanılabilirliği Forumu aracılığıyla bir şekilde standartlaştırılmıştır ve telekom, savunma ve havacılık endüstrilerindeki karmaşık, gömülü sistemlerde yaygın olarak kullanılmaktadır.

Ara yazılım terimi başka bağlamlarda da kullanılır. Ara yazılım bazen, bir uygulamadan donanım aygıtları veya diğer yazılımlarla ilgili ayrıntıları gizleyen bir soyutlama katmanı olan bir yazılım sürücüsüne benzer anlamda kullanılır. Android işletim sistemi, çekirdeğinde Linux çekirdeğini kullanır ve ayrıca geliştiricilerin uygulamalarına dahil ettikleri bir uygulama çerçevesi sağlar. Ek olarak Android, veri depolama, ekran görüntüsü, multimedya ve web'de gezinme gibi hizmetler sağlayan kitaplıkları içeren bir ara yazılım katmanı sağlar. Ara yazılım kitaplıkları makine diline göre derlendiğinden, hizmetler hızla yürütülür. Ara yazılım kitaplıkları ayrıca cihaza özgü işlevler de uygular, bu nedenle uygulamaların ve uygulama çerçevesinin çeşitli Android cihazlar arasındaki varyasyonlarla ilgilenmesi gerekmez. Android'in ara yazılım katmanı ayrıca ART sanal makinesini ve temel Java uygulama kitaplıklarını içerir. Ara yazılım, iki veya daha fazla API'yi ayıran ve hız sınırlama, kimlik doğrulama ve günlük kaydı gibi hizmetler sağlayan yazılımı da ifade eder. Gamebryo ve RenderWare gibi oyun motoru yazılımları, oyun geliştirmeyi basitleştirmek için birçok hizmet sundukları için bazen ara yazılım olarak tanımlanır. Simülasyon teknolojisinde, ara katman yazılımı genellikle birçok dağıtılmış simülasyon için geçerli olan yüksek seviyeli mimari (HLA) bağlamında kullanılır. Uygulama kodu ile çalışma zamanı altyapısı arasında yer alan bir yazılım katmanıdır. Ara yazılım genellikle bir işlevler kitaplığından oluşur ve bir dizi uygulamanın - HLA terminolojisindeki simülasyonlar veya federasyonların - bu işlevleri her uygulama için yeniden oluşturmak yerine ortak kitaplıktan sayfalandırmasını sağlar. Kablosuz ağ geliştiricileri, bir kablosuz sensör ağı (WSN) ile ilişkili zorlukların üstesinden gelmek için ara yazılım kullanabilir. Bir ara yazılım uygulamasının uygulanması, WSN geliştiricilerinin işletim sistemlerini ve donanımı şu anda mevcut olan çok çeşitli çeşitli uygulamalarla entegre etmelerine olanak tanır. QNX işletim sistemi, otomobillerde, uçaklarda ve diğer ortamlarda kullanılmak üzere multimedya hizmetleri sağlamak için ara yazılım sunar. Radyo frekansı tanımlama (RFID) yazılım araç takımları, gürültülü ve gereksiz ham verileri filtrelemek için ara yazılım sağlar.

Corba Nedir?

Ortak Nesne İstek Aracısı Mimarisi (CORBA), farklı platformlarda konuşlandırılan sistemlerin iletişimini kolaylaştırmak için tasarlanmış, Nesne Yönetim Grubu (OMG) tarafından tanımlanan bir standarttır. CORBA, farklı işletim sistemleri, programlama dilleri ve bilgi işlem donanımındaki sistemler arasında işbirliğine olanak tanır. CORBA, CORBA'yı kullanan sistemlerin nesne yönelimli olması gerekmese de, nesne yönelimli bir model kullanır. CORBA, dağıtılmış nesne paradigmasının bir örneğidir.

Nesne Yönetim Mimarisi Nesne Modeli ve Referans Modelinden oluşur. Nesne Modeli heterojen bir ortamda dağılmış nesnelerin nasıl tanımlanabileceğini belirler. Referans Modeli ise nesneler arası etkileşimleri tanımlar. Dolayısıyla Nesne Yönetim Mimarisi heterojen ortamlara dağılmış beraber işleyebilen dağıtık nesnelerin geliştirilmesine ve konuşlandırılmasına yardımcı olur. CORBA sayesinde programcılar kullandıkları nesnelerin hangi dilde yazıldığına, dağıtık olup olmadıklarına, işletim sistemlerine ve iletişim protokollerine bakmaksızın programları geliştirebilirler.

CORBA'nın ana bileşenleri ORB çekirdeği, OMG ara yüz dili (OMG IDL), taşınabilir nesne adaptörüdür (POA).

ORB Çekirdeği Nedir?

ORB istemci nesnelerin yarattığı istemleri sunucu nesnelere yönlendirip, sunucu nesnelerin cevaplarını istemci nesnelere iletir.

Java remote method invocation

Hesaplamada, Java Remote Method Invocation (Java RMI), serileştirilmiş Java sınıflarının ve dağıtılmış çöp toplama desteğinin (distributed garbage collection) doğrudan aktarımı için uzaktan yordam çağrılarının (Remote Procedure Calls - RPC) nesne yönelimli eşdeğeri olan uzak yöntem çağrısı gerçekleştiren bir Java API'sidir. Orijinal uygulama Java Sanal Makinesi (JVM) sınıf temsil mekanizmalarına bağlıdır ve bu nedenle yalnızca bir JVM'den diğerine çağrı yapılmasını destekler. Bu yalnızca Java uygulamasının temelini oluşturan protokol, Java Uzaktan Yöntem Protokolü (JRMP) olarak bilinir. JVM dışı bir bağlamda çalışan kodu desteklemek için programcılar daha sonra bir CORBA sürümü geliştirdiler. RMI teriminin kullanımı yalnızca programlama arayüzünü ifade edebilir veya hem API hem de JRMP, IIOP veya başka bir uygulamayı ifade edebilirken, RMI-IIOP (okuma: IIOP üzerinden RMI) özellikle işlevselliğin çoğunu yetkilendiren RMI arayüzünü belirtir. destekleyen CORBA uygulaması. Java RMI'nin temel fikri, dağıtılmış çöp toplama (DGC) protokolü ve orijinal Sun uygulamasının altında yatan mimarinin çoğu, Modula-3'ün "ağ nesneleri" özelliğinden gelir.

Orijinal RMI API'nin programcıları, HTTP aktarımı gibi farklı uygulamaları desteklemek için kodu bir şekilde genelleştirdiler. Ek olarak, CORBA'ya RMI arabirimiyle uyumlu olması için bağımsız değişkenleri "değere göre" geçirme yeteneği eklendi. Yine de, RMI-IIOP ve JRMP uygulamaları tamamen aynı arayüzlere sahip değildir. RMI işlevi java.rmi paketinde gelirken, Sun uygulamasının çoğu sun.rmi paketinde bulunur. Java 5.0'dan önceki Java sürümlerinde geliştiricilerin RMI saplamalarını rmic kullanarak ayrı bir derleme adımında derlemeleri gerektiğine dikkat edin. Java'nın 5.0 ve sonraki sürümleri artık bu adımı gerektirmemektedir.

Data Distribution Service

DDS, karmaşık ağ programlamasını basitleştiren bir ağ ara yazılımıdır. Düğümler arasında veri, olay ve komut göndermek ve almak için bir publish-subscribe olma modeli uygular. Bilgi üreten node'lar (publishers) "topics" (ör. Sıcaklık, konum, basınç) oluşturur ve "samples" yayınlar. DDS, sample'ları o publish ile ilgilendiğini beyan eden subscriberlara ulaştırır. 

DDS aktarım işlerini yönetir: mesaj adresleme, veri sıralama ve ayırma (böylece subscriberlar publisherlardan farklı platformlarda olabilir), teslimat, akış kontrolü, yeniden denemeler vb. Herhangi bir düğüm bir yayıncı, abone veya aynı anda her ikisi olabilir. 

DDS publish-subscribe olma modeli, dağıtılmış uygulamalar için karmaşık ağ programlamasını neredeyse tamamen ortadan kaldırır. 

DDS, basic publish-subscribe olma modelinin ötesine geçen mekanizmaları destekler. Temel fayda, iletişimleri için DDS kullanan uygulamaların ayrıştırılmış olmasıdır. . Karşılıklı etkileşimlerini ele almak için çok az tasarım zamanı harcanması gerekiyor. Özellikle, uygulamalar, varlıkları veya konumları dahil olmak üzere diğer katılan uygulamalar hakkında asla bilgiye ihtiyaç duymaz. DDS, aşağıdakiler dahil olmak üzere kullanıcı uygulamalarından müdahale gerektirmeden mesaj teslimini şeffaf bir şekilde yönetir:

• mesajları kimin alacağının belirlenmesi

• alıcıların bulunduğu yer

• mesajlar teslim edilemezse ne olur

DDS, kullanıcının keşif ve davranış mekanizmalarını önceden yapılandırmak için hizmet kalitesi (QoS) parametrelerini belirlemesine olanak tanır. Mesajları isimsiz olarak değiş tokuş ederek, DDS dağıtılmış uygulamaları basitleştirir ve modüler, iyi yapılandırılmış programları teşvik eder. DDS ayrıca, birincil başarısızlık durumunda çalışırken değiştirilen yedek yayıncıları otomatik olarak işler. Aboneler her zaman en yüksek önceliğe sahip örneği alır veriler hala geçerlidir (yani, yayıncı tarafından belirtilen geçerlilik süresi sona ermemiştir). O da kurtarıldığında otomatik olarak birincil konuma geri döner.

DDS birlikte çalışabilirlik gösterimi, aşağıdakiler gibi senaryolar kullandı: 

• İnternet Protokolü (IP) kullanarak ağa temel bağlantı 

• Yayıncıların ve abonelerin keşfi Hizmet kalitesi (QoS) 

• Talep eden ve sağlayıcı arasındaki uyumluluk 

• Gecikmeye toleranslı ağ oluşturma 

• Birden çok konu ve konuların münhasır sahiplikleri 

• İçerik zaman ve coğrafi bilgiler dahil olmak üzere konu verilerinin filtrelenmesi

mqtt gibi merkezde bir broker olması gerekmez. dağıtık bir mimaridir. dds node'ları doğrudan peer-to-peer tarzında udp multicast kullanarak haberleşir. merkezi network yönetim ihtiyacını ortadan kaldıran ve daha hızlı haberleşmeyi mümkün kılan bu yöntem ile milisaniyenin de altında haberleşebilir. bu yüksek hız kapasitesi dds protokolünü m2m haberleşme ihtiyaçlarında tercih edilir duruma getirmektedir.

Priority queue

Bilgisayar biliminde, bir öncelik sırası, her bir öğenin ek olarak kendisiyle ilişkili bir "önceliğe" sahip olduğu normal kuyruğa veya yığın veri yapısına benzer soyut bir veri türüdür. Öncelik kuyruğunda, yüksek önceliğe sahip bir öğe, düşük önceliğe sahip bir öğeden önce sunulur. Bazı uygulamalarda iki eleman aynı önceliğe sahipse sıralanma sırasına göre sunulurlar, diğer uygulamalarda ise aynı önceliğe sahip elemanların sıralaması tanımsızdır. Öncelik kuyrukları genellikle yığınlarla uygulanırken, kavramsal olarak yığınlardan farklıdır. Öncelik kuyruğu, "liste" veya "harita" gibi bir kavramdır; tıpkı bir listenin bağlantılı bir liste veya bir dizi ile uygulanabilmesi gibi, bir öncelik kuyruğu da bir yığınla veya sırasız dizi gibi çeşitli diğer yöntemlerle uygulanabilir.

Öncelik kuyruğu en azından aşağıdaki işlemleri desteklemelidir: 

• is_empty: kuyruğun hiç elemanı olup olmadığını kontrol edin. 

• insert_with_priority: kuyruğa ilişkili bir önceliğe sahip bir öğe ekleyin. 

• pull_highest_priority_element: en yüksek önceliğe sahip öğeyi kuyruktan kaldırır ve döndürür. Bu aynı zamanda "pop_element (Kapalı)", "get_maximum_element" veya "get_front (çoğu) _element" olarak da bilinir. Bazı konvansiyonlar, düşük değerlerin daha yüksek öncelik olduğunu düşünerek öncelik sırasını tersine çevirir, bu nedenle bu "get_minimum_element" olarak da bilinir ve literatürde genellikle "get-min" olarak anılır. Bunun yerine bu, "pull_highest_priority_element" oluşturmak için birleştirilebilen ayrı "peek_at_highest_priority_element" ve "delete_element" fonksiyonları olarak belirtilebilir.

 Ek olarak, en yüksek öncelikli öğeyi döndüren ancak kuyruğu değiştirmeyen gözetleme (bu bağlamda genellikle bul-maks veya bul-min olarak adlandırılır) çok sık uygulanır ve neredeyse her zaman Ozamanında çalıştırılır. Bu işlem ve O performansı, birçok öncelik kuyruğu uygulaması için çok önemlidir. Daha gelişmiş uygulamalar, pull_lowest_priority_element, ilk birkaç en yüksek veya en düşük öncelikli öğeyi inceleme, kuyruğu temizleme, kuyruğun alt kümelerini temizleme, bir toplu ekleme gerçekleştirme, iki veya daha fazla kuyruğu bir araya getirme, önceliği artırma gibi daha karmaşık işlemleri destekleyebilir Bir öncelik kuyruğunu değiştirilmiş bir kuyruk olarak düşünülebilir, ancak bir sonraki öğe kuyruktan çıktığında, ilk önce en yüksek öncelikli öğe alınır. Yığınlar ve kuyruklar, belirli türde öncelik kuyrukları olarak modellenebilir. Bir hatırlatma olarak, yığınların ve kuyrukların nasıl davrandığı şu şekildedir: 

• stack - öğeler son giren ilk çıkar sırasında (ör. Kağıt yığını) 

• queue - öğeler ilk giren ilk çıkar sırasında çekilir (ör. , kafeteryada bir çizgi) 

Bir yığında, eklenen her bir elemanın önceliği monoton bir şekilde artmaktadır; bu nedenle, eklenen son öğe her zaman ilk alınan öğedir. Bir kuyrukta, eklenen her öğenin önceliği monoton bir şekilde azalır; bu nedenle, eklenen ilk öğe her zaman ilk alınır.

RSS

RSS, genellikle haber sağlayıcıları, bloglar ve podcastlar tarafından kullanılan, yeni eklenen içeriğin kolaylıkla takip edilmesini sağlayan bir web sayfası bildirimcisidir. Kullandığı dosya biçimleri .rss ve .xml'dir.

İnternet kullanıcısı RSS teknolojisi ile düzenli olarak içerik sunan sitelere abone olabilir ve çeşitli RSS istemcileri sayesinde içeriği takip edebilir. Site yöneticisi veya sahibi bu hizmeti sunmak için bir takım teknik düzenlemeler yapmalı ve uygun formatta XML'i RSS istemcisi talep ettiğinde göndermelidir.

Multi-RSS reader

Multi-RSS reader, İnternet haber taşımacılığın neredeyse son noktasıdır, çünkü birçok alt site, haber kaynağı olarak kullandığı siteleri kaynakça olarak göstermektedir. Ayrıca aldığı haberleri basit bir harmanlama yöntemi ile kendi sitesine haber yapar. "Multi-RSS reader" da ise bu işlemi otomatik bir şekilde PHP veya ASP desteği olan her site sahibi yapabilir.

Datagram

Bir datagram (veri birimi), paket anahtarlamalı bir ağ ile ilişkili temel bir aktarım birimidir. Datagramlar tipik olarak başlık ve payload bölümlerinde yapılandırılır. Datagramlar, paket anahtarlamalı bir ağ üzerinden bağlantısız bir iletişim hizmeti sağlar. Datagramların teslimi, varış zamanı ve varış sırasının ağ tarafından garanti edilmesi gerekmez.

Datagram varış saati, düzeni ve teslimi garanti edilemeyen paket anahtarlamalı bir ağ ile ilişkilendirilmiş temel bir aktarım ünitesidir. Datagramlarda başlıkta datagramı internet üzerinde yönlendirebilmek için gerekli bilgiler bulunur. Hedef ve kaynak adresleri datagram başlığında birer alan olarak bulunur. Eğer bir datagram aynı ağ içerisinde bulunan bir bilgisayara gönderilmediyse, ağ geçidi üzerinden belirtilen noktaya ulaşmak üzere gönderilir.

Datagramda taşınan veri miktarı sabit değildir. Kullanım amacına göre veri miktarını gönderen belirler. Eğer datagramın boyutu MTU' yu aşarsa veri parçalanır. Orijinal yani parçalanmamış olan datagramın Fragment Offset kısmı 0' dır ve parçalandıkça Fragment Offset değeri artar. Bir datagram en fazla 8192 parçaya ayrılır. Veri karşı tarafta bu numaraya göre birleştirilir.

Genelde datagram ve paket kavramları aynı anlamda kullanılsa da aralarında farklar vardır. İlk olarak datagram kavramı genelde güvenilmez bir servisin paketleri için ayrılırken, paket kavramı paket olarak biçimlendirilmiş herhangi bir mesaj için geçerlidir. Datagramınn karşı tarafa iletilip iletilmediği güvenilmeyen servislerde kullanıcıya bildirilmez. Örnek olarak, IP kendisi güvenilmez bir hizmet vermektedir ve IP üzerinden UDP de güvenilmez servislerden birisidir. Bu yüzden UDP paketleri genelde datagram olarak adlandırılır. İkinci olarak, eğer bir datagram parçalanırsa, datagramın parçaları artık datagram olarak değil paket olarak anılacaktır.

MTU (Maksimum İletim Birimi)

Her data-link katman protokolünün kendi frame formatları vardır. Veri alanlarının maksimum boyutu tanımlanan formattaki alanlardan biridir. Fiziksel bir ağın çerçevesindeki veri bölümünde taşıyabileceği en fazla veri miktarına MTU (Maksimum İletim Birimi) denir. MTU bir Data-Link protokolünün sarmalladığı, paketleyebildiği byte'ların maksimum sayısıdır. MTU değerleri ağdan ağa değişebilir.

Ağ türleri için MTU değerleri

Bir veri paketinin maksimum boyutu 65,535 byte dir. Eğer gönderilen veri paketinin boyutu gönderilen ağın MTU (Maksimum İletim Birimi) degerinden daha büyük ise bu veri paketi daha küçük birimlere bölünerek gönderilir. Bu birimlere de Fragmentation denir. Bu bölünme işlemi yönlendiriciler tarafından yürütülür. Yönlenledirici gelen paketi gideceği ağın türünü göre belirleyip, o ağın MTU değerine göre daha küçük birimlere ayırarak gönderir. Bu birimlere ayrılma işleminde ağların bir sorumlulğu yoktur. Veri paketlerinin çok fazla sayıda fragmentation lara bölmek verimsizliğe neden olabilir. Bu fragmentationların orginal pakete dönüştürülmesi ayrıca bir zaman alacaktır Bu ağdaki hızın düşmesine neden olur. Bu nedenle MTU 'nun iyi ayarlanması gerekir. Ağlara en geniş MTU'ları desteklemek için bazı öncelikler verilmiştir. Özellikle de araştırmayla ilgili olan ağlara. Ethernet ağları için MTU değeri 1500 Byte’dır. Bu demek oluyorki bir Ethernet ağa giren bir paketin boyutu maksimum 1500 byte olabilir.

UDP

UDP (User Datagram Protocol - Kullanıcı Veribloğu İletişim Kuralları), TCP/IP protokol takımının iki aktarım katmanı protokolünden birisidir. Verileri bağlantı kurmadan yollar.

Gelişmiş bilgisayar ağlarında paket anahtarlı bilgisayar iletişiminde bir datagram modu oluşturabilmek için UDP protokolü yazılmıştır. Bu protokol minimum protokol mekanizmasıyla bir uygulama programından diğerine mesaj göndermek için bir prosedür içerir. Bu protokol 'transaction' yönlendirmelidir. Paketin teslim garantisini isteyen uygulamalar TCP protokolünü kullanır.

• Geniş alan ağlarında (WAN) ses ve görüntü aktarımı gibi gerçek zamanlı veri aktarımlarında UDP kullanılır.
• UDP bağlantı kurulum işlemlerini,akış kontrolü ve tekrar iletim işlemlerini yapmayarak veri iletim süresini en aza indirir.
• UDP ve TCP aynı iletişim yolunu kullandıklarında UDP ile yapılan geçek zamanlı veri transferinin servis kalitesi TCP'nin oluşturduğu yüksek veri trafiği nedeniyle azalır.

UDP'yi kullanan protokollerden bazıları DNS, TFTP, ve SNMP protokolleridir. Uygulama programcıları birçok zaman UDP'yi TCP'ye tercih eder, zira UDP ağ üzerinde fazla bant genişliği kaplamaz.

UDP güvenilir olmayan bir aktarım protokolüdür. Ağ üzerinden paketi gönderir ama gidip gitmediğini takip etmez ve paketin yerine ulaşıp ulaşmayacağına onay verme yetkisi yoktur. UDP üzerinden güvenilir şekilde veri göndermek isteyen bir uygulama bunu kendi yöntemleriyle yapmak zorundadır.

TCP: UDP 'den daha yavaştır,çünkü verinin karşı tarafa ulaşıp ulaşmadığını kontrol eder. 

UDP: Ses ve video gönderiminde kullanılır. TCP'ye göre daha hızlıdır fakat güvenli değildir. Veri ismine datagram denilir.     
        Datagramın segmentten  farkı ise içerisinde sıra numarasının bulunmamasıdır. 

IP multicast

IP multicast, İnternet Protokolü (IP) datagram tek bir iletimde bir grup ilgili alıcıya gönderme yöntemidir. IP'ye özgü multicast biçimidir ve akış ortamı ve diğer ağ uygulamaları için kullanılır. IPv4 ve IPv6'da özel olarak ayrılmış multicast adres blokları kullanır. 

IP multicast, bir ağdaki bir IP altyapısı üzerinden bire çok ve çoktan çoğa gerçek zamanlı iletişim için bir tekniktir. Ne bir alıcının kimliği hakkında ön bilgi ne de alıcıların sayısı hakkında önceden bilgi gerektirmeden daha büyük bir alıcı popülasyonuna ölçeklenir. Çok noktaya yayın, çok sayıda alıcıya teslim edilmesi gerekse bile kaynağın bir paketi yalnızca bir kez göndermesini gerektirerek ağ altyapısını verimli bir şekilde kullanır. Ağdaki düğümler (tipik olarak ağ anahtarları ve yönlendiriciler), mesajların ağın her bir bağlantısı üzerinden yalnızca bir kez gönderileceği şekilde birden fazla alıcıya ulaşmak için paketi kopyalamaya özen gösterir.

Introduction to Node-RED

Node red, IBM tarafından geliştirilen ve Node.js'de yazılan Açık Kaynaklı akış tabanlı bir araç ve IOT platformu ve Dashboard'dur.

Node-RED, bir web arayüzü kullanarak black box functionlarınıi (nodes) bir araya getirerek uygulamaları kolayca yapmanızı sağlar ve varsa çok az programlama bilgisi gerektirir.

Creating Flows- Node-Red Admin Basics

Node-Red'i yönetmek için yönetici url'sine gitmeniz gerekecek. Yönetici url'si, makine adı veya IP adresi ve ardından port number. Örneğin, 127.0.0.1:1880/ tarayıcıyı node red ile aynı makinelerde çalıştırıyorsanız. localhost: 1880 / - steve-laptop: 1880 / uzak bir makinede node-red çalıştırırken 192.168.1.154:1880/.

Raspberry Pi'de node-red ve akış oluşturmak için Windows 10 kullanırken oluşan bir örnek.

Using The Node Red Admin User Interface (UI)

Node-RED admin ekranını ilk kez açtığınızda, yukarıdaki önceki ekran resminde gösterildiği gibi boş bir çalışma alanıyla başlamalısınız. 

Varsayılan görünüm, solda nodes, ortada akışlar çalışma alanı ve sağda üçüncü bir sütun bulunan üç sütunlu bir düzendir. 

Üçüncü sütun veya çıktı bölmesinin iki veya üç sekmesi vardır - info, debug ve dashboard (yüklüyse).

Not: 0.19 ve üzeri sürümlerde artık 5 sekme bulunmaktadır. Bunlardan ikisi, yapılandırma sekmesi ve bağlam sekmesidir.

Node-Red Flows

Akış, birbirine bağlanan ve bir uygulama veya program olarak işlev gören bir düğümler koleksiyonudur. 

Nodered workspace aynı nodejs olay döngüsünü paylaşan birden çok akışı destekler.

Node-Red Nodes

Nodes, node-redin temel yapı taşıdır. 

Bir node, mesajları işleyen etkili bir yazılım bloğudur. 

Bir node, mesajların düğümler arasında geçirilmesini sağlayan giriş ve çıkışlara sahip olabilir. 

Bir giriş birden çok nodedan gelen bağlantıları kabul edebilir ve bir çıkış birden çok nodes çıktı verebilir.

Sol bölmedeki düğümler kategoriler halinde düzenlenmiştir. Node-red bir kurulum, core nodes içerecektir ve nodes gruplar halinde düzenlenmiştir. Bir giriş grubu çıkış grubu vardır, functional nodes, dashboard veya ekran nodes. Yeni nodes kurulduğunda diğer gruplar oluşturulabilir. İşte temel bir akışın nasıl oluşturulacağını gösteren hızlı bir genel bakış videosu.

Node-RED eğitimi bu adresten devam etmektedir;

http://www.steves-internet-guide.com/node-red-admin-basics/

http://www.steves-internet-guide.com/install-mosca-mqtt-broker-node-red/

Bir Örnek

Windows, Mac, Linux, Debian, Raspberry Pi ve Ubuntu kurulumları;

https://mosquitto.org/download/

Windows'da cmd de mesaj gönderme

https://www.youtube.com/watch?v=wKgXQwY7oCU&feature=youtu.be

Bir ikili paket kurduysanız, broker otomatik olarak başlatılmış olması gerekir. Değilse, temel bir yapılandırma ile başlatılabilir:

mosquitto

Ardından bir topic subscribe olmak için mosquitto_sub kullanın:

mosquitto_sub -t 'test/topic' -v

Ve bir mesaj yayınlamak için:

mosquitto_pub -t 'test/topic' -m 'hello world'

https://randomnerdtutorials.com/esp8266-nodemcu-mqtt-publish-dht11-dht22-arduino/

ESP 8266 ISI SENSÖRÜ PROJESİ

#include "DHT.h"

#include <ESP8266WiFi.h>

#include <Ticker.h>

#include <AsyncMqttClient.h>

#define WIFI_SSID "Modem ID"

#define WIFI_PASSWORD "Modem Şifresi"

#define MQTT_HOST IPAddress(192, 168, 1, 102)

#define MQTT_PORT 1883

#define MQTT_PUB_TEMP "esp/dht/temperature"

#define MQTT_PUB_HUM "esp/dht/humidity"

#define DHTPIN 14

#define DHTTYPE DHT22   // DHT 22  (AM2302), AM2321

DHT dht(DHTPIN, DHTTYPE);

float temp;

float hum;

AsyncMqttClient mqttClient;

Ticker mqttReconnectTimer;

WiFiEventHandler wifiConnectHandler;

WiFiEventHandler wifiDisconnectHandler;

Ticker wifiReconnectTimer;

unsigned long previousMillis = 0;   

const long interval = 10000;  

void connectToWifi() {

  Serial.println("Connecting to Wi-Fi...");

  WiFi.begin(WIFI_SSID, WIFI_PASSWORD);

}

void onWifiConnect(const WiFiEventStationModeGotIP& event) {

  Serial.println("Connected to Wi-Fi.");

  connectToMqtt();

}

void onWifiDisconnect(const WiFiEventStationModeDisconnected& event) {

  Serial.println("Disconnected from Wi-Fi.");

  mqttReconnectTimer.detach(); // ensure we don't reconnect to MQTT while reconnecting to Wi-Fi

  wifiReconnectTimer.once(2, connectToWifi);

}

void connectToMqtt() {

  Serial.println("Connecting to MQTT...");

  mqttClient.connect();

}

void onMqttConnect(bool sessionPresent) {

  Serial.println("Connected to MQTT.");

  Serial.print("Session present: ");

  Serial.println(sessionPresent);

}

void onMqttDisconnect(AsyncMqttClientDisconnectReason reason) {

  Serial.println("Disconnected from MQTT.");

  if (WiFi.isConnected()) {

    mqttReconnectTimer.once(2, connectToMqtt);

  }

}

/*void onMqttSubscribe(uint16_t packetId, uint8_t qos) {

  Serial.println("Subscribe acknowledged.");

  Serial.print("  packetId: ");

  Serial.println(packetId);

  Serial.print("  qos: ");

  Serial.println(qos);

}

void onMqttUnsubscribe(uint16_t packetId) {

  Serial.println("Unsubscribe acknowledged.");

  Serial.print("  packetId: ");

  Serial.println(packetId);

}*/

void onMqttPublish(uint16_t packetId) {

  Serial.print("Publish acknowledged.");

  Serial.print("  packetId: ");

  Serial.println(packetId);

}

void setup() {

  Serial.begin(115200);

  Serial.println();

  dht.begin();

  

  wifiConnectHandler = WiFi.onStationModeGotIP(onWifiConnect);

  wifiDisconnectHandler = WiFi.onStationModeDisconnected(onWifiDisconnect);

  mqttClient.onConnect(onMqttConnect);

  mqttClient.onDisconnect(onMqttDisconnect);

  //mqttClient.onSubscribe(onMqttSubscribe);

  //mqttClient.onUnsubscribe(onMqttUnsubscribe);

  mqttClient.onPublish(onMqttPublish);

  mqttClient.setServer(MQTT_HOST, MQTT_PORT);

  // If your broker requires authentication (username and password), set them below

  //mqttClient.setCredentials("REPlACE_WITH_YOUR_USER", "REPLACE_WITH_YOUR_PASSWORD");

  

  connectToWifi();

}

void loop() {

  unsigned long currentMillis = millis();

  // Every X number of seconds (interval = 10 seconds) 

  // it publishes a new MQTT message

  if (currentMillis - previousMillis >= interval) {

    // Save the last time a new reading was published

    previousMillis = currentMillis;

    // New DHT sensor readings

    hum = dht.readHumidity();

    // Read temperature as Celsius (the default)

    temp = dht.readTemperature();

    // Read temperature as Fahrenheit (isFahrenheit = true)

    //temp = dht.readTemperature(true);

    

    // Publish an MQTT message on topic esp/dht/temperature

    uint16_t packetIdPub1 = mqttClient.publish(MQTT_PUB_TEMP, 1, true, String(temp).c_str());                            

    Serial.printf("Publishing on topic %s at QoS 1, packetId: %i ", MQTT_PUB_TEMP, packetIdPub1);

    Serial.printf("Message: %.2f \n", temp);

    // Publish an MQTT message on topic esp/dht/humidity

    uint16_t packetIdPub2 = mqttClient.publish(MQTT_PUB_HUM, 1, true, String(hum).c_str());                            

    Serial.printf("Publishing on topic %s at QoS 1, packetId %i: ", MQTT_PUB_HUM, packetIdPub2);

    Serial.printf("Message: %.2f \n", hum);

  }

}

Bu sayfa WIKIPEDIA, steves-internet-guide.com, ibm.com,  randomnerdtutorials.com ve ekşi sözlükten faydalanılarak hazırlanmıştır.