Lorawan-stack: 하나의 형식에서 여러 결과 메시지 지원

@adriansmares 저는 현재 이 문제를 해결하기 위해 노력하고 있습니다. formatter.go 파일에서 *ttnpb.ApplicationUp 함수를 []byte에서 [][]byte로 변경한 후 json.go 및 protobuf.go 파일에서도 변경했습니다. 그러나 이제 다음 오류가 발생합니다.

친절하게 몇 가지 제안을 제공합니다. 감사합니다.

@mihirr93 이제 결과 조각(각 결과는 바이트 조각임)을 반환하도록 호출 사이트를 수정하고 있으므로 [][]byte{ slice-containing-result } 로 하나의 결과만 반환되는 위치를 래핑해야 합니다.

안녕하세요 Mr. @adriansmares 입니다. 나는 우리의 접근 방식에 대해 약간 혼란 스럽습니다. 우리는 프론트 엔드 메시지(원시 페이로드)를 여러 메시지로 분할하도록 묶고 있습니다. 그러나 이 경우 메시지가 슬라이싱되는 지점은 우리에게 알려지지 않은 인코딩(카이엔 또는 사용자 정의 인코딩)에 따라 다릅니다. 따라서 이를 수행하려면 디코딩된 페이로드를 사용해야 합니다. 사용자가 TTN의 페이로드 형식 탭에 디코더를 입력하면 애플리케이션은 실제로 디코딩된 값을 JSON으로 표시합니다(그림 참조). 이 디코딩된 페이로드를 직접 분할하고 http를 사용하여 추가로 푸시해야 하지 않습니까?

이 혼란에 대해 조금이나마 조명해 주시겠습니까?
그리고 pkg 파일만 수정하면 .proto 파일이 자동으로 업데이트됩니까?
귀하의 친절한 지원과 시간에 감사드립니다.

_이 저장소에는 LoRaWAN 스택의 V3 버전이 포함되어 있으며 제공된 사진은 V2 버전을 실행하는 TTN에서 가져온 것입니다._

이 문제는 하나의 메시지에서 여러 페이로드 생성에 대한 지원만 다루고 있으며 관심이 있을 수 있는 새로운 형식 문제는 https://github.com/TheThingsNetwork/lorawan-stack/issues/1158입니다. 이 문제가 실제로 찾고 있는 문제인지 확인하십시오.

그럼에도 불구하고 이 경우 업링크 내부에서 발견된 디코딩된 정보를 기반으로 여러 페이로드를 생성하는 JSON 형식을 기반으로 하는 새로운 형식을 도입하는 것이 좋습니다.
DecodedPayload 필드의 일부로 관심 있는 필드가 포함되어 있으므로 ApplicationUp_UplinkMessage 업링크 메시지를 구체적으로 처리하는 것이 좋습니다.

이 사용 사례에 대해 proto 파일을 수정할 필요가 없습니다.

나는 여전히 스택의 내부 작업과 코드를 이해하려고 노력하고 있습니다. 현재 저는 #1158이 아닌 이 문제에만 집중하고 있습니다. ApplicationUp_Uplinkmessage 수정을 제안하셨듯이 저는 그것을 알아내려고 노력하고 있습니다. 현재 다음과 같은 질문이 있습니다.
1) ApplicationUplink 구조체와 ApplicationUp_UplinkMessage 함수는 ttnpb 디렉토리의 messages.pb.go 파일에 정의되어 있습니다. 그러나 파일의 헤더에는 "DO NOT EDIT"가 언급되어 있습니다. 무시해야 하나요? 아니면 그것을 수정하는 다른 방법이 있습니까?
2) " introduce a new format, based on the JSON one "에 대해 자세히 설명해 주시겠습니까? 새 형식을 만드는 대신 기존 형식을 수정하면 된다고 생각했습니다.
3) 또한 하나의 결과만 반환되는 결과 래핑에 대해서도 언급했습니다. 정확히 무엇을 할 것인가? 여러 메시지를 하나로 다시 결합하고 하나의 결과만 반환합니까? 그리고 업링크 메시지에 대해서만 그렇게 해야 합니까?

[지속적인 지도를 해주신 @adriansmares 에 감사드립니다. 비록 golang 튜토리얼을 수강했지만, 이것은 GO 언어와의 첫 상호작용입니다.

• 해당 파일이나 *.pb.* 파일을 편집할 필요가 없습니다. mage proto:all 를 실행할 때 *.proto 파일에서 자동으로 생성됩니다. 그럼에도 불구하고 이 문제의 목적을 위해 그러한 수정을 수행할 필요가 없습니다.
• 다른 문제에서 그 내용을 따르십시오.
• 래핑 제안을 통해 기존 코드를 그대로 유지할 수 있습니다(여전히 하나의 업링크 메시지에서 게시할 하나의 페이로드를 반환함).

전체 파이프라인을 더 잘 설명하려고 노력하겠습니다. 아마도 이것이 어떻게 작동하는지에 대한 빛을 비춰줄 것입니다.

1. 장치는 1개의 업링크를 보냅니다.
2. 1 업링크는 게이트웨이에서 수신하여 게이트웨이 서버로 보내 네트워크 서버로 전달한 다음 애플리케이션 서버로 전달합니다. AS에 도달하는 메시지는 *ttnpb.ApplicationUplink 유형입니다.
3. 애즈 디코딩 된 필드에 이진 페이로드를 디코딩하기 위해 1이 개 업 링크 및 시도가 필요합니다 (의 바이트 회전 FRMPayload 의 복호화 구조로 필드 DecodedPayload 디바이스 페이로드 포맷을 이용하여).
4. 그런 다음 *ttnpb.ApplicationUp 로 포장하여 프런트엔드(MQTT, 웹훅, PubSub, 애플리케이션 패키지)로 보냅니다.
5. 프론트엔드는 이 1 *ttnpb.ApplicationUp 수신하고 설정(형식)에 따라 사용할 포맷터를 선택합니다(포맷터 인터페이스는 pkg/applicationserver/io/formatters ).
6. 프론트엔드는 1 *ttnph.ApplicationUp formatter.FromUp 를 호출하고 1 메시지의 본문을 나타내는 바이트 조각( []byte )을 받습니다.

이제 이 문제와 관련하여 6단계에만 변경이 필요하다는 것을 알 수 있기를 바랍니다.

• FromUp 가 여러 페이로드(바이트 조각 조각)를 반환할 수 있도록 인터페이스와 구현의 반환 유형을 변경합니다.
• 기존 Protobuf 및 JSON 형식은 동작을 변경해서는 안 되며 계속해서 1개의 페이로드만 반환해야 합니다(그래서 랩이 필요한 이유).
• [][]byte 를 반환하도록 이 2개(인터페이스 및 포맷터)를 변경하면 오류가 표시되기 시작합니다( FromUp 를 호출하는 대부분의 장소에서는 하나의 페이로드만 수신할 것으로 예상하므로 업데이트해야 합니다. 이러한 호출 사이트는 페이로드 목록을 통해 루프를 만들고 각각을 보냅니다.

동작을 전혀 변경하지 않는 이 문제가 수정된 후에만 각 측정에 대해 하나씩 여러 페이로드 조각을 반환하는 고유한 포맷터를 구현할 수 있습니다(그러나 이 새로운 형식은 이 문제의 범위를 벗어났습니다!).

@adriansmares 의 자세한 설명과 가이드에 감사드립니다. 이제 이 문제를 해결할 수 있었다고 생각합니다. 또한 ./mage go:test js:test jsSDK:test 테스트했는데 오류가 발생하지 않습니다. 코드의 주요 변경 사항은 아래에 강조 표시되어 있습니다.
formatter.go

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
}

protobuf.go
같은 상기와

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
}

피드백과 의견을 보내주십시오. 작업이 완전히 완료되면 코드 스타일 지침에 따라 수정(Var 이름 지정, 들여쓰기 등)을 수행합니다. 이 내용이 정확하다면 #1158 문제에 대해 더 자세히 안내해 주시겠습니까? 다시 한번 감사드립니다.

@mihirr93 잘

@adriansmares 물론입니다. 그렇게 하겠습니다. 해당 pull 요청은 언급된 환경 또는 최신 버전의 스택을 기반으로 해야 합니까?

나중에 충돌을 피하기 위해 최신 master 위에 변경 사항을 다시 적용하는 것이 좋습니다.

이 문제는 꽤 오랫동안 비활성화되었으므로 다시 분류로 이동하여 이에 대한 수요가 있는지 아니면 그냥 삭제해야 하는지 확인하겠습니다.

확장성이 좋지 않기 때문에 더 이상 필요하지 않습니다.