基于视频压缩的实时监控系统-A4:main.c代码解析

本文介绍了一种基于Epoll的事件驱动机制实现方法,通过自定义结构体扩展Epoll的功能,实现了事件的创建、添加、删除等操作,并展示了如何在主循环中处理不同类型的事件。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

#include <main.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/epoll.h>
#include <sys/stat.h>
#include <stdbool.h>

//为epoll_event 结构体附加一个结构体
struct event_ext
{
	int fd;
	bool epolled;
	uint32_t events;
	void (*handler) (int fd,void *arg);
	void *arg;
};

/*
*函数功能:创建一个事件附加结构
*/
struct event_ext *epoll_event_creat(int fd,uint32_t type,void (*handler)(int,void*),void *arg)
{
	struct event_ext *e;
	e = calloc(1,sizeof(struct event_ext));    //为结构体分配空间

	e->fd = fd;                               //初始化结构体
	e->events = type;
	e->handler = handler;
	e->arg = arg;
	return e;
}

/*
*函数功能:添加事件到epoll
*/
int epoll_add_event(int epfd,struct event_ext *ev)
{
	struct epoll_event epv;
	int op;

	//初始化epoll_event,并将附加结构挂载在epoll_event 
	epv.data.ptr = ev;
	epv.events = ev->events;
	if(ev->epolled)            //true    修改事件
		{
			op = EPOLL_CTL_MOD;
		}
	else                      //false   添加事件
       {		
	   		op = EPOLL_CTL_ADD;    
	   		ev->epolled = true;
	   }	
	//将epoll_event 加入 epoll池
	epoll_ctl(epfd,op,ev->fd,&epv);
}

/*
*函数功能:从epoll删除事件
*/
int epoll_del_event(int epfd,struct event_ext *ev)
{
	epoll_ctl(epfd,EPOLL_CTL_DEL,ev->fd,NULL);
	ev->epolled = false;
	return 0;
}
int main()
{
	int fds;
	int i;
	struct epoll_event events[512];
	uint32_t event;
	struct event_ext *e;
	//分配空间
	srv_main = calloc(1,sizeof(struct server));
	//创建epoll
	srv_main->epfd = epoll_create(512);
	//加入事件
	srv_main->cam = cam_sys_init();
    srv_main->srv = net_sys_init();
	//等待事件发生且处理
	while(1)
	{
		fds = epoll_wait(srv_main->epfd,events,512,1000);    //等待1000ms
		for(i=0;i<fds;i++)
		{
			event = events[i].events;
			e =  events[i].data.ptr;
			if(event & EPOLLIN)
			{
				e->handler(e->fd,e->arg);

			}
			if(event & EPOLLOUT)
			{
				e->handler(e->fd,e->arg);

			}
			if(event & EPOLLERR)
			{
				e->handler(e->fd,e->arg);

			}

		}

	}
	return -1;
}

mpeg4编码库源代码,C++完整源代码,有需要饿同学尽管拿去。 // This is the header file describing // the entrance function of the encoder core // or the encore ... #ifdef __cplusplus extern "C" { #endif typedef struct _ENC_PARAM_ { int x_dim; // the x dimension of the frames to be encoded int y_dim; // the y dimension of the frames to be encoded float framerate;// the frame rate of the sequence to be encoded long bitrate; // the bitrate of the target encoded stream long rc_period; // the intended rate control averaging period long rc_reaction_period; // the reation period for rate control long rc_reaction_ratio; // the ratio for down/up rate control long max_key_interval; // the maximum interval between key frames int max_quantizer; // the upper limit of the quantizer int min_quantizer; // the lower limit of the quantizer int search_range; // the forward search range for motion estimation } ENC_PARAM; typedef struct _ENC_FRAME_ { void *image; // the image frame to be encoded void *bitstream;// the buffer for encoded bitstream long length; // the length of the encoded bitstream } ENC_FRAME; typedef struct _ENC_RESULT_ { int isKeyFrame; // the current frame is encoded as a key frame } ENC_RESULT; // the prototype of the encore() - main encode engine entrance int encore( unsigned long handle, // handle - the handle of the calling entity, must be unique unsigned long enc_opt, // enc_opt - the option for encoding, see below void *param1, // param1 - the parameter 1 (its actually meaning depends on enc_opt void *param2); // param2 - the parameter 2 (its actually meaning depends on enc_opt // encore options (the enc_opt parameter of encore()) #define ENC_OPT_WRITE 1024 // write the reconstruct image to files (for debuging) #define ENC_OPT_INIT 32768 // initialize the encoder for an handle #define ENC_OPT_RELEASE 65536 // release all the resource associated with the handle // return code of encore() #define ENC_OK 0 #define ENC_MEMORY 1 #define ENC_BA
逐行解析一下root@ImmortalWrt:~# tcpdump -i br-lan -nn 'arp' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes 23:39:17.345552 ARP, Request who-has 192.168.2.1 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.346296 ARP, Reply 192.168.2.1 is-at a4:a9:30:cd:d2:4c, length 46 23:39:17.346434 ARP, Request who-has 192.168.2.160 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.350042 ARP, Request who-has 192.168.2.13 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.350302 ARP, Reply 192.168.2.13 is-at 00:0c:29:c3:6f:66, length 46 23:39:17.353640 ARP, Request who-has 192.168.2.11 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.353958 ARP, Reply 192.168.2.11 is-at 00:0c:29:b3:d9:93, length 46 23:39:17.355578 ARP, Request who-has 192.168.2.12 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.355847 ARP, Reply 192.168.2.12 is-at b8:97:5a:eb:2b:49, length 46 23:39:17.476310 ARP, Request who-has 192.168.2.182 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.478113 ARP, Request who-has 192.168.2.201 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.483021 ARP, Request who-has 192.168.2.214 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.485643 ARP, Request who-has 192.168.2.234 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.490919 ARP, Reply 192.168.2.160 is-at 54:ef:44:46:85:9a, length 46 23:39:17.493686 ARP, Reply 192.168.2.182 is-at 54:ef:44:46:67:92, length 46 23:39:17.496285 ARP, Reply 192.168.2.214 is-at 38:00:25:8a:8f:04, length 46 23:39:18.478162 ARP, Request who-has 192.168.2.201 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:18.485684 ARP, Request who-has 192.168.2.234 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28
03-17
<think>嗯,用户让我帮忙解析一个tcpdump抓取的ARP请求和响应的输出。之前他已经问过关于网络中几个设备(旁路由、Home Assistant、美的空调)的ARP交互,现在他提供了一个具体的tcpdump输出,想要逐行解析。看起来他可能是在排查网络问题,或者想更深入了解网络中的设备通信情况。 首先,我需要回忆一下ARP协议的基本工作原理,ARP请求是广播的,而响应是单播的。在给出的输出中,有很多ARP请求和回复,都是由IP地址192.168.2.2(旁路由)发起的。用户可能想知道为什么旁路由会发送这么多ARP请求,或者是否存在网络问题,比如某些设备没有响应,或者是否有IP冲突。 接下来,我需要逐行分析每个ARP包的时间戳、类型(请求或回复)、源IP和目标IP,以及对应的MAC地址。需要注意的是,有些请求可能没有收到回复,比如192.168.2.201和234,可能在后续的时间点重复请求,这说明这些设备可能离线或存在网络问题。 用户之前的对话中提到了旁路由作为网关,可能负责处理NAT和防火墙规则,所以旁路由频繁发送ARP请求可能是因为它在维护ARP缓存,或者有流量需要经过它转发到这些IP地址。需要检查是否有设备配置了静态ARP条目,或者是否有异常的网络流量导致旁路由不断查询MAC地址。 此外,用户可能关心这些ARP请求是否正常,或者是否存在ARP欺骗攻击。比如,是否有多个不同的MAC地址响应同一个IP,但在这个输出里,每个回复都是唯一的,没有冲突。不过,用户提供的输出中有部分请求没有立即得到回复,可能需要进一步确认这些设备是否存在。 另外,用户可能想知道如何优化网络,减少不必要的ARP流量,比如设置静态ARP条目或者调整ARP缓存超时时间。在之前的回复中,我提到了静态ARP绑定的方法,用户可能需要进一步的指导来实施这些优化措施。 最后,总结部分需要指出可能的网络问题,比如未响应的设备,以及给出排查建议,比如检查设备状态、IP冲突、防火墙设置等。同时,提醒用户注意网络性能和安全,比如ARP欺骗的可能性,建议使用监控工具持续观察。</think>#### 逐行解析`tcpdump` ARP抓包记录 --- ##### **命令行解析** ```shell root@ImmortalWrt:~# tcpdump -i br-lan -nn 'arp' ``` - `-i br-lan`:监听桥接局域网接口`br-lan` - `-nn`:禁用主机名和端口号解析(直接显示IP和MAC地址) - `'arp'`:过滤仅捕获ARP协议流量 --- ##### **输出内容解析** 1. **全局信息** ``` tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes ``` - 抓包环境为以太网(`EN10MB`) - 默认禁用详细输出(可通过`-v`或`-vv`开启) - 抓包缓存大小为262144字节(用于减少丢包) --- 2. **具体数据包分析** **(1) ARP请求-响应对** ```plaintext 23:39:17.345552 ARP, Request who-has 192.168.2.1 (ff:ff:ff:ff:ff:ff) tell 192.168.2.2, length 28 23:39:17.346296 ARP, Reply 192.168.2.1 is-at a4:a9:30:cd:d2:4c, length 46 ``` - **请求**:IP `2.2`(旁路由)广播(MAC全`f`)询问`2.1`的MAC地址 - **响应**:`2.1`回复其MAC为`a4:a9:30:cd:d2:4c` - **长度差异**:请求包28字节(最小ARP帧),响应包46字节(包含完整以太网头部) **(2) 未立即响应的请求** ```plaintext 23:39:17.346434 ARP, Request who-has 192.168.2.160 ... tell 192.168.2.2 23:39:17.490919 ARP, Reply 192.168.2.160 is-at 54:ef:44:46:85:9a ``` - **延迟响应**:请求`2.160`后约144ms收到响应(可能因设备处理延迟或网络拥塞) **(3) 重复请求模式** ```plaintext 23:39:17.478113 ARP, Request who-has 192.168.2.201 ... 23:39:18.478162 ARP, Request who-has 192.168.2.201 ... ``` - **重传机制**:`2.201`在1秒内未响应,触发旁路由重传ARP请求(典型ARP缓存超时机制) **(4) 关键设备交互** ```plaintext 23:39:17.353640 ARP, Request who-has 192.168.2.11 ... # Home Assistant 23:39:17.353958 ARP, Reply 192.168.2.11 is-at 00:0c:29:b3:d9:93 ``` - 旁路由`2.2`与Home Assistant(`2.11`)建立通信链路 --- ##### **网络行为诊断** 1. **旁路由的主动探测** - `2.2`密集发送ARP请求,可能是以下原因: - 维护ARP缓存表(定期刷新) - 处理NAT转发时需确认目标设备在线状态 - 网络扫描行为(如DHCP服务探测) 2. **未响应设备** - `2.201`和`2.234`的请求未显示响应(可能设备离线或防火墙丢弃) 3. **MAC地址特征** - `00:0c:29:xx:xx:xx`:VMware虚拟网卡地址(可能为虚拟机设备) - `54:ef:44:xx:xx:xx`:美的空调OUI(厂商标识) --- ##### **排查建议** 1. **检查未响应设备** - 使用`ping 192.168.2.201`测试连通性 - 确认设备是否启用ARP协议(某些IoT设备可能限制ARP响应) 2. **分析旁路由行为** ```shell # 查看ARP缓存表 arp -n # 监控ARP请求频率 tcpdump -i br-lan -nn 'arp and src host 192.168.2.2' ``` 3. **优化策略** - 对关键设备(如Home Assistant)设置静态ARP绑定: ```shell arp -s 192.168.2.11 00:0c:29:b3:d9:93 ``` - 调整ARP缓存超时时间(默认20分钟): ```shell sysctl -w net.ipv4.neigh.default.gc_stale_time=1800 ``` --- 通过此抓包分析,可以清晰观察到局域网内设备的ARP交互模式。若需进一步诊断,建议结合`Wireshark`进行协议层级分析。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值