Ağ iletişimlerinde temel yenilikçi çözümlerin standartlaştırılması
Standardization of basic innovative solutions in network communications
Yazar: MUHAMMED SALİH KALKAN
Danışman: DR. ÖĞR. ÜYESİ GÖKHAN SEÇİNTİ
İstanbul Teknik Üniversitesi / Lisansüstü Eğitim Enstitüsü / Bilgisayar Mühendisliği Ana Bilim Dalı / Bilgisayar Mühendisliği Bilim Dalı
Derece: Yüksek Lisans, 2023
Konu: Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrol = Computer Engineering and Computer Science and Control

Özet:
Ağ iletişimlerindeki problemler oldukça eskiye dayanır. Bu problemleri çözmek için birçok çalışma yapılmıştır. Bu çalışmalar, günümüzde OSI model olarak adlandırdığımız, katmanlı bir iletişim yapısını ortaya çıkarmıştır. Bu katmanlardan birisi uygulama katmanıdır. Mesajlaşma ile ilgili problemler, bu katmana aittir. Dolayısıyla, mesajlaşma ile ilgili özellikler bu katmanda kullanılır. Bazı mesajlaşma özelliklerini standartlaştırmak için, bazı uygulama katmanı protokoller oluşturulmuştur. AMQP, MQTT vb. protokoller, uygulama katmanı protokollerine örnektir. Bu araştırmada da, temel yenilikçi çözümler uygulama katmanında değerlendirilir. 

Uygulamalar, mesajlaşma ile ilgili sorunları farklı şekillerde çözmektedir. Bazı özellikler uygulama koduyla, bazıları kütüphanelerle ve bazıları da protokollerle standardize edilerek sağlanır. Uygulama koduna eklenen mesajlaşma özelliklerinin her uygulama için tekrar tekrar yazılması gerekmektedir. Her uygulama için gerekli mesajlaşma özelliklerinin kodlarının tekrar tekrar yazılması, iş gücü kaybına, hata olasılığına, kodun her seferinde artan karmaşıklığına neden olur. Mesajlaşma sorunlarını kütüphane kodları ile çözmek, bu kütüphanenin diğer tüm uç noktalarla paylaşılmasını gerekli kılar. Bu nedenle mesajlaşma özelliklerinin bir protokol ile standardize edilmesi gerekmektedir. Bu çalışmada, yerel ağlarda ve IoT'de kullanılmak üzere temel yenilikçi özellikleri standartlaştırarak iş gücü kazancı sağlanması, uygulama kodunun karmaşıklığının azaltılması, çözümlerin her uç nokta için ortaklanması amaçlanmıştır. Bir protokol standardı oluşturmak için, protokollere ait özelliklerin arkaplan bilgisine ihtiyaç vardır. Bu yüzden öncelikle, ikili-metin protokoller, iletişim modelleri, merkezi-merkeziyetsiz yaklaşımlar gibi arkaplan bilgileri incelenmiştir.

İkili protokoller, verileri ikili olarak ileten protokollerdir. Metin protokolleri, verileri Unicode veya ASCII olarak ileten protokollerdir. İkili protokoller, verilerin daha küçük boyutlarda iletilmesini sağladığı için performans açısından daha iyidir. Metin protokolleri, verileri daha büyük boyutlarda iletmesine karşın ikili protokollere kıyasla kolayca hata ayıklanabilir ve veriler insan tarafından okunabilirdir. Hem yüksek performans özelliği, hem verinin okunabilir olma özelliğine sahip olmak için, izleyici uç noktanın, ikili verilerin metin karşılıklarını bilmesi gerekir. Ayrıca ikili protokoller için bayt sırası (endianness) önemliyken, metin protokolleri için bayt sırası önemli değildir. Cihazın endianness tipi little-endian veya big-endian olabilir. İkili protokollerde, farklı endianness'e sahip iki cihaz iletişim kurduğunda, verilerin serileştirilmesinden önce ve verinin serisini çözümleme işleminden önce verilerin bayt adreslemesi tersine çevrilmelidir. Bu problemlerin çözümleri, uygulama katmanında standartlaştırılırsa, geliştiricilerin bu problemleri tekrar tekrar çözmeye çalışmasına gerek kalmaz.

Sunucu-istemci modeli, birden fazla istemci uç noktasının tek bir sunucu uç noktasından hizmet talep ettiği bir modeldir. Yayınla-abone ol modeli, yayıncı ve abone uç noktalarının merkezi bir mesaj yönelimli ara yazılım aracılığıyla mesaj iletimlerini sağlayan bir modeldir. Uç noktalar, konulara abone olur veya mesajları yayınlar. Mesaj aracısı, yayınlanan mesajları, mesaja abone olan uç noktalara iletir. Mesaj aracısı, gevşek bağlantı ve esneklik sağlar. Uç noktalar, birbirlerinin varlığından bağımsız olarak mesajlaşmaya devam eder. Transformatörler ve filtreler, mesaj aracısı üzerinde çalışabilir. Gevşek bağlantı aynı zamanda bir dezavantajdır. Yayıncı uç noktaları, abone uç noktalarının iletişim kurup kurmadığından emin olamaz. Yayıncılar ve aboneler arttıkça, mesaj aracısını aşırı yükleyebilir. Mesaj aracısı, merkezi olduğundan darboğaza neden olabilir. Bu, yatay ölçeklenebilirliği sınırlar. İletileri doğrudan hedef uç noktalara iletmek yerine önce mesaj aracısına iletmek gecikmeyi artırır. Mesaj aracısı ile gelen bu problemlerden kurtulmak için, merkezi olmayan yayınla-abone ol modeline ihtiyaç vardır.

Mesajlaşan uç noktalar için en büyük sorunlardan biri, uç noktalardan birinde mesaj yapılarının güncel olmaması veya yanlış implement edilmiş olmasıdır. Mevcut mesajlaşma protokolleri için, bir bağlantıdaki uç noktaların mesaj yapılarının uyumluluğunu kontrol etmeye yönelik standart bir yaklaşım yoktur. 

Bir iletişimde giden ve gelen mesajları izlemek kritik olabilir. Mesaj gönderme noktadan noktaya ise, üçüncü bir izleme uzak uç noktası iletişime dahil edilemez. IP paket başlığındaki hedef IP adresi, noktadan noktaya iletişim için tek bir cihaza ait olmalıdır. Bu problem, uygulama katmanında üçüncü uzak noktalara yönlendirme yapılarak çözülebilir.

Birçok uygulama katmanı protokolü, taşıma katmanındaki bir protokole bağlıdır. Bu da gelecek kullanımları kısıtlayabilir. Örneğin, QUIC protokolü, TCP'nin yerini aldığını varsayalım. Artık TCP implementasyonlarının ortadan kalktığını varsayalım. Bu durumda, düzinelerce TCP tabanlı protokolün yeni bir sürümle QUIC tabanlı olması gerekecektir. Bu yüzden alt protokollerden soyutlanmak, gelecek kullanımlar için önemlidir. 

Birden çok protokol kullanmak için birden çok iletişim arabirimi oluşturulmalıdır. Ancak bir protokol, çoklu alt katman protokol ile kullanılabilir olma özelliğine sahip ise, tek bir iletişim arabirimi yeterli olacaktır.

Bu çalışmada, mevcut protokollerin, bu sorunları ne kadar çözdüğüne dair veriler toplandı. Bu sorunları çözen özellikler ile mevcut protokolleri kullanarak bir tablo oluşturuldu. Diğer uygulama katmanı protokollerinin tüm bu özellikleri desteklemediği görülmektedir. Bu nedenle, bu özellikleri sağlayan yeni bir protokole ihtiyaç vardır. Bu protokolün adı mesajlaşma kontrol protokolüdür (MCP). MCP'nin hedeflediği kullanım alanı daha çok yerel ağ iletişimleridir. MCP, daha çok yerel ağ iletişimleri, asenkron iletişimler, non-stateless iletişimler ve gömülü sistemlerde kullanılabilecek özelliklere yoğunlaşmıştır.

MCP'nin alt katman protokollerinden bağımsız olması için ve çoklu alt protokollerle kullanılabilmesi için MCP'nin iki bileşeni vardır: MCP Adaptörü ve iletişim arayüzü. MCP Adaptörü, MCP'nin ön koşullarını sağlamak için gereklidir. Alt protokollerin işlevlerini kullanmak için iletişim arayüzü gereklidir. Böylece MCP alt protokollerden bağımsız hale gelir ve birden fazla alt protokol ile kullanılabilir.

MCP'de iki mesaj sınıfı vardır: MCP Standart Mesajı, MCP Uygulama Mesajı. MCP, MCP standart mesajları olarak adlandırılan, uygulama kodundan bağımsız yerleşik mesajlara sahiptir. 5 tür standart mesaj vardır: El Sıkışma Mesajı, Kalp Atışı Mesajı, Rol Başvuru Mesajı, Abone Olma Mesajı, Abonelikten Çıkma Mesajı. İstemciler, kullanıcı tanımlı mesajların yapılarını el sıkışma istek mesajı ile JSON formatında gönderir. Böylece uç noktaların mesaj uyumlulukları kontrol edilir. Sunucu, endianness tipini el sıkışma yanıt mesajı ile gönderir. İstemci, sunucunun endianness tipini öğrenir. İstemci ve sunucunun endianness türleri farklıysa, istemci verilerin bayt sıralamasını otomatik olarak değiştirir. Bağlantının canlı olup olmadığını tespit etmek için periyodik olarak kalp atışı mesajı gönderilir. Bir istemci, bir mesaja abone olmak için ya da bir mesajın aboneliğinden çıkmak için Abone Olma Mesajı ve Abonelikten Çıkma Mesajını kullanır.

MCP uygulama mesajları, uygulama kodunda tanımlanan mesajlardır. Dört tür uygulama mesajı vardır: İstek-Yanıt Mesajı, Olay Mesajı, Başlangıç Mesajı, Rapor Mesajı. İstek-yanıt mesajları için, yalnızca ilgili istek mesajı alındığında ilgili yanıt mesajı oluşturularak iletişim sağlanır. Olay mesajları, bir olayın tetiklenmesi ile iletilir. Olay mesajları tüm bağlı abone istemcilerine gönderilir. Başlangıç mesajı, aslında bağlantı kurulduğunda tetiklenen bir olay mesajıdır. Rapor mesajı, aslında zamana göre tetiklenen bir olay mesajıdır.

Yetkilendirme için rol tabanlı erişim kontrol yöntemi kullanılır. İstemcilerin MCP bağlantısında rolleri vardır. İstemcilerin rolleri, mesajlaşma arayüzündeki mesajların erişilebilirliğini belirler. Sunucu, her mesaj için hangi istemci rollerinin erişebileceğini belirler. Rollerin istemcilere atanmasını ise, admin rolündeki istemci gerçekleştirir. Noktadan noktaya iletişimde mesajları izlemek isteyen istemcilerin rolü, izleme rolüdür. İzleyici rolü, iletilerin erişilebilirliğinden bağımsızdır. Noktadan noktaya iletişimdeki tüm mesajlar monitör istemcisine iletilir. İzleme istemcisi, iletişime katılmak için bir bağlantı isteği gönderir. Monitör, bağlantı kurma aşamasında el sıkışma mesajı ile mesaj yapılarını alır ve iletişimdeki ikili verilerin metin karşılıklarını öğrenir. Böylece veriler ikili olarak iletilse de, metin olarak görüntülenebilir.

Uygulama katmanında oluşturulan MCP protokolü, mesajlaşma problemlerini protokol kodunda çözerek problemlerin çözümünü standardize eder. Diğer uygulama katmanı protokolleri, MCP'nin çözdüğü tüm sorunları çözemez. Bu nedenle, MCP fark yaratır. MCP kullanılırsa, bu çalışmada belirtilen çözümlerin uygulama kodunda olmasına gerek kalmaz. Böylece uygulama kodunun karmaşıklığı azaltılmakta ve mesajlaşma özelliklerinde oluşabilecek hatalar ortadan kaldırılmaktadır. MCP sadece mesajlaşma için birçok özellik sunmakla kalmaz, aynı zamanda performansa da önem verir. Performans için, MCP dinamik başlık boyutunu kullanır ve MCP ikili protokoldür. MCP, temel mesajlaşma problemlerine odaklandığı ve performansı önemsediği için yerel ağların yanında IoT'ye de uygulanabilir. Gelecekte IoT alanında MCP'nin kullanılabilmesi için analizler yapılabilir. Sonuç olarak, MCP yenilikçi temel mesajlaşma özellikleri sağlar, bu özellikleri standardize ederek hata olasılığını azaltır ve uygulama kodunun karmaşıklığını azaltır.

Abstract:
Network communication problems are very old. Many studies have been done to solve these problems. These studies have revealed a layered communication structure, which we now call the OSI model. One of these layers is the application layer. Messaging related problems belong to this layer. Therefore, messaging-related features are used in this layer. Some application layer protocols have been created to standardize some messaging features. AMQP, MQTT etc. protocols are examples of application layer protocols. Basic innovative solutions are evaluated at the application layer in this research.

The applications solve messaging-related problems in different ways. Some features are provided by application code, some by libraries, some by middle-ware, and some by standardizing with protocols. The messaging features added to the application code need to be written over and over again for each application. Repeatedly writing codes of the necessary messaging features for each application causes loss of workforce, possibility of bugs, increasing complexity of the code in every time. Solving messaging problems in library code requires that this library be need to shared with all other endpoints. Using middle-wares may not be applicable in all areas such as embedded systems. Therefore, messaging features need to be standardized with a protocol.

Binary protocols are protocols that transmit data in binary. Text protocols are protocols that transmit data as Unicode or ASCII. Binary protocols are better in terms of performance. It allows data to be transmitted in smaller sizes. Text protocols transmit data in larger sizes but text protocols are easily debugged and easily read compared to binary protocols. The monitor endpoint must know the text representations of binary data to have both high performance capability and data readability. Also, while byte order (endianness) is important for binary protocols, byte order is not important for text protocols. The endianness type of the device can be little-endian or big-endian. In binary protocols, When two devices with different endianness communicate, the byte addressing of the data must be reversed before serialization and deserialization. If the solutions to these problems are standardized at the application layer, developers don't need to try to solve these problems over and over.

The server-client model is a model where multiple client endpoints request services from a single server endpoint. The publish-subscribe model is a model that enables publisher and subscriber endpoints to send message through a central message-oriented middle-ware. Subscriber endpoints subscribe to topics and publisher endpoints publish messages. The message broker forwards the message to the subscriber endpoints that have subscribed to the message. The message broker provides loose coupling and flexibility. Endpoints continue to messaging regardless of each other's existence. Transformers and filters can operate on the message broker. Loose coupling is also a disadvantage. Publisher endpoints cannot be sure whether subscriber endpoints are communicating. As publishers and subscribers increase, it can overload the message broker. Message broker can cause bottleneck since it is centralized. This limits horizontal scalability. Forwarding messages to the message broker first, rather than forwarding them directly to the target endpoints, increases latency. A decentralized publish-subscribe model is needed to get rid of these problems that come with the message broker. 

One of the biggest problems for messaging endpoints is that the message structures are out of date or implemented incorrectly in one of the endpoints. There is no standard approach to checking the compatibility of message structures of endpoints in existing messaging protocols. 

Monitoring outgoing and incoming messages in a communication can be critical. If sending messages is point-to-point, a third monitoring remote endpoint cannot be involved in the communication. The destination IP address in the IP packet header must belong to a single device for point-to-point communication. This problem can be solved by routing messages to third remote points in the application layer.

Many application layer protocols depend on a protocol at the transport layer. For example,  If QUIC is to replace TCP, dozens of TCP-based protocols will need to become QUIC-based with a new version. Thus, abstracting from sub-protocols is important for future uses.
 
In order to use multiple protocols, multiple communication interfaces must be created. if a protocol is capable of being used with multiple sub-layer protocols, a single communication interface is sufficient.

Data were collected on how current protocols solve these problems in this study. A table was created using existing protocols with features that solve these problems. It seems that other application layer protocols do not support all these features. Therefore, there is a need for a new protocol that provides these features. The name of this new protocol is the Messaging Control Protocol (MCP).

For the MCP to be used with different sub-protocols, the MCP has two components: the MCP Adapter and the communication interface. The MCP Adapter is required to provide the prerequisites for the MCP. The communication interface is required to use the functions of the sub-protocols. Thus, the MCP becomes independent of the sub-protocols. Moreover, MCP can be used with multiple sub-protocols.

There are two classes of messages in the MCP: MCP Standard Message, MCP Application Message. MCP has built-in messages independent of application code, called MCP standard messages. There are 4 types of standard messages: Heartbeat Message, Handshake Message, Subscribe Message, Subscribe Message. Heartbeat message is periodically sent to detect that the connection is keep alive and the quality of connection. Clients sends the structures of the user-defined messages as JSON format with the handshake request message. Thus, the message compatibility of the endpoints is checked. The server sends its endianness type with the handshake response message. The client learns the endianness type of the server. If the endianness types of the client and the server are different, the client reverse the data according to its endianness type. A client sends a subscribe message to subscribe to a message and sends a unsubscribe message to unsubscribe to a message.

MCP application messages are messages defined in the application code. There are four types of MCP application messages: Request-Response Message, Event Message, Initial Message, Report Message. Request-response messages are transmitted with a point-to-point communication model. Event messages are transmitted with a point-to-multipoint communication model. The transmission of event messages is triggered by the server-side application code. Event messages are sent to all connected subscriber clients. The initial message is actually a event message that is triggered by establishing connection. The report message is actually a event message that is triggered by time. A message can have more than one message type. In other words, a message can be all of message types: a response message, an event message, an initial message and a report message.

The clients have roles in the MCP connection. The roles of the clients determine the accessibility of messages in the messaging interface. The server determines which client roles can access for each message. Accessibility of a message can be given to multiple client roles. The default role of each client is common role. The default accessibility of each message is common role. An unlimited number of client roles can be generated in a messaging interface. These roles are not created by the protocol. These roles differ from the standard roles, which are the common role and monitor role, as they are user-defined. Message-based authorization is provided with these roles. The role of clients that want to monitor messages in a point-to-point communication is the monitor role. The Monitor role is independent of the accessibility of the messages. All messages in point-to-point communication are forwarded to the monitor client. Monitor client sends a connection request to join the communication. The monitor learns the message structures with the handshake message during the client connection establishment phase. Thus, it learns the text representations of the binary data in communication. Therefore, although data is transmitted in binary, the data is displayed as text.

The MCP protocol, created at the application layer, standardizes the solution of the problems by solving messaging problems at the protocol code. Other application layer protocols cannot solve all the problems that MCP does. Therefore, MCP makes the difference. If MCP is used, it is expected that the application code will have almost no code for the features required for messaging. Thus, the complexity of the application code is reduced and the bugs that may arise in the messaging features are eliminated. MCP not only offers many features for messaging, but also cares about performance. For performance, MCP uses dynamic header size and MCP is binary protocol. MCP is suitable for use in many usage areas because it focuses on basic messaging problems and it cares about performance. However, MCP alone may not be sufficient in some areas. MCP-based upper layer protocols may be needed. In the future, MCP can be developed and brought to a level that can be sufficient on its own in all areas. As a result, MCP provides innovative basic messaging features,  standardizing these features, reduces the possibility of bugs, and reduces the complexity of application code in messaging applications.