为什么解析1939can协议协议获得的数据不全

21ic官方微信-->
后使用快捷导航没有帐号?
请完成以下验证码
查看: 11773|回复: 36
请教一下 串口协议数据的几种处理方法
&&已结帖(10)
主题帖子积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
主题帖子积分
专家等级:结帖率:87%
主题帖子积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
我们知道,串口的协议数据一般包括 帧头+地址+功能码+校验码+数据+帧尾 等组成。
请教一下,大家平时是怎么处理串口协议的呢,我用过的方法有两种,第三种方法听别人说过,但不知道具体是怎么样的实现思路。
第一种:超时判断,思路就是每在接收到串口数据,进入接收中断后,保存数据,并赋值一个变量,然后该变量的值在定时器里面自减,若自减到零说明对方数据传送完成,由此可判断接收完成,下一步就是在主程序里处理串口数据了。
这种办法现在基本不使用。
第二种:在接收中断里逐级判断,只有一级一级的数据判断正确,才进行接收,最后再判断校验码和帧尾,只有整个过程的数据都正确,才能确定数据接收完成,此时置位一个标志位,在主程序里处理通过此标志位执行相应程序。
现在我一直用的就是这种方法,但这种方法很容易有一种限制,就是只能一帧一帧的处理数据,就是说对方发了一帧数据后,下一帧数据要间隔一段时间(如10MS)再发送,如果两帧或以上的数据一起发送,第二种处理方法就会产生错误。
第三种:我也是听人说过,就是可以解决第二种只能一帧一帧接收数据的问题,具体的实现思路我也不清楚,只能分别简单描述一下,第三种方法也是我上来发帖请教的目的。
这种处理方法就是开辟一个相对较大的数组用于存放接收到的数据,接收程序只管接收数据,若接收到的数据到达数组尾端,下一个接收到的数据又会从数组头开始存放,即会把之前存放的数据覆盖掉。
在主程序里,不断扫描数组里面存放的数据,搜索里面的功能协议,每一条协议都要从数组里搜索一遍,每次循环都要这样做。我的疑问是怀疑自己理解错了,要是这样的话,单单搜索协议都要耗费大量的CPU时间,貌似不太现实。
请教一下各位大侠,是怎么处理多帧数据同时传输的问题的呢?
, , , , , , ,
满意回复+1
中断接收只往缓冲内写数据,主程序从缓冲取数据,按照协议合并成完整的帧。基本思路就是这样
把你的 第二种 接收中断里逐级判断,只有一级一级的数据判断正确 放在主程序里取缓冲数据之后。就是常用的做法 ...
用MODBUS,只需要用到位读写,字节读写,就四五条协议,位和字节都有对应的地址,你把“什么设置时间、设置状态、返回时间、返回计数结果等等”和地址对应起来, ...
缓冲区不需要很大。保证2次处理期间的数据不漏就行了
你有必要先了解一下协议分层。
我就用的第一种方法,个人看法如下:
1:第一种方法主要适用于变字长帧接收,缺点是要占用一个定时器(两字节间隔超过4个字节时间即认为一帧传输完毕);
对于一般单片机主要是用于控制用途,第二种是最实用的,它一般都采用半双工,请求/应答式通讯,对应的单片机以单任务的方式在运行(至少有通讯需求的部分是单任 ...
第三种方法就是用环形缓冲+状态机+时间轮询来解析传输协议的
下一个接收到的数据又会从数组头开始存放,即会把之前存放的数据覆盖掉。
这说明缓冲区太小了,改大就可以了...
接收完再一帧一帧处理... ...
去查一下freemodbus
一般用第三种,上面已经有朋友说了,fifo+fsm主循环解析
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
中级技术员, 积分 198, 距离下一级还需 102 积分
中级技术员, 积分 198, 距离下一级还需 102 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
中级技术员, 积分 198, 距离下一级还需 102 积分
中级技术员, 积分 198, 距离下一级还需 102 积分
中断接收只往缓冲内写数据,主程序从缓冲取数据,按照协议合并成完整的帧。基本思路就是这样
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
中级技术员, 积分 198, 距离下一级还需 102 积分
中级技术员, 积分 198, 距离下一级还需 102 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
中级技术员, 积分 198, 距离下一级还需 102 积分
中级技术员, 积分 198, 距离下一级还需 102 积分
把你的 第二种 接收中断里逐级判断,只有一级一级的数据判断正确 放在主程序里取缓冲数据之后。就是常用的做法
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
主题帖子积分
专家等级:结帖率:87%
主题帖子积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
你好,如果像你说的那样,在主程序里搜索接收缓冲区,这样我就有几个疑问:
1、这样做的方法,接收中断只管接收,并不会置什么接收完成的标志位,这样就会导致:在主程序里的搜索程序是每次循环必然会执行到的。
举个例子,如果接收缓冲区比较大(对于51单片机来说),有几K,然后有几十条协议,什么设置时间、设置状态、返回时间、返回计数结果等等。那搜索程序是不是要从第一条协议开始,从接收缓冲区的头开始搜索,如果从头到尾都没搜索到第一条协议,那又从第二条协议,从接收缓冲区的头开始一直搜索……一直到最后一条协议搜索完……从下一次循环,又开始反复上面的过程呢?
那这样是不是像我上面说的,耗费了大量的CPU时间呢……
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
技术达人, 积分 9819, 距离下一级还需 181 积分
技术达人, 积分 9819, 距离下一级还需 181 积分
主题帖子积分
专家等级:结帖率:100%打赏:0.00受赏:7.36
主题帖子积分
技术达人, 积分 9819, 距离下一级还需 181 积分
技术达人, 积分 9819, 距离下一级还需 181 积分
用MODBUS,只需要用到位读写,字节读写,就四五条协议,位和字节都有对应的地址,你把“什么设置时间、设置状态、返回时间、返回计数结果等等”和地址对应起来,再多功能都够了
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
中级技术员, 积分 198, 距离下一级还需 102 积分
中级技术员, 积分 198, 距离下一级还需 102 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
中级技术员, 积分 198, 距离下一级还需 102 积分
中级技术员, 积分 198, 距离下一级还需 102 积分
缓冲区不需要很大。保证2次处理期间的数据不漏就行了
你有必要先了解一下协议分层。
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
高级技术员, 积分 608, 距离下一级还需 392 积分
高级技术员, 积分 608, 距离下一级还需 392 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
高级技术员, 积分 608, 距离下一级还需 392 积分
高级技术员, 积分 608, 距离下一级还需 392 积分
我就用的第一种方法,个人看法如下:
1:第一种方法主要适用于变字长帧接收,缺点是要占用一个定时器(两字节间隔超过4个字节时间即认为一帧传输完毕);
2:如果数据帧是定字长,那么你最好使用你的第二种方法
3:第三种实际就是以上两种的延伸,主要适用于通信速率繁忙的状况下,你可以开辟多个变量记录每帧的字长,循环处理存放数据即可,内部RAM够大不怕浪费你可以使用多缓存数组+状态机处理
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
助理工程师, 积分 1767, 距离下一级还需 233 积分
助理工程师, 积分 1767, 距离下一级还需 233 积分
主题帖子积分
专家等级:结帖率:100%
主题帖子积分
助理工程师, 积分 1767, 距离下一级还需 233 积分
助理工程师, 积分 1767, 距离下一级还需 233 积分
对于一般单片机主要是用于控制用途,第二种是最实用的,它一般都采用半双工,请求/应答式通讯,对应的单片机以单任务的方式在运行(至少有通讯需求的部分是单任务性质)。第三种采用通讯缓冲区,对于需要大数据量交换,多任务或多线程应用意义重大,同时,程序的复杂性也增加很多。但是如果你的单片机应用仍然是单任务请求/应答式,这种方式意义不大,仅仅只是节约了数据本身的传输时间,而在控制用途的场合,尤其是链路不稳定情况下,如简单的无线通讯,如何保证通讯的正确性远比数据传输速度重要的多。
第三种方式的缓冲区一般需要FIFO,既环形缓冲器,分别有读写指针。希望这个可以回答你四楼的问题。
为什么说第三种程序要复杂很多呢,举一个例子,你考虑一个通讯出错以后重传的问题就明白了。可不是重新发一次就行的哦。
最后要说的是,通讯协议够用就好,不是貌似功能越强大越好。即使优秀如USB,也把传输模式分成了四种以应对不同情况。
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
实习生, 积分 12, 距离下一级还需 38 积分
实习生, 积分 12, 距离下一级还需 38 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
实习生, 积分 12, 距离下一级还需 38 积分
实习生, 积分 12, 距离下一级还需 38 积分
第三种方法就是用环形缓冲+状态机+时间轮询来解析传输协议的
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
实习生, 积分 12, 距离下一级还需 38 积分
实习生, 积分 12, 距离下一级还需 38 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
实习生, 积分 12, 距离下一级还需 38 积分
实习生, 积分 12, 距离下一级还需 38 积分
第三种方法就是用环形缓冲+状态机+时间轮询来解析传输协议的
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
主题帖子积分
专家等级:结帖率:87%
主题帖子积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
谢谢指教!如你所说,目前我确实只用到了单任务的通讯协议,但随着知识点的积累,我觉得有必要进行进一步的学习和了解,虽然目前也许用不上第三种方法,但我感觉,只要是做这方面技术的,以后会有用上的一天的。。。
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
主题帖子积分
专家等级:结帖率:95%打赏:9.18受赏:100.00
主题帖子积分
下一个接收到的数据又会从数组头开始存放,即会把之前存放的数据覆盖掉。
这说明缓冲区太小了,改大就可以了...
接收完再一帧一帧处理...
21ic公开课,21ic网友共同的学习圈子!
主题帖子积分
高级工程师, 积分 7012, 距离下一级还需 988 积分
高级工程师, 积分 7012, 距离下一级还需 988 积分
主题帖子积分
专家等级:结帖率:100%
主题帖子积分
高级工程师, 积分 7012, 距离下一级还需 988 积分
高级工程师, 积分 7012, 距离下一级还需 988 积分
去查一下freemodbus
主题帖子积分
高级技术员, 积分 990, 距离下一级还需 10 积分
高级技术员, 积分 990, 距离下一级还需 10 积分
主题帖子积分
专家等级:结帖率:66%
主题帖子积分
高级技术员, 积分 990, 距离下一级还需 10 积分
高级技术员, 积分 990, 距离下一级还需 10 积分
一般用第三种,上面已经有朋友说了,fifo+fsm主循环解析
三人行,必有我师。
技术道路上点滴记录,欢迎访问我的blog:
http://blog.csdn.net/power_mcu
主题帖子积分
资深工程师, 积分 13140, 距离下一级还需 6860 积分
资深工程师, 积分 13140, 距离下一级还需 6860 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
资深工程师, 积分 13140, 距离下一级还需 6860 积分
资深工程师, 积分 13140, 距离下一级还需 6860 积分
中断只做两件事:接收数据进缓冲,清零超时计数器
void& & UartInterrupt(void)
& &&&......
& &&&Rec.OverTime=0;
& &&&if(Rec.Counter&REC_BUFFER_LENGTH)
& && &&&Rec.Buffer[Rec.Counter++] = D
后台程序,10ms执行1次。注:Rec.OverTime为4字节整形,永远不会溢出
void& & TaskUartRec(void)
& && & if(++Rec.OverTime != 2)& && &&&// 超时20ms
& && & ......&&//&&接收处理程序,扫描帧头,可做贴包处理
帧头 + 校验 + 命令 + 方向 + 流水号 + 保留 + 长度 + 数据
帧头为2字节或4字节
其中方向、流水号、保留等可选,也可为其它内容。长度为数据段长度
很多人喜欢把校验放最后面,对前面所有字节进行校验。其实这样不好,校验的位置不定,增加程序的复杂性。&&
而校验放在帧头后面,固定位置,程序更简单,使用结构就简单多了。只对校验字后面的数据进行校验就可以了,帧头为固定内容,没必要校验。
车恋网,让生活充满梦想!
车摩斯,伴您安驾驶!
主题帖子积分
资深技术员, 积分 494, 距离下一级还需 6 积分
资深技术员, 积分 494, 距离下一级还需 6 积分
主题帖子积分
专家等级:结帖率:85%
主题帖子积分
资深技术员, 积分 494, 距离下一级还需 6 积分
资深技术员, 积分 494, 距离下一级还需 6 积分
中断只做两件事:接收数据进缓冲,清零超时计数器
void& & UartInterrupt(void)
& &&&......
& &&&Rec.OverTime=0;
& &&&if(Rec.Counter
汽车电子 发表于
这样对单任务是没有问题,比如说从GPS接收时间信息
假设下这种情况:在一个系统里有大量的广播信息(发的比较快)
那么这时候缓冲内的数据就会被冲掉,怎么办?
这时候我就在中断内进行帧鉴别然后导出有效内容到全局变量传递给主程序
但是这样会让中断程序显得比较大,而且用了全局变量很多个,看着很不爽
看了上面的帖子还是没太搞明白,有没有好的方法同时解决这2个问题。
我知道FIFO应该是可以的,但是那个东西我觉得又太复杂了些
因为我在FPGA里自己写异步FIFO的时候对写和读指针的判断就感觉很麻烦
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
助理工程师, 积分 1130, 距离下一级还需 870 积分
助理工程师, 积分 1130, 距离下一级还需 870 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
助理工程师, 积分 1130, 距离下一级还需 870 积分
助理工程师, 积分 1130, 距离下一级还需 870 积分
我用第一种&&我觉得简单好用的。
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
主题帖子积分
专家等级:结帖率:87%
主题帖子积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
助理工程师, 积分 1027, 距离下一级还需 973 积分
对于15楼汽车电子的方法,我感觉跟我说的第一种方法如出一辙,因为只有接收到数据才会把Rec.OverTime清零,主程序才会执行到接收处理程序,否则,只要Rec.OverTime不翻转,接收处理程序永远不会执行到的。
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
主题帖子积分
资深工程师, 积分 13140, 距离下一级还需 6860 积分
资深工程师, 积分 13140, 距离下一级还需 6860 积分
主题帖子积分
专家等级:结帖率:0%
主题帖子积分
资深工程师, 积分 13140, 距离下一级还需 6860 积分
资深工程师, 积分 13140, 距离下一级还需 6860 积分
开个几KB的DMA缓冲,是最爽爽的了。
DMA超时中断,就取全部数据
电脑串口通常开32KB缓冲
车恋网,让生活充满梦想!
车摩斯,伴您安驾驶!
主题帖子积分
资深技术员, 积分 494, 距离下一级还需 6 积分
资深技术员, 积分 494, 距离下一级还需 6 积分
主题帖子积分
专家等级:结帖率:85%
主题帖子积分
资深技术员, 积分 494, 距离下一级还需 6 积分
资深技术员, 积分 494, 距离下一级还需 6 积分
16# lxc806705&&
对于15楼汽车电子的方法,我感觉跟我说的第一种方法如出一辙,因为只有接收到数据才会把Rec.OverTime清零,主程序才会执行到接收处理程序,否则,只要Rec.OverTime不翻转,接收处理程序永远不会执 ...
sfesdm 发表于
20:14 恩这种方法就是循环缓冲我理解的对吧?但这样无法解决想要得到的报文被其他报文
冲掉的问题;如果用第二种方法在中断中对帧进行判别处理,又会写出较长的程序,占用
较长的中断时间,这样会不会对主程序造成影响?
21ic公开课,21ic网友共同的学习圈子!学单片机、嵌入式、模拟、电源……就看这里
移步更多21ic独家微课:
技术奇才奖章
人才类勋章
时间类勋章
甘甜之泉水
发帖类勋章
希望之星奖章
等级类勋章
技术高手奖章
人才类勋章
突出贡献奖章
等级类勋章
沉静之湖泊
发帖类勋章
时间类勋章
技术导师奖章
人才类勋章
坚毅之洋流
发帖类勋章
时间类勋章
核心会员奖章
等级类勋章
技术领袖奖章
人才类勋章
无冕之王奖章
等级类勋章
奔腾之江水
发帖类勋章
时间类勋章
时间类勋章
涓涓之细流
发帖类勋章
技术新星奖章
人才类勋章
社区建设奖章
等级类勋章11029人阅读
Network Security(12)
MIME协议分析
第1章.MIME
MIME, &Multipurpose Internet Mail Extensions&, &&RFC RFC1521RFC1522
MIMESMTPRFC822
第2章.MIME
<font face="楷体_GB.改进措施
SMTPRFC822SMTP
<font face="楷体_GB.一封简单邮件的源码
MIME... ... ... ...
&& 1 From: &bhw98& &&
&& 2 Reply-To:
&& 3 To: &&
&& 4 Subject: Re: help
&& 5 X-Mailer: Foxmail 4.2 [cn]
&& 6 Mime-Version: 1.0
&& 7 Content-Type: multipart/
&& 8& boundary=&=====002_Dragon_=====&
& 11 This is a multi-part message in MIME format.
& 13 --=====002_Dragon_=====
& 14 Content-Type: text/ charset=&GB2312&
& 15 Content-Transfer-Encoding: quoted-printable
& 17 bluesky7810=A3=AC=C4=FA=BA=C3=A3=A1
& 19 =A1=A1=A1=A1=D4=DA=CF=C2=C6=AA=D7=EE=BA=F3=BF=C9=D2=D4=CF=C2=D4=D8=B0=A1=A3=AC=C4=E3
&&&& ... ...& ... ...
& 30 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1
& 32 --=====002_Dragon_=====
& 33 Content-Type: text/ charset=&GB2312&
& 34 Content-Transfer-Encoding: quoted-printable
& 36 &!DOCTYPE HTML PUBLIC &-//W3C//DTD HTML 4.0 Transitional//EN&&
& 37 &HTML&&HEAD&
& 38 &META content=3D&text/ charset=3Dgb2312&=
& 39& http-equiv=3DContent-Type&
& 40 &META content=3D&MSHTML 5.00.2920.0& name=3DGENERATOR&
&&&& ... ...& ... ...
& 79 &/HTML&
& 81 --=====002_Dragon_=====--
<font face="楷体_GB.邮件头
MIME: 27-8
各级邮件服务器
Return-Path
目标邮件服务器
Delivered-To
目标邮件服务器
邮件的创建者
发件人地址
邮件的创建者
收件人地址
邮件的创建者
邮件的创建者
邮件的创建者
日期和时间
邮件的创建者
邮件的创建者
Message-ID
邮件的创建者
MIME-Version
邮件的创建者
Content-Type
内容的类型
邮件的创建者
Content-Transfer-Encoding
内容的传输编码方式
邮件的创建者
1 邮件头中常见的域
X-X-Mailer, X-MSMail-Priority
Content-Type
Content-TypeCotent-Type/text, image, audio, video, application, multipart, messagetextplain, html, xml, cssX-IANAapplication/x-zip-compressedZIPWindowsHKEY_CLASSES_ROOT/MIME/Database/Content TypemultipartContent-Type
application
2 常见类型的参数
Content-Transfer-Encoding
Content-Transfer-Encoding
Content-Transfer-EncodingBase64, Quoted-printable, 7bit, 8bit, Binary7bitASCIIASCIIBase64, Quoted-PrintableBinaryBase64Quoted-PrintableRFCSMTP
8bit8bitBase64Quoted-printable
<font face="楷体_GB.邮件体
Content-Typetext/plain()text/html()
multipartMIMEmultipartmultipart/mixed, multipart/relatedmultipart/alternative 1
+------------------------- multipart/mixed ----------------------+&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& |& +----------------- multipart/related -------------+&&&&&&&&&&& |&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&|& |&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& |&&&&&&&&&&& |&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& |& |&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& |&&&&&&&&&&& |
|& |& +----multipart/alternative ---+& +----------+& |& +------+& |& |& |& |&&&&&&&&&&&&&&&&&&&&&&&&&&&& |& | 内嵌资源 |& |& | 附件 |& |& | &|& |& +-----------+ +----------+ | &+----------+& |& +------+& |
|& |& |& | 纯文本正文| |超文本正文| |&&&&&&&&&&&&&&& |&&&&&&&&&&& |
|& |& |& +-----------+ +----------+ |& +----------+& |& +------+& |
|& |& |& &&&&&&&&&&&&&&&&&&&&&&&&&&&|& | 内嵌资源 |& |& | 附件 |& |& |& |& +-----------------------------+& +----------+& |& +------+& |
|& |&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& |&&&& &&&&&&&|&&&&&&&&&&& |& +-------------------------------------------------+&&&&& &&&&&&|&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&+-----------------------------------------------------------------+
邮件体的层次关系图
multipart/mixedmultipart/relatedmultipart/alternativemultipart/relatedmultipart/mixed
multipartboundary--+boundary--+boundary+--multipart(--+boundary)
boundarymultipart 10-1213-82multipart/alternative13-3032-79
Content-Type
段体的类型
Content-Transfer-Encoding
段体的传输编码方式
Content-Disposition
段体的安排方式
Content-ID
Content-Location
段体的位置(路径)
Content-Base
段体的基位置
3 段头中常见的域
<font face="楷体_GB.如何得到MIME邮件的源码
Outlook ExpressFoxmail()Foxmail
MIMESMTPPOP3MIMEMIMESMTPPOP3MIMEMIME
SMTPPOP3MIMEMIME
http://dev.csdn.net/article/18/18448.shtm [Online]
RFCRFC821SMTPRFC822RFC1425ESMTPRFC1939POP3RFC2045-RFC2049MIME
http://www.faqs.org/rfcs/RFC
paf.net/RFC
Stevens, W.R., TCP/IP Illustrated, Vol1. Addision-Wesley, 2002
&&相关文章推荐
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:276372次
积分:2612
积分:2612
排名:第17647名
原创:40篇
评论:86条
(1)(1)(1)(3)(1)(1)(1)(2)(1)(1)(2)(1)(1)(1)(3)(1)(4)(1)(3)(9)(2)(1)(1)数据库协议解析-软件开发-任务易推荐给您
数据库协议解析
数据库协议解析一、硬件环境:?操作系统:Centos6.4?编码语言:C/C++二、接口需求?设计原理文档?用户使用文档?源码及实例程序(压缩包类型)三、周期要求面议四、详细功能描述?从网络数据报文中智能提取用户操作数据库信息。?用户登录账号?用户登录客户端工具?数据库增、删、改、查等sql语句。?支持主流数据库oracle、mssql、mysql、DB2、pgsql等。?支持每种数据库操作信息智能获取算法模块化封装。?Get_Oracle_UserName()、Get_mssql_UserName()…?Get_Oracle_query_sql()、Get_mssql_query_sql()…?考虑到一些关联sql语句会比较长,必须保证数据库信息获取的完整性、可用性。
任务易所有内容均为威客和外包行业网站提供或收集于互联网公开的信息,目的是给在网络上工作的威客和兼职人员收集更多的免费工作信息,以帮助更多的人自主就业。如果有内容触及您的权益,请给我们发邮件()并附上具体网址和说明,核实后我们将立即删除!对免责声明的解释、修改及更新权均属于任务易所有。
你觉得这个任务肿么样?
评分:3.5分
猪八戒网是全国最大的在线服务交易平台,由原《重庆晚报》首席记者朱明跃创办于2006年,服务交易品类涵盖创意设计、软件开发、网站建设、网络营销、文案策划、生活服务等多种行业。2011年猪八戒网获得IDG千万级美金投资,并被评选为中国2011年度“最佳商业模式十强”企业。2012年猪八戒还获得了国家文化产业示范基地称号。
你可能也对这些任务感兴趣
日内的任务网络协议(3)
  对于在网络上的比较小的结点,支持消息传输系统(MTS)是不实际的。例如,一台
工作站可能不具有充足的资源允许SMTP服务器和相当的本地邮件传送系统保持序驻留,
并持续运行。同样的,将一台个人计算机长时间连接在IP类型网络上的费用也是可观的
(结点缺少的资源被称为&联络性&)。
  虽然如此,在这样的小结点上允许管理邮件是十分有用的,并且这些结点经常支持一
个用户代理来管理邮件。为解决这一问题,能够支持MTS的结点就为这些不能支持的结点提
供了邮件存储功能。邮局协议-版本3就是使这样的工作站可以用一种比较实用的方法来访问
存储于服务器上的储存邮件。通常,这意味着工作站可以从服务器上取得邮件,而服务器为
它暂时保存邮件。
  在下文中,客户主机指的是利用POP3服务的主机,而服务器主机指的是提供POP3服务的
2.简单说明
  在此文档中不指明客户主机如何将邮件送入到传送系统中去。但这里有一个说明:当用
户代理需要将信息送到传送系统时,它在接力主机上建立SMTP连接(这些接力主机可以是
POP3主机,也可以不是)。
3.基本操作
  初始时,服务器通过侦听TCP端口110开始POP3服务。当客户主机需要使用服务时,它将
与服务器主机建立TCP连接。当连接建立后,POP3发送确认消息。客户和POP3服务器相互(分
别)交换命令和响应,这一过程一直要持续到连接终止。
  POP3命令由一个命令和一些参数组成。所有命令以一个CRLF对结束。命令和参数由可打
印的ASCII字符组成,它们之间由空&#26684;间隔。命令一般是三到四个字母,每个参数却可达40个
  POP3响应由一个状态码和一个可能跟有附加信息的命令组成。所有响应也是由CRLF对结
束。现在有两种状态码,&确定&(&&#43;OK&)和&失败&(&-ERR&)。
  对于特定命令的响应是由许多字符组成的。在这些情况中,下面一一表述:在发送第一
行响应和一个CRLF之后,任何的附加信息行发送,他们也由CRLF对结束。当所有信息发送结束
时,发送最后一行,包括一个结束字符(十进制码46,也就是&.&)和一个CRLF对。如果信息
中的任何一行以结束字符开始,此行就是通过在那一行预先装入结束而进行字符填充的。因此,
多行响应由五个CRLF.CRLF结束。当检测多行响应时,客户检测以确认此行是否以结束字符开
始。如果是的,而且其后的字符不是CRLF,此行的第一个字符(结束字符)将被抛弃;如果其
后紧跟CRLF,从POP服务器来的响应终止,包括.CRLF的行也不被认为是多行响应的一部分了。
  在生命周期中,POP3会话有几个不同的状态。一旦TCP连接被打开,而且POP3服务器发送了
确认信息,此过程就进入了&确认&状态。在此状态中,客户必须向POP3服务器确认自己是其的
客户。一旦确认成功,服务器就获取与客户邮件相关的资源,此时这一过程进入了&操作&状态。
在此状态中,客户提出服务,当客户发出QUIT命令时,此过程进入了&更新&状态。在此状态中,
POP3服务器释放在&操作&状态中取得的资源,并发送消息,终止连接。
  POP3服务器可以拥有一个自动退出登录的记时器。此记时器必须至少可以记录10分钟。这样
从客户发送的消息才可能刷新此记时器。当记时器失效时,POP3会话并不进入&更新&状态,而是
关闭TCP连接,而且不删除任何消息,不向客户发送任何响应。
4.&确认&状态
  一时TCP连接由POP3客户打开,POP3服务器发送一个单行的确认。这个消息可以是由CRLF结
束的任何字符。例如,它可以是:
    S:&#43;OKPOP3serverready
  注意:这个消息是一个POP3应答。POP3服务器应该给出一个&确定&响应作为确认。
  此时POP3会话就进入了&确认&状态。此时,客户必须向服务器证明它的身份。在文档中介绍
两种可能的处理机制,一种是USER和PASS命令,另一种是在后面要介绍的APOP命令。
  用USER和PASS命令进行确认过程,客户必须首先发送USER命令,如果POP3服务器以&确认&状
态码响应,客户就可以发送PASS命令以完成确认,或者发送QUIT命令终止POP3会话。如果POP3服
务器返回&失败&状态码,客户可以再发送确认命令,或者发送QUIT命令。
  当客户发送了PASS命令后,服务器根据USER和PASS命令的附加信息决定是否允许访问相应的
存储邮件。
  一旦服务器通过这些数据决定允许客户访问储存邮件,服务器会在邮件上加上排它锁,以防
止在进入&更新&状态前对邮件的改变。如果成功获得了排它锁,服务器返回一个&确认&状态码。
会话进入&操作状态&,同时没有任何邮件被标记为删除。如果邮件因为某种原因不能打开(例如,
排它锁不能获得,客户不能访问相应的邮件或者邮件不能进行语法分析),服务器将返回&失败&
状态码。在返回&失败&状态码后,服务器会关闭连接。如果服务器没有关闭连接,客户可以重新
发送确认命令,重新开始,或者发送QUIT命令。
  在服务器打开邮件后,它为每个消息指定一个消息号,并以八进制表示每个消息的长度。第
一个消息被指定为1,第二个消息被指定为2,以此类推,第N个消息被指定为N。在POP3命令和响应
中,所以的消息号和长度以十进制表示。
  下面是对上述三条命令的总结:
5.&操作&状态
  一旦客户向服务器成功地确认了自己的身份,服务器将锁住并打开相应的邮件,这时POP3会
话进入&操作&状态。现在客户可以重复下面的POP3命令,对于每个命令服务器都会返回应答。最
后,客户发送QUIT命令,会话进入&更新&状态。
  下面是在&操作&状态中可用的命令:
6.&更新&状态
  当客户在&操作&状态下发送QUIT命令后,会话进入&更新&状态。(注意:如果客户在&确认&状
态下发送QUIT后,会话并不进入&更新&状态。)
  如果会话因为QUIT命令以外的原因中断,会话并不进入&更新&状态,也不从服务器中删除任何
7.可选的POP3命令
  以上讨论的命令是对POP3服务的最小实现。以下说明的可选命令允许客户更方便地处理信件,
这是一个比较一般的POP3服务实现。
  ·TOPmsgn
  【参数】一个是未被标记为删除的信件数,另一个是非负数(必须提供)
  【限制】仅在&操作&状态下使用。
  【说明】
  如果服务器返回&确认&,响应是多行的。在初始的&#43;OK后,服务器发送信件头,一个空行将信
件头和信件体分开,对于多行响应要注意字节填充终止符。
  注意:如果客户要求的行数比信件体中的行数大,服务器会发送整个信件。
  【响应】&#43;OK:其后有信件头;
  -ERR:其后无类&#20284;消息。
  【例子】
  C:TOP110
  S:&#43;OK
  S:&服务器发送消息头,一个空行和信件的头10行&
  C:TOP1003
  S:-ERRnosuchmessage
  ·UIDL[msg]
  【参数】信件数(可选)。如果给出信件数,不包括被标记为删除的信件。
  【限制】仅在&操作&状态下使用。
  【说明】
  如果给出了参数,且POP3服务器返回包括上述信息的&确认&,此行称为信息的&独立-ID表&。
  如果没有参数,服务器返回&确认&响应,此响应便以多行给出。在初的&#43;OK后,对于每个信件,
服务器均给出相应的响应。此行叫做信件的&独立-ID表&。
  为简化语法分析,所有服务器要求使用独立-ID表的特定&#26684;式。它包括空&#26684;和信件的独立-ID。
  信件的独立-ID由0x21到0x7E字符组成,这个符号在给定的存储邮件中不会重复。
  注意:信件不包括被标记为删除的信件。
  【响应】&#43;OK:其后是独立-ID表;
  -ERR:其后无类&#20284;信件。
  【例子】
  C:UIDL
  S:&#43;OK
  S:1whqtswO00WBw418f9t5JxYwZ
  S:2QhdPYR:00WBw1Ph7x7
  C:UIDL2
  S:&#43;OK2QhdPYR:00WBw1Ph7x7
  C:UIDL3
  S:-ERRnosuchmessage,only2messagesinmaildrop
  ·APOPnamedigest
  【参数】指定邮箱的字串和MD5摘要串。
  【限制】仅在POP3确认后的&确认&状态中使用。
  【说明】通常,每个POP3会话均以USER/PASS互换开始。这导致了用户名和口令在网络上的显式
传送,这不会造成什么危险。但是,许多客户经常连接到服务检查信件。通常间隔时间比较短,这就
加大了泄密的可能性。
另一种提供&确认&过程的方法是使用APOP命令。
  实现APOP命令的服务器包括一个标记确认的时间戳。例如:在UNIX上使用APOP命令的语法为:
process-ID.clock@hostname,其中进程-ID是进程的十进制的数,时钟是系统时钟的十进制表示,主
机名与POP3服务器名一致。
  客户记录下此时间戳,然后以送APOP命令。name语法和USER命令一致。Digest是采用MD5算法产
生的包括时间戳和共享密钥的字串。此密钥是客户和服务器共知的,应该注意保护此密钥,如果泄密,
任何人都能够以用户身份进入服务器。
  如果服务器接到APOP命令,它验证digest,如果正确,服务器返回&确认&,进入&操作&状态;否
则,给出&失败&并停留在&确认&状态。
  注意:共享密钥的长度增加,解读它的难度也相应增加,这个密钥应该是长字符串。
  【响应】&#43;OK:邮件锁住并准备好;
  -ERR:拒绝请求。
  【例子】
  S:&#43;OKPOP3serverready&52@dbc.mtview.ca.us&
  C:APOPmrosec4c9334bac560ecc979efb
  S:&#43;OKmaildrophas1message(369octets)
  在此例子中,共享密钥&52@dbc.mtview.ca.us&tanstaaf由MD5算法生成,它产生了
digest&#20540;,c4c9334bac560ecc979efb
8.POP3命令总结
基础的POP3命令:
USERname在&确认&状态有效
PASSstring
STAT在&操作&状态有效
QUIT在&更新&状态有效
可选的POP3命令:
APOPnamedigest在&确认&状态有效
TOPmsgn在&操作&状态有效
POP3响应:
注意:除了STAT,LIST和UIDL的响应外,其它命令的响应均为&&#43;OK&和&-ERR&。响应后的所有文
本将被客户略去。
9.POP3会话实例
S:&等待连接到TCP端口110&
C:&打开连接&
S:&#43;OKPOP3serverready&52@dbc.mtview.ca.us&
C:APOPmrosec4c9334bac560ecc979efb
S:&#43;OKmrose smaildrophas2messages(320octets)
S:&#43;OK2320
S:&#43;OK2messages(320octets)
S:&#43;OK120octets
S:&服务器发送信件1&
S:&#43;OKmessage1deleted
S:&#43;OK200octets
S:&服务器发送信件2&
S:&#43;OKmessage2deleted
S:&#43;OKdeweyPOP3serversigningoff(maildropempty)
C:&关闭连接&
S:&等待下一次连接&
10.消息&#26684;式
  在会话过程中的消息&#26684;式都假定与Internet文本消息&#26684;式标准一致。应该注意的是,由于各
个服务器对于换行符的处理不同,因此计数不一定相同。通常,在&确认&状态中,服务器能够以
八进制计算信件的大小。例如,如果在打开储存邮件时服务器内部认定换行符代表一个字符,一
般服务器在计算它时作为两个字符计。注意,以终止符开始的消息行不被计数两次,因为客户将
在接收到多行响应后删除所有字节填充。
11.安全性考虑
  可以推测,使用APOP命令可以提供会话期间的保护。相应的,同时实现PASS和APOP命令的服务
器只允许用户以一种方式访问;也就是说要么使用USER/PASS组合,要么使用APOP命令,不能同时
使用两个。
  而且,注意随着共享密钥长度的增加,解读的难度也就上升了。服务器要提供用户名时不给出
任何响应,不给出任何暗示此用户名是否正确。而口令却在网络上显式传送;使用RETR和TOP命令
在网络上显式传送信件
&&相关文章推荐
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场

我要回帖

更多关于 1939can协议 解析 的文章

 

随机推荐