国产午夜视频免费_精品午夜国产_国产欧洲av,寡妇高潮的味道,特级全黄久久久久久久久,久久久亚洲高清

一、概述      上一篇講述了bitmap的端口表示方法，也講了單播只用常規方法表示的原因，故我們只需要對多播的轉發表進行相應的定制和處理即可。單播和多播的地址區分也已在上篇文章中交待清楚，本篇重點講述如何處理多播數據。 二、多播表定義      根據前篇分析，多播表的定義只是將其端口號字段的表述進行了重定義。故多播表的定義只需要將單播表復制一份即可，只是在處理多播數據時，對端口字段的使用有些不一樣。

struct table_port_mac *obx_mc_mac_tbl = NULL;/*定義多播MAC轉發表對象為空指針，將在main函數中初始地址*/
/*為多手播MAC轉發表分配內存，并初始數據為0*/
obx_mc_mac_tbl = (struct table_port_mac *)malloc(sizeof(struct table_port_mac));
memset(obx_mc_mac_tbl,0,sizeof(struct table_port_mac));

三、組播協議      本交換機原型中，我們僅支持IGMP v3版本，故只對該版本協議進行解析處理，對組播的入組與退組處理只需要處理IGMPv3 的Report分組協議即可。
     解析IGMP協議我們需要關心的分組字段如下：
     1）IGMP的組播IP地址為224.0.0.22，多播MAC為：01:00:5E:00:00:16      2）以太網幀類型為IPv4(0x0800)      3）IP協議號為IGMP(0x2)      4）IGMP協議的type字段為0x22(V3 report)      相關的協議數據結構定義在以下幾個系統頭文件中，將其添加到代碼頭部。

#include /*ethhdr*/
#include /*iphdr*/
#include /*igmvp_report*/

四、代碼修改      1）多播解析      多播首先判斷MAC地址的第1字節的最低位，分離出多播分組，然后再精確篩選出組播入組與退組的通告消息。

if(pkt->data[0]&0x1)//MC MAC
{
u64 igmpv3_dmac = 0x1600005E0001;
if(!ether_addr_equal(pkt->data,(u8 *)&igmpv3_dmac)) //IGMP
{
struct ethhdr *eth = (struct ethhdr *)pkt->data;
struct iphdr *ip = (struct iphdr *)(eth+1);
int oft = 0;
if(eth->h_proto = htons(0x0800) && ip->protocol == IPPROTO_IGMP)
{
oft = sizeof(*eth) + ip->ihl * sizeof(int);
igmpv3_report(pkt->um.inport,pkt->data+oft);
}
}
}

     2）多播學習      精確篩選出IGMP的Report分組后，便可根據協議字段區分是入組消息或是退組消息。該步最核心的一步是要將IGMP中的組播IP地址轉換為多播MAC，并將該MAC消息學習到多播MAC轉發表中。多播MAC的轉換規則有明確的定義要求，簡言之就是MAC地址由三部分組成：高24位固定為01:00:5E，第23位為0，低23位為組播IP的低23位。

void igmpv3_report(u8 inport,u8 *igmp)
{
struct igmpv3_report *g3r = (struct igmpv3_report *)igmp;
if(g3r->type == IGMPV3_HOST_MEMBERSHIP_REPORT)/*IGMPv3_REPORT*/
{
u8 mc_mac[MAC_LEN] = {0x01,00,0x5E};
u8 *mcip = NULL;
int k = 0;
for(;kngrec);k++)
{
mcip = (u8 *)&g3r->grec[k].grec_mca;
memcpy(&mc_mac[3],&mcip[1],3);/*僅復制后3字節數據*/
mc_mac[3] &= 0x7F;/*將第23bit置0*/
join_leave_mc_mac(inport,mc_mac,g3r->grec[k].grec_type);
}
}
}

     多播MAC的學習過程封裝在join_leave_mc_mac函數中，其核心操作方法與單播MAC的學習過程類似，只是在對端口號的處理不同。

if(type == IGMPV3_CHANGE_TO_EXCLUDE)/*入組*/
{
obx_mc_mac_tbl->row[i].port |= 1< }
else/*退組*/
{
obx_mc_mac_tbl->row[i].port &= ~ (1< }

     3）多播查表      多播的查表與單播完全一致，只是查表的對象換成多播表，這兩個查表過程可以代碼優化成一個功能函數。      4）多播輸出      多播的輸出端口信息存儲在返回值的每個bit位上，故需要根據輸出端口的bit位是否為1來作為分組輸出判斷依據。單播和多播的統一輸出函數如下：

void output(u8 outtype,int outport,struct fast_packet *pkt)
{
if(outtype == UC)
{
pkt->um.outport = outport;
pkt_send_normal(pkt,pkt->um.len);
}
else
{
int i = 0;
for(;i {
if(pkt->um.inport != i && (outport & (1< 0)
{
pkt->um.outport = i;
pkt_send_normal(pkt,pkt->um.len);
}
}
}
}

     一定要記得，底層API的輸出端口號是常規表示方法，在多播輸出時的端口號應該是變量i的值。 五、總結與下一步      1）確定協議支持      硬件適合做簡單、確定的事情，軟件適合做靈活多變的事情。故若在硬件中支持組播的加入和退出，簡單實現就是支持確定性的IGMPv3協議的Report功能，硬件可以不像軟件一下逐層解析協議，可以直接將對應幾個位置的數據都取出來之后一次判斷，符合要求的消息即可繼續完成后續功能。硬件不如軟件靈活，對每一種確定協議的支持都需要確定的邏輯支撐，所以對于比較復雜的協議交互，一般在要設備中加入輕量級的CPU進行處理。一般像確定的組播協議可以放到FPGA實現，而生成樹協議不適合FPGA實現。      2）MAC表的老化      老化簡單來說就是刪除長時間不使用的表項，把空間留出來給新的MAC地址使用。老化是為了解決MAC地址數量大于轉發表空間容量的問題。若有些MAC地址使用一段時間之后，就一直不再使用或關機，則交換機無需再保留其在MAC轉發表中。若不刪除，則會導致新的MAC表找不到存儲空間，導致大量的數據轉化為泛洪發送，對整個網絡來說是災難性的，不可容忍的。當然，不計成本的擴大存儲容量更是不可取的。故MAC表的老化是十分必要的，下篇主要內容講述MAC表老化。 六、結語       歡迎您和學生們加入FAST開源項目群溝通與探討，一起體驗不一樣的系統設計過程。請先加微信號15116127200后邀請入群。