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?
Dikkat Edilmesi Gereken Önemli Noktalar
- İstemcilerin e-posta sistemlerindeki gibi adresleri yoktur ve istemcilere mesaj gönderilmez.
- Mesajlar, bir konu hakkında bir brokera yayınlanır.
- Bir MQTT aracısının işi, mesajları konuya göre filtrelemek ve ardından bunları abonelere dağıtmaktır.
- Bir client, aynı brokerda o konuya abone olarak bu mesajları alabilir
- Bir yayıncı ile abone arasında doğrudan bir bağlantı yoktur.
- Tüm clients yayınlayabilir ve abone olabilir.
- 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.
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.
Wildcard character
Subscribing to Topics
- # (karma karakter) - çok seviyeli joker karakter
- + (artı karakter) - tek seviyeli joker karakter
Topic naming Examples:
Valid Topic subscriptions
- /
- /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
When are Topics Created
- 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
$SYS/MQ branch of queue manager topic tree
Topic trees
- Birden fazla konuya abone olmak.
- Güvenlik politikalarının oluşturulması.
- "USA"
- "USA/Alabama"
- "USA/Alaska"
- "USA/Alabama/Auburn"
- "USA/Alabama/Mobile"
- "USA/Alabama/Montgomery"
- "USA/Alaska/Juneau"
- 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?
- 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.
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?
- Mesaj konusu
- Mesaj QOS
- Mesajın saklanıp saklanmayacağı. - Tutma Bayrağı (retain flag)
https://tr.wikipedia.org/wiki/%C4%B0nternet_ileti%C5%9Fim_kurallar%C4%B1_dizisi
- 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 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.
- 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.
- 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
Disadvantages
Disadvantages
Message delivery issues
Message delivery issues
- 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.
- 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
Client–server model
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?
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
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.
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.
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
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:
mosquittoArdından bir topic subscribe olmak için mosquitto_sub kullanın:
mosquitto_sub -t 'test/topic' -vVe 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.
