[發明專利]一種組播通信方法及組播通信設備

在審

• 申請號: 202010852223.6
• 申請日: 2020-08-21
• 公開（公告）號: CN112039793A
• 公開（公告）日: 2020-12-04
• 發明（設計）人: 李松華
• 申請（專利權）人: 烽火通信科技股份有限公司
• 主分類號: H04L12/801
• 分類號: H04L12/801;H04L1/16;H04L1/18
• 代理公司: 武漢智權專利代理事務所(特殊普通合伙) 42225
• 代理人: 邱云雷

本發明公開了一種組播通信方法及組播通信設備，涉及通信技術領域，用于實現通信設備卡間和堆疊設備間的信息同步，該方法包括以下步驟：對需要進行信息同步的對象通過系統號和線卡號進行標識。發送端學習接收端的標識信息，發送包含目的系統號和目的線卡號的數據包。接收端接收數據包，并判斷是否返回確認包；發送端判斷是否收到所有需返回的確認包，若是，則標記通信結果成功。本發明中的組播通信方法能解決通信時延過長以及帶寬和CPU資源占用過多的問題。

技術領域

本發明涉及通信技術領域，具體涉及一種組播通信方法及組播通信設備。

背景技術

在通信設備中主用主控與備用主控之間、主用主控與業務線卡之間以及堆疊場景下不同設備的主用主控之間均有信息同步的要求。

而現有技術是通過單播方式逐一向通信設備內線卡(主用主控和備用主控本質上也是線卡)或堆疊成員設備內線卡進行配置下發、動態表項同步，這樣會造成以下問題：一是通信延時過長，不能滿足上層應用對通信時延的要求。比如，CFM(Connectivity FaultManagement，連接故障管理)、BFD(Bidirectional Forwarding Detection，雙向轉發檢測)等快速檢測協議超時時間最大為秒級，如果這些操作通信延時過長就會導致這些協議超時、斷鏈，影響業務。二是管理通道帶寬占用，尤其是在大路由/ARP/MAC地址等表項的瞬時刷新的情況下會導致管理通道帶不足，產生丟包、重傳。三是過多占用CPU資源，多次單播數據的發送會占用CPU資源，讓有限的CPU資源無法處理更高優先級的事件，進而導致業務中斷。

發明內容

針對現有技術中存在的缺陷，本發明第一方面在于提供一種能解決通信時延過長以及帶寬和CPU資源占用過多的組播通信方法。

為達到以上目的，本發明采取的技術方案是：

一種組播通信方法，用于實現通信設備卡間和堆疊設備間的信息同步，該方法包括以下步驟：

對需要進行信息同步的對象通過系統號和線卡號進行標識；

發送端學習接收端的標識信息，發送包含目的系統號和目的線卡號的數據包；

接收端接收數據包，并判斷是否返回確認包；

發送端判斷是否收到所有需返回的確認包，若是，則標記通信結果成功。

一些實施例中，所述接收端接收數據包，并判斷是否返回確認包，具體包括：

接收端判斷數據包中的目的系統號和目的線卡號是否包括自身，若是，則返回確認包，否則丟棄。

一些實施例中，所述發送端還記錄所發送的目的系統號和目的線卡號信息，以用于失敗重傳。

一些實施例中，所述發送端發送包含目的系統號和目的線卡號的數據包時，還啟動等待接收端回應的定時器，并為定時器設置最大重發次數，若發送端未收到所有需返回的確認包，當定時器超時且重發次數小于最大重發次數時，發送端繼續對未返回確認包的對象進行數據重發，當定時器超時且重發次數大于最大重發次數時，標記通信結果失敗。

一些實施例中，所述方法還包括：

當發送端收到接收端返回的一確認包時，根據該確認包中記載的線卡號，刪除所記錄的對應的目的線卡號信息。

一些實施例中，所述方法還包括：

當發送端收到所有需返回的確認包時，取消定時器，標記通信結果為成功。

一些實施例中，所述發送端通過線卡位圖標示需要接收數據包的對象，并通過相應的位圖值指明該對象的線卡號。

本發明第二方面在于提供一種能解決通信時延過長以及帶寬和CPU資源占用過多的組播通信方法。