Couchbase Komutları

couchbase-cli komutu

--enable-auto-failover seçeneği

Şöyle yaparız

./couchbase-cli setting-autofailover -c <IP-node1>:8091 -u username -p password 
--enable-auto-failover 0

HTTP Digest Authentication Nedir?

Giriş

Açıklaması şöyle

Like HTTP Basic Authentication, HTTP Digest Authentication authenticates a user based on a username and a password. However the authentication is performed by transmitting the password in an ENCRYPTED form which is much MORE SECURE than the simple base64 encoding used by Basic Authentication, e.g. HTTPS Client Authentication. As Digest Authentication is not currently in widespread use, servlet containers are encouraged but NOT REQUIRED to support it.

The advantage of this method is that the cleartext password is protected in transmission, it cannot be determined from the digest that is submitted by the client to the server.

Digested password authentication supports the concept of digesting user passwords. This causes the stored version of the passwords to be encoded in a form that is not easily reversible, but that the Web server can still utilize for authentication. From a user perspective, digest authentication acts almost identically to basic authentication in that it triggers a login dialog. The difference between basic and digest authentication is that on the network connection between the browser and the server, the password is encrypted, even on a non-SSL connection. In the server, the password can be stored in clear text or encrypted text, which is true for all login methods and is independent of the choice that the application deployer makes.

TCP Header - SACK Permitted Alanı

Giriş

Bu yazıdaki içeriği uzun zaman önce not almıştım. Anladığım şekliyle tekrar kaleme almaya çalıştım. Konunu uzmanı değilim, böyle bir iddiam yok, yazıda eksikler olabilir.

 

Bu yazıda kavramlar var, her TCP gerçekleştirimi buradaki olmak zorunda değil. 

Acknowledgment Nedir?

Acknowledgment, ARQ (Automatic Repeat Request) kavramı ile ilgili. ARQ güvenilir (reliable) iletişim için vardır. ACK gelmeyen paketleri tekrar gönderir.

Not : ARQ TCP seviyesinde zaten var, ancak daha alta seviyelerde de uygulanabiliyor. Örneğin Mobile Ad hoc Network (Manet) sistemlerinde TCP'nin getirdiği maliyet fazla olduğu için Layer 2 (MAC) seviyesinde de uygulanabiliyor.

TCP Hangi Acknowledgement Yöntemini Kullanır

TCP "Cumulative Positive Acknowledgements" yöntemini kullanır. Açıklaması şöyle

Each TCP segment contains the sequence number of the next byte that the sender of the acknowledgement expects to receive from the remote host. 

Bu yöntemde alan taraf bir sonraki beklediği mesaj numarasını gönderir. Eğer bir sonraki beklenen mesaj gelmezse sürekli aynı numarayı göndererek "go-back-n" denilen davranışı istediğini belirtir. Şeklen şöyle. Burada 123 numaralı paket kaybolduğu için alan taraf 3 tane Cumulative Positive ACK gönderiyor. 123'ten sonra gelen 127,129,131 numaralı paketler için Cumulative Positive ACK gönderilemiyor, dolayısıyla gönderen taraf ta bu paketleri kendi Windows'undan çıkartamıyor

Ancak bu yöntem verimli değil. Açıklaması şöyle. Bu yüzden ilave olarak Selective Acknowledgement (SACK) yöntemi de geliştirilmiş.

The default go-back-n retransmission strategy used by TCP has the advantage of being simple to implement, in particular on the receiver side, but when there are losses, a go-back-n strategy provides a lower performance than a selective repeat strategy. 

SACK mesajların geldiğini bloklar/aralıklar şeklinde karşı tarafa bildirir. Ancak SACK kullanımının olup olmayacağına dair her iki tarafın da evet demesi gerekir.

SACK'e geçmeden önce bir küçük iyileştirme daha yapılmış. Buna "TCP fast retransmit heuristic" deniliyor. Şeklen şöyle Burada yine 3 tane ACK = 123 gönderiliyor ancak 127,129,131 numaralı mesajlar da alındığı için en sonunda ACK = 133 gönderiliyor.

Açıklaması şöyle. Yani dizideki bir mesaj kaybolur ancak dizinin gerisi düzgün gelirse (isolated loss), sorun yok fakat durum bu değilse yine problem var.

The fast retransmit heuristic improves the TCP performance provided that isolated segments are lost and the current window is large enough to allow the sender to send three duplicate acknowledgements.

When losses are not isolated or when the windows are small, the performance of the fast retransmit heuristic decreases. In such environments, it is necessary to allow a TCP sender to use a selective repeat strategy instead of the default go-back-n strategy.

Selective Acknowledgement (SACK) Kullanma Kararı Ne Zaman Verilir

SACK kullanılmasına izin verilip verilmediği yani TCP zarfındaki "SACK Permitted" değeri SYN aşamasında gönderilir. Her iki taraf SACK kullanıp kullanılmayacağını söyler. Açıklaması şöyle.

The SACK option is negotiated between the TCP endpoints, and is only used if support is advertised by both sides of a connection.

Daha detaylı açıklama şöyle.

Selective Acknowledgment (SACK) TCP was another TCP proposal in 1996, in RFC 2018. The earlier variants 8f TCP, even back to Tahoe, implement a cumulative acknowledgment scheme where a lost packet results in duplicate ACKs for each subsequently received packet. Relying purely on the cumulative acknowledgment scheme can lead to inefficiencies when packets are lost. An example of this is a case where 10,000 bytes are sent in 10 different TCP packets, and the first packet is lost during transmission. Using cumulative acknowledgment scheme, the receiver cannot say that it received the bytes 1,000 to 9,999 successfully, and only failed to receive the first packet, containing bytes 0 to 999. Thus the sender may then have to resend all 10,000 bytes.

Selective Acknowledgement (SACK) Yapısı Nasıldır
Yapısı şöyledir.

                     +--------+--------+
                     | Kind=5 | Length |
   +--------+--------+--------+--------+
   |      Left Edge of 1st Block       |
   +--------+--------+--------+--------+
   |      Right Edge of 1st Block      |
   +--------+--------+--------+--------+
   |                                   |
   /            . . .                  /
   |                                   |
   +--------+--------+--------+--------+
   |      Left Edge of nth Block       |
   +--------+--------+--------+--------+
   |      Right Edge of nth Block      |
   +--------+--------+--------+--------+

Örnek

İletişim esnasında şu paketler gelmiş olsun.

0 - 500, 900 - 1100 ve 1300 - 2000 ?

Paketlerin sırasının bozuk olması SACK gönderilmesine sebep olur. Gönderilen SACK şöyledir.

TCP ACK - 501 (in TCP header, not in SACK Option)
TCP SACK - 1st block Left Edge  - 900
TCP SACK - 1st block Right Edge - 1100
TCP SACK - 2nd block Left Edge  - 1300
TCP SACK - 2nd block Right Edge - 2000
(all in the same Segment)

Örnek

Şeklen şöyle. Burada 123 numaralı paket kaybolduğu için alan taraf 3 tane Cumulative Positive ACK gönderiyor. 123'ten sonra gelen 127,129,131 numaralı paketler içinse Selective ACK gönderiliyor. 

WebRTC - Streaming Protokolü

Giriş

Not : Bu konuyla ilgili RTMP, RTP/RTSP, HLS, WebRTC, CMAF, DASH protokollerine de bakmak lazım.

WebRTC'den önce video ve ses iletişimi için merkezi bir sunucu bulunur ve tüm veri bu sunucu üzerinden akardı. WebRTC ile iletişim artık peer-to-peer şeklinde. WebRTC tarayıcılarda bulunur ve eklenti (plug-in) kurmaya gerek kalmaz.

Transcoding Nedir?

Açıklaması şöyle. Transcoding sayesinde bir stream'i farklı cihaz ve bağlantı hızına sahip çok daha fazla insan izleyebilir

The definition of transcoding is the process of converting an audio or video file from one encoding format to another in order to increase the number of compatible target devices on which a media file can be played.

Burada Transrating and Transsizing kavramlarını bilmek gerekiyor.Açıklaması şöyle

Transcoding term includes these two terms: Transrating and Transsizing.

Transrating specifically refers to changing bitrates, such as taking a 2k video input stream at 16 Mbps and converting it into lower-bitrate streams like 720p at 5 Mbps (the process is also called renditions). 

Transsizing specifically means resizing the video frame; for example, from a resolution of 2560×1440 (2K UHD) down to 1920×1080 (1080p), 1280×720 (720p), or 720×480(480p)

Transmuxing Nedir?

Açıklaması şöyle

Transcoding Is not the same as transmuxing. Transmuxing is also called recoding, repacking, packaging, or repacking. Transmuxing is a process where you take compressed audio and video and pack/repack it in different formats with keeping audio or video content original.

For example, you might have H.264/AAC content and change the container in which it is packaged so you can use it HTTP Live Streaming (HLS), Smooth Streaming, HTTP Dynamic Streaming (HDS), or Dynamic Adaptive Streaming over HTTP (DASH). The computational overhead for transmuxing is much smaller than transcoding.

1. WebRTC Nedir?

2010 yılında Google tarafından geliştirildi. WebRTC ile tarayıcılar kendi aralarından direkt iletişim kuruyorlar. Sunucu sadece istemcilerin IP adreslerini paylaşmak için kullanılıyor. WebRTC güvenlik zaafiyetleri ile ilgili bir yazı burada.

WebRTC hemen tüm tarayıcılarda mevcut. Yani özel bir eklenti kurmaya gerek yok. Ayrıca WebRTC kütüphaneleri olduğu için uygulamalarda da kullanmak mümkün. Açıklaması şöyle

WebRTC (Web Real-Time Communication protocol) is an open-source standard for real-time communication supported by almost every modern browser, including Safari, Google Chrome, Firefox, Opera, and others. WebRTC supports Opus audio codec as well as high-quality VP8 and VP9. In the near future, the protocol will gain support for a brand new AV1 video codec. The protocol is expected to be used in a much wider area.

One of the biggest advantages of WebRTC is that it converts millions of browsers into streaming terminals without the need to install any additional plugins. What’s more, WebRTC supports sub-second latency, which means no more delay(as we mentioned, the audience hates delay)! Finally, the protocol uses an adaptive bitrate technology that allows it to automatically adjust video quality and avoid any interruptions and interruptions. 

Streaming Latency Nedir?

WebRTC "low latency" için tasarlanmış. Streaming Latency için açıklama şöyle

Streaming latency is basically the delay between the camera capturing an event and the event being displayed on viewers’ devices. It takes time to transfer the content from the source to the viewers’ devices. The time of this period depending on the type of live streaming directly affects the success of the live broadcast.

WebRTC Bileşenleri

Temel olarak 3 bileşenden oluşuyor

- Voice Engine

- Video Engine

- Transport

WebRTC Nasıl Çalışır

1. GetUserMedia JavaScript API

Kamera ve mikrofona erişim içindir

2. RTCPeerConnection  - Setting–up and creating a peer-to-peer connection 

Şu işleri yapar

- Taking care of session management 

- Managing all Session Description Protocol (SDP) message exchanges and handling negotiations through ICE candidates (uses STUN and Turn if required) 

- Encoding and decoding media streams (audio/video/text) in real-time 

- Handling all network-related issues such as bandwidth estimation, packet loss etc.  

STUN ve Turn NAT Traversal İçin Gerekiyor

Açıklaması şöyle

That’s where the roles of STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers come into the picture.   

This is how the process goes:  

- A request for public IP address is sent to STUN/TURN servers.  

- Now, this server responds with the IP address that it perceives correct.   

- It creates a set of Interactive Connectivity Establishment (ICE) that contains IP address, port, and transport protocols.   

- With this information about the public IP and port, it easily connects with the peer.    

- The peer browser, on the other hand, does the same thing while using the STUN or TURN server. 

Here it is to be noted that signalling is not a part of the WebRTC framework, it was left out for valid reasons. Different applications might need different protocols and the working group for WebRTC did not want to limit the choices for developers.  

3. RTCDataChannel

Metin, dosya gibi ses ve video dışındaki herhangi bir veriyi göndermek içindir.

WebRTC ve Ölçeklenebilirlik (Scalability)

WebRTC'nin ölçeklendirme problemler olabiliyor.

- 50 bağlantıdan sonra performans düşüyor

- Kalite düşebiliyor

vs.

WebRTC ile ilgili diğer şeyler şöyle

2. SIP (Session Initiation Protocol)

Telekom dünyasında kullanılır

3. HLS - HTTP Live Streaming

HLS yazısına taşıdım

4. WebTransport Nedir?

WebRTC'nin problemlerini çözmek için tasarlanmış yeni bir protokol. 

Robustness - Dayanıklılık ve Fail Fast (Hemen Hata Verme)

Giriş

Bu yazıda Robustness (Dayanıklılık) beklenmedik bir hatayla karşılaşınca 

- otomatik çözüm bulma, 

- varsayılan bir davranış gösterme 

olarak düşünülüyor.

Bu davranış yerine Fail Fast (Hemen Hata Verme) tercih edilebilir. Fail Fast özellikle hatanın ne gibi sonuçlara yol açacağı tahmin edilemiyorsa iyi bir yöntem.

Bu yöntemde default (varsayılan) davranışlar kodda yer almıyor. Uygulama ya sonlandırılıyor ya da bir özellik, bir ekran vs. kapatılıyor/etkisizleştiriliyor.

Problemin çözümü de bir supervisor'e devrediliyor. Supervisor insan veya bir başka uygulama olabilir.

Açıklaması şöyle. 

Some people recommend making your software robust by working around problems automatically. This results in the software “failing slowly.” The program continues working right after an error but fails in strange ways later on. A system that fails fast does exactly the opposite: when a problem occurs, it fails immediately and visibly. Failing fast is a nonintuitive

technique: “failing immediately and visibly” sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production.

Beklenen ve Beklenmedik Hatalar

Örnek

Bence güzel bir örnek şöyle

The important part here is the kind of error you encountered. There are errors that are expected, and where you know what to do with them. Typical examples are network errors, e.g. in your web application you need to display an error if the server doesn't respond, and probably give the user a button to retry. You don't want to crash everything for this kind of error that you can cleanly handle.

Another type of error are those that simply make the current job impossible. For example if you need to read 100 different files for a specific job, if any of them fails you don't need to continue, it is impossible to complete the job. So you don't need a try/catch around every file access, you can let the whole thing either succeed completely, or let if fail on any error.

The most important error, and the one this statement is really about is an unexpected error that has put your application into an unknown state. Let's assume we're in an application with multiple threads and shared memory. We have a try/catch around the whole program in each thread that catches anything. Is it safe to just restart the thread if any kind of arbitrary exception is thrown?

The answer is no, because of the shared state. The error could have done anything to the shared memory, and put it into a corrupt state. What you need to do is to get the program into a defined, known good state again. In most programming languages this means crashing the entire program and restarting it. You can't recover from having your application in an unknown state. Any of your assumption might be broken, there might simply be garbage data in some of your state.

Pragmatic Programmer

Bu kitapta Fail Fast yerine Crash Early kelimesi kullanılıyor. Kitaptaki tanım şöyle

One of the benefits of detecting problems as soon as you can is that you can crash earlier, and crashing is often the bet thing you can do. The alternative may be to continue, writing corrupted data to some vital database or commanding the washing machine into its twentieth consecutive spin cycle.

Crash Early davranışı neticesinde olabilecek şeylerin açıklaması şöyle

In these environments, programs are designed to fail, but that failure is managed with supervisors. A supervisor is responsible for running code and knows what to do in case the code fails, which could include cleaning up after it, restarting it, and so on.

Aslında Crash Early kelimesi muhtemelen yanlış kullanılmış ve yanlış anlaşılıyor. Açıklaması şöyle

The recommendation is to let a program terminate its execution ASAP when there is an indication that it cannot safely continue (the term "crash" can also be replaced by "end gracefully", if one prefers this). The important word here is not "crash", but "early" - as soon as such an indication becomes aware in a certain part of the code, the program should not "hope" that later executed parts in the code might still work, but simply end execution, ideally with a full error report. And a common way of ending execution is using a specific exception for this, transport the information where the problem occurred to the outermost scope, where the program should be terminated.

Moreover, the recommendation is not against catching exceptions in general. The recommendation is against the abuse of catching unexpected exceptions to prevent the end of a program. Continuing a program though it is unclear whether this is safe or not can mask severe errors, makes it hard to find the root cause of a problem and has the risk of causing more damage than when the program suddenly stops.

Supervisor ne olabilir. Açıklaması şöyle

Such a supervisor is either a person, which will deal with the failure of a program, or another program running in a separate process, which monitors the activity of other, more complex programs, and can take appropriate actions when one of them "fails".

What this is precisely depends heavily on the kind of program, and the potential costs of a failure. Imagine the failure scenarios for

- a desktop application with some GUI for managing address data in a database

- a malware scanner on your PC

- the software which makes the regular backups for the Stack Exchange sites

- software which does automatic high speed stock trading

- software which runs your favorite search engine or social network

- the software in your newest smart TV or your smartphone

- controller software for an insulin pump

- controller software for steering of an airplane

- monitoring software for a nuclear power plant

I think you can imagine by yourself for which of these examples a human supervisor is enough, or where an "automatic" supervisor is required to keep the system stable even when one of its components fail.

Örnek - Parser

Fail fast yöntemini takip etmeyen PHP kodlarında hata mesajları çok uzun olabiliyor çünkü derleyici çalışmaya devam ediyor. Aslında derleyici beklenmedik bir hata ile karşılaşmış ve ilk hatada çıksa daha iyi olur. Açıklaması şöyle

Please don't get hung up on the fact that I mentioned PHP. one of the features of php is that it keeps trying to work even when there are errors. Most other languages stop the process flow on an error. That's a big reason for a cascade of error messages.

Örnek - Formatlı Dosya Okuma

Açıklaması şöyle. İlk hata bulduğunda uygulama durabilir. Eğer devam ederse, belki yanlış bir veri okunacak

If the first step of parsing a file fails, then stop with an error. Don't carry on passing bad data from one step to the next.

Yazılım Dünyasında Air Gap Nedir?

Giriş

Bu konuyu çok bilmiyorum. Anladığım kısmın not etmek istedim. 

Hassas bilgiye sahip bir bilgisayarın, internete açık bir başka bilgisayardan ayrılmasıdır. Şöyledir

internet-facing computerA => air-gapped computerB 

A'dan B'Ye Tek Yönlü İletişim İstiyorsak

- İki bilgisayar arasındaki kablonun B'den A'ya giden tarafı bir tarafı koparılır veya B'nin önüne dışarıya bağlantıya izin vermeyen bir firewall konulur. Açıklaması şöyle

Have Computer B sit behind a router with firewall configured. The firewall allows traffic in, but drops traffic out. That's why you need an UDP service, as TCP would have to send confirmation data out, and that's forbidden.

- A'dan B'ye veri göndermek için sadece UDP kullanılır. TCP kullanılamaz çünkü TCP çift yönlü iletişim gerektirir.

UML Class Diagram - Composition (Birbirinden Ayrılamaz Parçalar)

Giriş

Not : UML Class Diagram yazısına bakabilirsiniz

Composition oluşum, bileşim olarak çevrilir. Bileşim olduğu için birbirinden ayrılamaz parçaları kasteder. Açıklaması şöyle.

A composition describes a relationship in which one object completely controls another object that has no independent lifecycle.

İçi dolu elmas ile gösterilir.

Örnek

Elimizde şöyle bir C++ kodu olsun. Bu kodda Player nesnesine bir Board nesnesi verilmeli ve pointer olmadığı için birbirinden ayırma şansı da yok

class Board {
    ...
};

class Player
{
  Board m_board;
  ...  
};