विश्वसनीय डेटा स्थानांतरण के मूल सिद्धांत

उन लोगों के लिए जो करना है नेटवर्क और प्रोटोकॉल को समझने के लिए समर्पित।

संक्षिप्त

लेख विश्वसनीय डेटा ट्रांसमिशन की मूल बातें पर चर्चा करता है, उदाहरणों को लागू करता है Go, यूडीपी और टीसीपी सहित। पर आधारित समय, два, तीन и книги "Компьютерные сети. Нисходящий подход", а то все обсуждают только Танненбаума и Олиферов.

परिवहन परत प्रोटोकॉल

विभिन्न होस्ट पर चल रही एप्लिकेशन प्रक्रियाओं के बीच एक तार्किक संबंध प्रदान करता है। अनुप्रयोग परिप्रेक्ष्य से, एक तार्किक कनेक्शन एक चैनल की तरह दिखता है जो प्रक्रियाओं को सीधे जोड़ता है।

परिवहन परत प्रोटोकॉल एंड सिस्टम द्वारा समर्थित हैं, लेकिन नेटवर्क राउटर द्वारा नहीं (सिवाय - डीपीआई). प्रेषक पक्ष पर, ट्रांसपोर्ट परत, भेजने वाली एप्लिकेशन प्रक्रिया से प्राप्त एप्लिकेशन लेयर डेटा को ट्रांसपोर्ट लेयर पैकेट में परिवर्तित करती है जिसे सेगमेंट कहा जाता है।

यह एप्लिकेशन परत संदेशों को टुकड़ों में विभाजित करके (यदि आवश्यक हो) और उनमें से प्रत्येक में एक ट्रांसपोर्ट लेयर हेडर जोड़कर किया जाता है।

Далее транспортный уровень передает сегмент сетевому уровню отправителя, где сегмент инкапсулируется в пакет сетевого уровня (дейтаграмму) и отсылается. На принимающей стороне сетевой уровень извлекает сегмент транспортного уровня из дейтаграммы и передает его вверх транспортному уровню. Далее транспортный уровень обрабатывает полученный сегмент таким образом, чтобы его данные стали доступны приложению-получателю.

विश्वसनीय डेटा ट्रांसमिशन के सिद्धांत

पूरी तरह से सुरक्षित चैनल पर विश्वसनीय डेटा ट्रांसमिशन

सबसे सरल मामला. भेजने वाला पक्ष केवल ऊपरी परत से डेटा प्राप्त करता है, इसे युक्त एक पैकेट बनाता है, और इसे चैनल पर भेजता है।

सेवक

package main

import (
    "log"
    "net"
)

func main() {
    // IP-адрес сервера и порт
    serverAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:12000")
    if err != nil {
        log.Fatal(err)
    }

    // создаем сокет с портом
    serverConn, err := net.ListenUDP("udp", serverAddr)
    if err != nil {
        log.Fatal(err)
    }
    // отложенное закрытие соединения
    defer serverConn.Close()

    // создаем буфер для данных
    buf := make([]byte, 1024)

    // ждем соединение
    for {
        // читаем запрос
        n, addr, err := serverConn.ReadFromUDP(buf)
        // передаем данные в ВЕРХНИЙ уровень: в нашем случае stdout
        println(string(buf[0:n]), " form ", addr.IP.String())
        if err != nil {
            log.Fatal(err)
        }
        // ответа нет, т.к. это UDP + надежный канал
    }
}

ग्राहक

package main

import (
    "fmt"
    "log"
    "net"
    "time"
)

func main() {
    // IP-адрес сервера и порт
    serverAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:12000")
    if err != nil {
        log.Fatal(err)
    }
    // локальный IP-адрес и порт
    localAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:0")
    if err != nil {
        log.Fatal(err)
    }
    // установка соединения
    conn, err := net.DialUDP("udp", localAddr, serverAddr)
    if err != nil {
        log.Fatal(err)
    }
    // отложенное закрытие соединения
    defer conn.Close()

    for {
        // получение данных от ВЕРХНЕГО уровня
        fmt.Print("Введите строчное предложение > ")
        var msg string
        _, err := fmt.Scanf("%s", &msg)
        if err != nil {
            log.Fatal(err)
        }
        // передается поток байт, а не строка
        buf := []byte(msg)
        // запись (передача) в соединение
        _, err = conn.Write(buf)
        if err != nil {
            log.Fatal(err)
        }
        // 1 секундочку
        time.Sleep(time.Second * 1)
    }
}

संभावित त्रुटियों के साथ एक चैनल पर विश्वसनीय डेटा ट्रांसमिशन

अगला कदम यह मान लेना है कि सभी प्रेषित पैकेट उसी क्रम में प्राप्त होते हैं जिसमें वे भेजे गए थे, लेकिन उनमें बिट्स इस तथ्य के कारण दूषित हो सकते हैं कि चैनल कभी-कभी विकृतियों के साथ डेटा प्रसारित करता है।

इस मामले में, निम्नलिखित तंत्र का उपयोग किया जाता है:

• गलती पहचानना;
• प्रतिक्रिया;
• पुन:संचरण।

विश्वसनीय डेटा ट्रांसफर प्रोटोकॉल जिनमें कई बार ट्रांसमिशन को दोहराने के लिए समान तंत्र होते हैं, स्वचालित रिपीट रीक्वेस्ट (ARQ) प्रोटोकॉल कहलाते हैं।
इसके अतिरिक्त, रसीदों में त्रुटियों की संभावना पर विचार करना उचित है, जब प्राप्तकर्ता पक्ष को अंतिम पैकेट के हस्तांतरण के परिणामों के बारे में कोई जानकारी नहीं मिलेगी।
इस समस्या का समाधान, जिसका उपयोग टीसीपी में भी किया जाता है, पैकेट के अनुक्रम संख्या वाले डेटा पैकेट में एक नया फ़ील्ड जोड़ना है।

पैकेट विरूपण और हानि के अधीन एक अविश्वसनीय चैनल पर विश्वसनीय डेटा ट्रांसमिशन

विकृति के साथ-साथ, दुर्भाग्य से, नेटवर्क में पैकेट हानि भी होती है।
और इस समस्या को हल करने के लिए तंत्र की आवश्यकता है:

• पैकेट हानि के तथ्य का निर्धारण;
• प्राप्तकर्ता पक्ष को खोए हुए पैकेटों की पुनः डिलीवरी।

इसके अतिरिक्त, पैकेज के खो जाने के अलावा, रसीद के खोने की संभावना या, यदि कुछ भी नहीं खोया है, तो इसकी डिलीवरी काफी देरी से होने की संभावना प्रदान करना आवश्यक है। सभी मामलों में, एक ही काम किया जाता है: पैकेट को पुनः प्रेषित किया जाता है। समय को नियंत्रित करने के लिए, यह तंत्र एक उलटी गिनती टाइमर का उपयोग करता है, जो आपको प्रतीक्षा अंतराल के अंत को निर्धारित करने की अनुमति देता है। तो पैकेज में जाल TCPKeepAlive डिफ़ॉल्ट रूप से 15 सेकंड पर सेट है:

// defaultTCPKeepAlive is a default constant value for TCPKeepAlive times
// See golang.org/issue/31510
const (
    defaultTCPKeepAlive = 15 * time.Second
)

हर बार पैकेट प्रसारित होने पर (पहली और दूसरी बार दोनों) भेजने वाले पक्ष को एक टाइमर शुरू करने की आवश्यकता होती है, टाइमर से होने वाली रुकावटों को संभालना होता है और उसे रोकना होता है।

इसलिए, हम विश्वसनीय डेटा ट्रांसफर प्रोटोकॉल की प्रमुख अवधारणाओं से परिचित हो गए हैं:

• चेकसम;
• पैकेजों की क्रम संख्या;
• टाइमर;
• सकारात्मक और नकारात्मक प्राप्तियाँ.

लेकिन वह सब नहीं है!

पाइपलाइनिंग के साथ विश्वसनीय डेटा ट्रांसफर प्रोटोकॉल

जिस संस्करण पर हम पहले ही विचार कर चुके हैं, उसमें विश्वसनीय डिलीवरी प्रोटोकॉल बहुत अक्षम है। आरटीटी बढ़ने पर यह संचार चैनल द्वारा प्रदान किए गए प्रसारण को "धीमा" करना शुरू कर देता है। इसकी दक्षता बढ़ाने और संचार चैनल क्षमता का बेहतर उपयोग करने के लिए पाइपलाइनिंग का उपयोग किया जाता है।

पाइपलाइनिंग के उपयोग से होता है:

• अनुक्रम संख्याओं की सीमा बढ़ाना, क्योंकि सभी भेजे गए पैकेट (पुन: प्रसारण को छोड़कर) को विशिष्ट रूप से पहचाना जाना चाहिए;
• संचारण और प्राप्त करने वाले पक्षों पर बफ़र्स बढ़ाने की आवश्यकता।

अनुक्रम संख्या सीमा और बफर आकार की आवश्यकताएं पैकेट भ्रष्टाचार, हानि और देरी के जवाब में प्रोटोकॉल द्वारा की जाने वाली कार्रवाइयों पर निर्भर करती हैं। पाइपलाइनिंग के मामले में, त्रुटियों को ठीक करने की दो विधियाँ हैं:

• एन पैकेट वापस लौटाएं;
• चयनात्मक पुनरावृत्ति.

एन पैकेट वापस जा रहे हैं - स्लाइडिंग विंडो प्रोटोकॉल

प्रेषक को तीन प्रकार की घटनाओं का समर्थन करना होगा:

• उच्च स्तरीय प्रोटोकॉल द्वारा कॉल करें। जब डेटा भेजने वाले फ़ंक्शन को "ऊपर से" कहा जाता है, तो भेजने वाला पक्ष पहले विंडो के भरने की डिग्री की जांच करता है (अर्थात, प्राप्तियों की प्रतीक्षा में एन भेजे गए संदेशों की उपस्थिति)। यदि विंडो खाली है, तो एक नया पैकेट उत्पन्न और प्रसारित होता है, और चर मान अपडेट किए जाते हैं। अन्यथा, भेजने वाला पक्ष ऊपरी परत पर डेटा लौटाता है, और यह एक अंतर्निहित संकेत है कि विंडो भरी हुई है। आमतौर पर ऊपरी परत कुछ समय बाद डेटा को फिर से प्रसारित करने का प्रयास करेगी। एक वास्तविक एप्लिकेशन में, प्रेषक संभवतः या तो डेटा को बफर करेगा (इसे तुरंत भेजने के बजाय) या उसके पास एक सिंक्रोनाइज़ेशन तंत्र होगा (जैसे कि सेमाफोर या ध्वज) जो ऊपरी परत को सेंड फ़ंक्शन को केवल तभी कॉल करने की अनुमति देगा जब विंडो खाली हो .
• पुष्टि प्राप्त करना। प्रोटोकॉल में, अनुक्रम संख्या एन वाले पैकेट के लिए, एक सामान्य पावती जारी की जाती है जो दर्शाती है कि एन से पहले अनुक्रम संख्या वाले सभी पैकेट सफलतापूर्वक प्राप्त किए गए थे।
• प्रतीक्षा अंतराल समाप्त हो गया है. पैकेट और प्राप्तियों के नुकसान और देरी के तथ्यों को निर्धारित करने के लिए, प्रोटोकॉल एक टाइमर का उपयोग करता है। यदि टाइमआउट अंतराल समाप्त हो जाता है, तो भेजने वाला पक्ष सभी भेजे गए अस्वीकृत पैकेटों को फिर से भेज देता है।

चयनात्मक पुनरावृत्ति

जब विंडो का आकार और थ्रूपुट-प्रसार विलंब उत्पाद बड़ा होता है, तो बड़ी संख्या में पैकेट पाइपलाइन में हो सकते हैं। ऐसे मामले में, एक एकल पैकेट त्रुटि के कारण बड़ी संख्या में पैकेट पुनः प्रेषित हो सकते हैं, जिनमें से अधिकांश की आवश्यकता नहीं थी।

उदाहरण

शीर्ष सैद्धांतिक अभ्यासों को व्यावहारिक कार्यान्वयन में एकत्रित किया जाता है टीसीपी. और अगर कोई सबसे अच्छा जानता है - में आपका स्वागत है.

सेवक

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "strings"
)

func main() {
    // создаем сокет с портом 
    ln, err := net.Listen("tcp", ":8081")
    if err != nil {
        log.Fatalln(err)
    }
    // ожидание вызова
    conn, _ := ln.Accept()

    for {
        // считывание данных
        msg, err := bufio.NewReader(conn).ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // вывод сообщения в stdout
        fmt.Print("Message Received:", string(msg))
        // перевод строки в верхний регистр
        newMsg := strings.ToUpper(msg)
        // отправка данных
        conn.Write([]byte(newMsg + "n"))
    }
}

ग्राहक

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "os"
)

func main() {
    // установка соединения
    conn, err := net.Dial("tcp", "127.0.0.1:8081")
    if err != nil {
        log.Fatalln(err)
    }

    for {
        // считывание данных с stdin
        reader := bufio.NewReader(os.Stdin)
        fmt.Print("Text to send: ")
        // построчно
        text, err := reader.ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // отправка
        fmt.Fprintf(conn, text+"n")
        // прием
        msg, err := bufio.NewReader(conn).ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // вывод полученного ответа
        fmt.Print("Msg from Server: " + msg)
    }
}

उत्पादन

विश्वसनीय डेटा स्थानांतरण और उपयोग सुनिश्चित करने के लिए तंत्र

तंत्र
आवेदन, टिप्पणी

योग की जाँच करें
प्रेषित पैकेट में बिट त्रुटियों का पता लगाने के लिए उपयोग किया जाता है

घड़ी
टाइमआउट अंतराल की गणना करता है और इंगित करता है कि यह कब समाप्त हो गया है। उत्तरार्द्ध का मतलब है कि उच्च संभावना के साथ पैकेट या उसकी रसीद ट्रांसमिशन के दौरान खो जाती है। यदि कोई पैकेट देरी से वितरित किया जाता है, लेकिन खो नहीं जाता है (टाइमआउट अंतराल की समयपूर्व समाप्ति), या रसीद खो जाती है, तो पुन: प्रेषण से प्राप्तकर्ता पक्ष पर एक डुप्लिकेट पैकेट बन जाता है।

क्रमांक
प्रेषक से प्राप्तकर्ता तक प्रेषित डेटा पैकेट की अनुक्रमिक संख्या के लिए उपयोग किया जाता है। प्राप्त पैकेटों की क्रम संख्या में अंतराल रिसीवर को पैकेट हानि का पता लगाने की अनुमति देता है। समान पैकेट अनुक्रम संख्या का मतलब है कि पैकेट एक दूसरे के डुप्लिकेट हैं

पुष्टि
प्राप्तकर्ता छोर द्वारा उत्पन्न किया जाता है और भेजने वाले छोर को संकेत दिया जाता है कि संबंधित पैकेट या पैकेटों का समूह सफलतापूर्वक प्राप्त हो गया है। आमतौर पर पावती में सफलतापूर्वक प्राप्त पैकेटों की अनुक्रम संख्याएँ शामिल होती हैं। प्रोटोकॉल के आधार पर, व्यक्तिगत और समूह पुष्टिकरण को प्रतिष्ठित किया जाता है

नकारात्मक पुष्टि
प्राप्तकर्ता द्वारा प्रेषक को यह सूचित करने के लिए उपयोग किया जाता है कि पैकेट गलत तरीके से प्राप्त हुआ था। एक नकारात्मक पावती में आमतौर पर उस पैकेट की अनुक्रम संख्या शामिल होती है जो सही ढंग से प्राप्त नहीं हुआ था

खिड़की, कन्वेयराइजेशन
अनुक्रम संख्याओं की सीमा सीमित करें जिनका उपयोग पैकेट संचारित करने के लिए किया जा सकता है। पावती की प्रतीक्षा की तुलना में मल्टीकास्ट और हैंडशेक प्रोटोकॉल थ्रूपुट को काफी बढ़ा सकते हैं। जैसा कि हम देखेंगे, विंडो आकार की गणना रिसीविंग एंड की रिसेप्शन और बफरिंग क्षमताओं के साथ-साथ नेटवर्क लोड स्तर के आधार पर की जा सकती है।

नेटवर्किंग के लिए गो का उपयोग करने के और उदाहरण

В खजाने.

स्रोत: www.habr.com