Lorawan-stack: एक प्रारूप से कई परिणामी संदेशों का समर्थन करें

@adriansmares मैं वर्तमान में इस मुद्दे पर काम कर रहा हूं। formatter.go फ़ाइल में *ttnpb.ApplicationUp फ़ंक्शन के लिए []byte से [][]byte में बदलने के बाद, मैंने इसे json.go और protobuf.go फ़ाइलों में भी बदल दिया। लेकिन अब, यह निम्न त्रुटि देता है:

कृपया कुछ सुझाव दें। धन्यवाद।

@ mihirr93 चूंकि अब आप परिणामों का एक टुकड़ा वापस करने के लिए कॉल साइटों को संशोधित कर रहे हैं (प्रत्येक परिणाम बाइट्स का एक टुकड़ा है), आपको उन जगहों को लपेटना चाहिए जहां केवल एक परिणाम [][]byte{ slice-containing-result } साथ लौटाया जाता है।

नमस्कार श्रीमान @adriansmares । मैं अपने दृष्टिकोण को लेकर थोड़ा भ्रमित हूं। हम फ्रंट-एंड संदेश (कच्चे पेलोड) को कई संदेशों में विभाजित करने के लिए तैयार हैं। लेकिन इस मामले में, जिस बिंदु पर संदेश काटा जाएगा वह उसके एन्कोडिंग (कैयेन या कोई कस्टम एन्कोडिंग) पर निर्भर करता है जो हमारे लिए अज्ञात है। तो, ऐसा करने के लिए हमें डीकोडेड पेलोड का उपयोग करने की आवश्यकता है। एक बार जब उपयोगकर्ता टीटीएन के पेलोड प्रारूप टैब में डिकोडर में प्रवेश करता है, तो एप्लिकेशन वास्तव में JSON में डिकोड किए गए मान दिखाता है (जैसा कि चित्र में देखा गया है)। क्या हमें इस डीकोडेड पेलोड को सीधे विभाजित नहीं करना चाहिए और http का उपयोग करके इसे और आगे नहीं बढ़ाना चाहिए?

क्या आप कृपया इस भ्रम पर कुछ प्रकाश डाल सकते हैं?
और, क्या हम सिर्फ pkg फाइलों को संशोधित करते हैं और .proto फाइलें अपने आप अपडेट हो जाएंगी?
आपकी तरह के समर्थन और समय के लिए बहुत-बहुत धन्यवाद।

_ध्यान रखें कि इस रिपॉजिटरी में हमारे लोरावन स्टैक का V3 संस्करण है, और प्रदान किया गया चित्र TTN से है, जो V2 संस्करण चलाता है।_

कृपया ध्यान रखें कि यह समस्या केवल एक संदेश से कई पेलोड बनाने के समर्थन से संबंधित है, और नए प्रारूप का मुद्दा जिसमें आप शायद रुचि रखते हैं, वह है https://github.com/TheThingsNetwork/lorawan-stack/issues/1158। कृपया जांचें कि क्या यह समस्या वास्तव में वही है जिसे आप ढूंढ रहे हैं।

फिर भी, मैं इस मामले में सुझाव दूंगा कि आप JSON वन पर आधारित एक नया प्रारूप पेश करें, जो अपलिंक के अंदर मिली डीकोड की गई जानकारी के आधार पर कई पेलोड उत्पन्न करता है।
आप शायद ApplicationUp_UplinkMessage अपलिंक संदेश को विशेष रूप से संभालना चाहेंगे, क्योंकि इसमें वे फ़ील्ड शामिल हैं जिनमें आप DecodedPayload फ़ील्ड के हिस्से के रूप में रुचि रखते हैं।

इस उपयोग के मामले के लिए आपको प्रोटो फाइलों को संशोधित करने की आवश्यकता नहीं है।

मैं अभी भी स्टैक के आंतरिक कामकाज और कोड को समझने की कोशिश कर रहा हूं। वर्तमान में, मैं केवल इस मुद्दे पर ध्यान केंद्रित कर रहा हूं, न कि #1158 पर। जैसा कि आपने ApplicationUp_Uplinkmessage को संशोधित करने का सुझाव दिया था, मैं इसका पता लगाने की कोशिश कर रहा हूं। इस समय मेरे पास निम्नलिखित प्रश्न हैं:
1) संरचना ApplicationUplink और func ApplicationUp_UplinkMessage को ttnpb निर्देशिका में संदेशों.pb.go फ़ाइल में परिभाषित किया गया है। हालांकि फ़ाइल के शीर्षलेख में "संपादित न करें" का उल्लेख है। क्या मुझे इसे अनदेखा करना चाहिए? या इसे संशोधित करने का कोई वैकल्पिक तरीका है?
2) क्या आप कृपया इसका अधिक विस्तार से वर्णन कर सकते हैं " introduce a new format, based on the JSON one "? मैंने सोचा कि हमें नया बनाने के बजाय मौजूदा प्रारूप को संशोधित करना होगा।
3) आपने परिणामों के रैपिंग का भी उल्लेख किया है जहां केवल एक परिणाम लौटाया जाता है। यह वास्तव में क्या करेगा? क्या यह एकाधिक संदेशों को एक में दोबारा जोड़ देगा और केवल एक परिणाम लौटाएगा? और क्या हमें केवल अपलिंक संदेश के लिए ऐसा करने की आवश्यकता है?

[आपके निरंतर मार्गदर्शन के लिए @adriansmares धन्यवाद। हालाँकि, मैंने गोलंग ट्यूटोरियल लिया, यह GO भाषा के साथ मेरी पहली बातचीत है, आपको इतने सारे संदेहों से परेशान करने के लिए क्षमा करें]

• आपको उस फ़ाइल को संपादित करने की आवश्यकता नहीं है, न ही किसी *.pb.* फ़ाइलों को। जब आप mage proto:all चलाते हैं तो ये स्वचालित रूप से *.proto फ़ाइलों से उत्पन्न होते हैं। बहरहाल, इस मुद्दे के प्रयोजन के लिए इस तरह के कोई संशोधन करने की आवश्यकता नहीं है।
• कृपया दूसरे अंक में इसका पालन करें।
• रैपिंग के लिए सुझाव आपको मौजूदा कोड को बरकरार रखने की अनुमति देता है (अभी भी एक अपलिंक संदेश से पोस्ट किए जाने के लिए एक पेलोड लौटा रहा है)।

मैं पूरी पाइपलाइन को बेहतर ढंग से समझाने की कोशिश करता हूं, शायद यह इस पर कुछ प्रकाश डालेगा कि यह कैसे काम करता है

1. एक डिवाइस 1 अपलिंक भेजता है।
2. 1 अपलिंक गेटवे द्वारा प्राप्त किया जाता है और गेटवे सर्वर को भेजा जाता है जो इसे नेटवर्क सर्वर को अग्रेषित करता है, जो फिर इसे एप्लिकेशन सर्वर को अग्रेषित करता है। AS तक पहुँचने वाला संदेश *ttnpb.ApplicationUplink ।
3. के रूप में डीकोड क्षेत्रों में अपने द्विआधारी पेलोड को डिकोड करने के लिए इस 1 अपलिंक और प्रयास करने पड़ते हैं (में बाइट्स बारी FRMPayload के डीकोड संरचना में क्षेत्र DecodedPayload ) डिवाइस पेलोड फ़ॉर्मेटर का उपयोग कर।
4. इसके बाद यह इसे *ttnpb.ApplicationUp में लपेटता है और इसे फ्रंटएंड (एमक्यूटीटी, वेबहुक, पबसुब, एप्लिकेशन पैकेज) में भेजता है।
5. फ़्रंटएंड को यह 1 *ttnpb.ApplicationUp प्राप्त होता है और उनकी सेटिंग्स (प्रारूप) के आधार पर चुनें कि किस फ़ॉर्मेटर का उपयोग करना है (फ़ॉर्मेटर इंटरफ़ेस को pkg/applicationserver/io/formatters में परिभाषित किया गया है)।
6. फ्रंटएंड formatter.FromUp को 1 *ttnph.ApplicationUp formatter.FromUp साथ कॉल करता है और बाइट का एक टुकड़ा ( []byte ) प्राप्त करता है, जो 1 संदेश के मुख्य भाग का प्रतिनिधित्व करता है।

अब, इस मुद्दे के संबंध में, मुझे आशा है कि यह दिखाई दे रहा है कि केवल चरण 6 में बदलाव की आवश्यकता है:

• इंटरफ़ेस और कार्यान्वयन दोनों के रिटर्न प्रकारों को बदलना जैसे कि FromUp एकाधिक पेलोड (बाइट के स्लाइस का एक टुकड़ा) वापस कर सकता है।
• मौजूदा Protobuf और JSON प्रारूपों को अपना व्यवहार नहीं बदलना चाहिए, और इस तरह केवल 1 पेलोड लौटाना जारी रखना चाहिए (इसीलिए रैप की आवश्यकता है)।
• [][]byte वापस करने के लिए इन 2 (इंटरफ़ेस और फ़ॉर्मेटर्स) को बदलने के बाद आपको त्रुटियां दिखाई देने लगेंगी (क्योंकि FromUp कॉल करने वाले अधिकांश स्थानों पर केवल एक पेलोड प्राप्त होने की उम्मीद है - आपको अपडेट करना होगा इन कॉल साइटों और पेलोड की सूची के माध्यम से उन्हें लूप बनाते हैं और उनमें से प्रत्येक को भेजते हैं।

केवल इस मुद्दे के बाद, जो व्यवहार को बिल्कुल भी नहीं बदलता है, आप अपने स्वयं के फॉर्मेटर को लागू करने के साथ आगे बढ़ सकते हैं, जो कई पेलोड का एक टुकड़ा लौटाएगा, प्रत्येक माप के लिए एक (लेकिन ध्यान रखें कि यह नया प्रारूप इस मुद्दे के दायरे से बाहर है!)

इतनी विस्तृत व्याख्या और मार्गदर्शन के लिए ./mage go:test js:test jsSDK:test साथ भी परीक्षण किया और यह कोई त्रुटि नहीं देता है। कोड में किए गए प्रमुख परिवर्तन नीचे हाइलाइट किए गए हैं:
फ़ॉर्मेटर.गो

type Formatter interface {
    FromUp(*ttnpb.ApplicationUp) ([][]byte, error)
    ToDownlinks([]byte) (*ttnpb.ApplicationDownlinks, error)
    ToDownlinkQueueRequest([]byte) (*ttnpb.DownlinkQueueRequest, error)
}

json.go

func (json) FromUp(msg *ttnpb.ApplicationUp) ([][]byte, error) {
    m, e := jsonpb.TTN().Marshal(msg)
    return [][]byte{m}, e
}

प्रोटोबफ.गो
ऊपर की तरह

mqtt.go

buf, err := c.format.FromUp(up.ApplicationUp)
                if err != nil {
                    logger.WithError(err).Warn("Failed to marshal upstream message")
                    continue
                }
                logger.Debug("Publish upstream message")
                for _, v := range buf {
                    c.session.Publish(&packet.PublishPacket{
                        TopicName:  topic.Join(topicParts),
                        TopicParts: topicParts,
                        QoS:        qosUpstream,
                        Message:    v,
                    })
                }

pubsub.go
ऊपर की तरह

webhooks.go

unc (w *webhooks) newRequest(ctx context.Context, msg *ttnpb.ApplicationUp, hook *ttnpb.ApplicationWebhook) ([]*http.Request, error) {
    var cfg *ttnpb.ApplicationWebhook_Message
    switch msg.Up.(type) {
    case *ttnpb.ApplicationUp_UplinkMessage:
        cfg = hook.UplinkMessage
    case *ttnpb.ApplicationUp_JoinAccept:
        cfg = hook.JoinAccept
    case *ttnpb.ApplicationUp_DownlinkAck:
        cfg = hook.DownlinkAck
    case *ttnpb.ApplicationUp_DownlinkNack:
        cfg = hook.DownlinkNack
    case *ttnpb.ApplicationUp_DownlinkSent:
        cfg = hook.DownlinkSent
    case *ttnpb.ApplicationUp_DownlinkFailed:
        cfg = hook.DownlinkFailed
    case *ttnpb.ApplicationUp_DownlinkQueued:
        cfg = hook.DownlinkQueued
    case *ttnpb.ApplicationUp_LocationSolved:
        cfg = hook.LocationSolved
    }
    if cfg == nil {
        return nil, nil
    }
    url, err := url.Parse(hook.BaseURL)
    if err != nil {
        return nil, err
    }
    url.Path = path.Join(url.Path, cfg.Path)
    expandVariables(url, msg)
    if err != nil {
        return nil, err
    }
    format, ok := formats[hook.Format]
    if !ok {
        return nil, errFormatNotFound.WithAttributes("format", hook.Format)
    }
    buf, err := format.FromUp(msg)
    if err != nil {
        return nil, err
    }
    var requests []*http.Request
    for i, v := range buf {
        req, err := http.NewRequest(http.MethodPost, url.String(), bytes.NewReader(v))
        requests[i] = req
        if err != nil {
            return nil, err
        }
        for key, value := range hook.Headers {
            req.Header.Set(key, value)
        }
        if hook.DownlinkAPIKey != "" {
            req.Header.Set(downlinkKeyHeader, hook.DownlinkAPIKey)
            req.Header.Set(downlinkPushHeader, w.createDownlinkURL(ctx, hook.ApplicationWebhookIdentifiers, msg.EndDeviceIdentifiers, "push"))
            req.Header.Set(downlinkReplaceHeader, w.createDownlinkURL(ctx, hook.ApplicationWebhookIdentifiers, msg.EndDeviceIdentifiers, "replace"))
        }
        req.Header.Set("Content-Type", format.ContentType)
        req.Header.Set("User-Agent", userAgent)
    }
    return requests, nil
}

कृपया अपनी प्रतिक्रिया और टिप्पणियाँ प्रदान करें। एक बार कार्य पूरी तरह से समाप्त हो जाने पर मैं कोड शैली दिशानिर्देशों के अनुसार सुधार (वर नामकरण, इंडेंटेशन, आदि) करूंगा। और अगर यह सही लगता है, तो क्या आप कृपया मुझे #1158 अंक के लिए मार्गदर्शन कर सकते हैं। एक बार फिर आपका धन्यवाद।

@ mihirr93 अच्छा लग रहा है! कृपया अपने परिवर्तन करें और इस मुद्दे के लिए पुल अनुरोध सबमिट करें। इसे मर्ज करने के बाद हम #1158 में उल्लिखित नए फॉर्मेटर की ओर आगे बढ़ सकते हैं।

@adriansmares ज़रूर, मैं वह करूँगा। क्या वह पुल अनुरोध उल्लिखित वातावरण या स्टैक के नवीनतम संस्करण पर आधारित होना चाहिए?

मेरा सुझाव है कि आप बाद में विरोध से बचने के लिए अपने परिवर्तनों को नवीनतम master ऊपर रीबेस करें।

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

इसकी अब आवश्यकता नहीं है, क्योंकि यह खराब पैमाने पर है।