精华内容
下载资源
问答
  • 凡是通信就必须要有通信协议,个人认为协议的设计是个非常严肃的工作,需要理解业务需求和掌握基本的协议设计知识。但是从这两个项目来看,其协议的设计可以说是 糟糕到了极点。下面就其糟糕的设计之处予以批判。 1 ...

    去年和今年分别参与了两个公司的项目,这两个项目都涉及到了通信方面的程序设计,或者是以太网络通信,或者是串口通信。凡是通信就必须要有通信协议,个人认为协议的设计是个非常严肃的工作,需要理解业务需求和掌握基本的协议设计知识。但是从这两个项目来看,其协议的设计可以说是 糟糕到了极点。下面就其糟糕的设计之处予以批判。

    1 糟糕设计之一:消息格式“包头+数据+包尾”

    与UDP不同,TCP通信属于流式通信,没有消息边界,所以需要应用层自行对报文进行界定分离。实际项目1中,包头为{{两个字节,包尾为}}两个字节,例如{{t=123}}。其格式为:

    开始边界+消息1+结束边界+开始边界+消息2+结束边界+开始边界+消息3+结束边界+....

    由于TCP是安全的传输层协议,除非特别需要,应用层无需再做校验。消息边界只需要一个标识即可,基本格式为:

    消息1+边界+消息2+边界+消息3+边界+...

    无论从节约网络带宽,还是从简化报文解析代码,第一种设计都是非常的愚蠢!

    无独有偶,项目2中基于串口的通信应用层协议也采用了这种设计格式。

    当问其设计人员为何如此设计时,说一直就是这么设计的,自己也不知道这么设计的原因,还美滋滋地说一直没有什么问题,真想揍他一拳。

    2 糟糕设计之二:用结构体代码而不是文本描述消息结构

    项目2中,根本无协议的描述文本,只有一个包含结构体定义的头文件供协议的使用者参考。

    通信就会涉及到多个机器,所以通信协议必须要能跨平台。而我们知道

    struct A
    {
    char x;
    int y;
    };

    在不同编译器,不同平台,不同编译选项下会有不同的二进制布局。况且协议使用者也可能看不懂C系语言代码。更搞笑的是,头文件中竟然没有强制结构体单字节对齐。

    问到协议的设计者设计思路时,说我们公司一直这样啊,一直没问题啊。之所以没有问题,是因为使用这个协议的所有机器都是同一CPU型号,同一开发环境,同一操作系统。

    3 糟糕设计之三:传送二进制浮点数

    浮点数的二进制格式并不是只有一种,不同平台采用不同的方式存放。这要比大端小端的整数差别更加严重。所以跨平台传送二进制浮点数是非常不安全的。而在项目2中,消息中大量使用了二进制浮点数。

    要传送浮点数,通常有两种解决方式:

    文本化。也就是传送描述浮点数的字符串,我们知道字符串是完全跨平台的,尤其是在UTF-8这样全球统一字符编码的情况下。

    转换为整数。例如1.2,可以用整数12代替,只是要规定单位为0.1即可。

    4 糟糕设计之三:大量备用字段

    项目二的消息结构体类似如下:

    struct A
    {
    char name[16];
    int age;
    int spare1;
    short spare2;
    short spare3;
    int spare4;
    };

    大量的备用字段充斥在结构体中。少量的备用字段可以理解,如此大量的后备力量,真是深远谋虑啊。真不知道协议使用者在看到spare时会不会吐。如果真的需要这么多备用字段,完全可以重新定义一个消息结构了。

    5 糟糕设计之四:照猫画虎的握手和校验

    握手和校验是保证安全完整通信的基本手段,但是其实现却非常不简单,看看TCP的实现代码就知道了,需要考虑各种异常情况。项目二中串口设备和主机之间照猫画虎地定义了一个握手协议。开机后 设备向主机一直发送AA,主机收到AA后向设备发送AA,设备收到AA后向主机发送55,主机收到55后向设备发送55。这个简单的握手存在很多问题,随便说几个:

    完全没有必要握手。一般的串口设备无需知道主机的工作状态,主机如果想了解设备状态,发个询问报文即可。

    如果主机发送AA后程序退出,那么串口设备永远也等不到来自主机的55。

    如果主机中途关掉,在运行时可能收到来自串口设备的AA,而此时的AA其实只是消息报文的一个字节,而不是握手信号。

    只要仔细想想,还有很多类似的情况需要处理。而且实际使用过程中,确实发生了上面的情况,致使必须重启串口设备或主机。

    还是项目2中,基于UDP的应用层协议自行设计了校验。其实这也无可厚非,比如著名的tftp就是这样的协议。只是设计者考虑不周,各种问题频出,最终的结果是这些校验字段根本就没有实际使用,白白浪费了网络带宽。需要说明的是,这个协议的设计者还是国内很大的一家公司,当然是国企,你懂的


    作者:smstong

    来源:51CTO

    展开全文
  • 版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 ... 去年和今年分别参与了两个公司的项目,这两个项目...凡是通信就必须要有通信协议,个人认为协议的设计是个非常严肃...

    版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
    本文链接:https://blog.csdn.net/smstong/article/details/49148283


    去年和今年分别参与了两个公司的项目,这两个项目都涉及到了通信方面的程序设计,或者是以太网络通信,或者是串口通信。凡是通信就必须要有通信协议,个人认为协议的设计是个非常严肃的工作,需要理解业务需求和掌握基本的协议设计知识。但是从这两个项目来看,其协议的设计可以说是 糟糕到了极点。下面就其糟糕的设计之处予以批判。

    1 糟糕设计之一:消息格式“包头+数据+包尾”
    与UDP不同,TCP通信属于流式通信,没有消息边界,所以需要应用层自行对报文进行界定分离。实际项目1中,包头为{{两个字节,包尾为}}两个字节,例如{{t=123}}。其格式为:

    开始边界+消息1+结束边界+开始边界+消息2+结束边界+开始边界+消息3+结束边界+....
    1
    由于TCP是安全的传输层协议,除非特别需要,应用层无需再做校验。消息边界只需要一个标识即可,基本格式为:

    消息1+边界+消息2+边界+消息3+边界+...
    1
    无论从节约网络带宽,还是从简化报文解析代码,第一种设计都是非常的愚蠢!
    无独有偶,项目2中基于串口的通信应用层协议也采用了这种设计格式。
    当问其设计人员为何如此设计时,说一直就是这么设计的,自己也不知道这么设计的原因,还美滋滋地说一直没有什么问题,真想揍他一拳。

    2 糟糕设计之二:用结构体代码而不是文本描述消息结构
    项目2中,根本无协议的描述文本,只有一个包含结构体定义的头文件供协议的使用者参考。

    通信就会涉及到多个机器,所以通信协议必须要能跨平台。而我们知道

    struct A
    {
        char x;
        int y;
    };

    在不同编译器,不同平台,不同编译选项下会有不同的二进制布局。况且协议使用者也可能看不懂C系语言代码。更搞笑的是,头文件中竟然没有强制结构体单字节对齐。

    问到协议的设计者设计思路时,说我们公司一直这样啊,一直没问题啊。之所以没有问题,是因为使用这个协议的所有机器都是同一CPU型号,同一开发环境,同一操作系统。

    3 糟糕设计之三:传送二进制浮点数
    浮点数的二进制格式并不是只有一种,不同平台采用不同的方式存放。这要比大端小端的整数差别更加严重。所以跨平台传送二进制浮点数是非常不安全的。而在项目2中,消息中大量使用了二进制浮点数。

    要传送浮点数,通常有两种解决方式:

    文本化。也就是传送描述浮点数的字符串,我们知道字符串是完全跨平台的,尤其是在UTF-8这样全球统一字符编码的情况下。
    转换为整数。例如1.2,可以用整数12代替,只是要规定单位为0.1即可。
    4 糟糕设计之三:大量备用字段
    项目二的消息结构体类似如下:

    struct A
    {
        char name[16];
        int age;
        int spare1;
        short spare2;
        short spare3;
        int spare4;
    };

    大量的备用字段充斥在结构体中。少量的备用字段可以理解,如此大量的后备力量,真是深远谋虑啊。真不知道协议使用者在看到spare时会不会吐。如果真的需要这么多备用字段,完全可以重新定义一个消息结构了。

    5 糟糕设计之四:照猫画虎的握手和校验
    握手和校验是保证安全完整通信的基本手段,但是其实现却非常不简单,看看TCP的实现代码就知道了,需要考虑各种异常情况。项目二中串口设备和主机之间照猫画虎地定义了一个握手协议。开机后 设备向主机一直发送AA,主机收到AA后向设备发送AA,设备收到AA后向主机发送55,主机收到55后向设备发送55。这个简单的握手存在很多问题,随便说几个:

    完全没有必要握手。一般的串口设备无需知道主机的工作状态,主机如果想了解设备状态,发个询问报文即可。
    如果主机发送AA后程序退出,那么串口设备永远也等不到来自主机的55。
    如果主机中途关掉,在运行时可能收到来自串口设备的AA,而此时的AA其实只是消息报文的一个字节,而不是握手信号。
    只要仔细想想,还有很多类似的情况需要处理。而且实际使用过程中,确实发生了上面的情况,致使必须重启串口设备或主机。

    还是项目2中,基于UDP的应用层协议自行设计了校验。其实这也无可厚非,比如著名的tftp就是这样的协议。只是设计者考虑不周,各种问题频出,最终的结果是这些校验字段根本就没有实际使用,白白浪费了网络带宽。需要说明的是,这个协议的设计者还是国内很大的一家公司,当然是国企,你懂的。
     

    展开全文
  • 适用于做CAN通信开发,资料是从网上下载的,需要的可以下载!方便开发。
  • 凡是通信就必须要有通信协议,个人认为协议的设计是个非常严肃的工作,需要理解业务需求和掌握基本的协议设计知识。但是从这两个项目来看,其协议的设计可以说是 糟糕到了极点。下面就其糟糕的设计之处予以批判。 ...

    去年和今年分别参与了两个公司的项目,这两个项目都涉及到了通信方面的程序设计,或者是以太网络通信,或者是串口通信。凡是通信就必须要有通信协议,个人认为协议的设计是个非常严肃的工作,需要理解业务需求和掌握基本的协议设计知识。但是从这两个项目来看,其协议的设计可以说是 糟糕到了极点。下面就其糟糕的设计之处予以批判。

    1 糟糕设计之一:消息格式“包头+数据+包尾”

    与UDP不同,TCP通信属于流式通信,没有消息边界,所以需要应用层自行对报文进行界定分离。实际项目1中,包头为{{两个字节,包尾为}}两个字节,例如{{t=123}}。其格式为:

    开始边界+消息1+结束边界+开始边界+消息2+结束边界+开始边界+消息3+结束边界+....
    

    由于TCP是安全的传输层协议,除非特别需要,应用层无需再做校验。消息边界只需要一个标识即可,基本格式为:

    消息1+边界+消息2+边界+消息3+边界+...
    

    无论从节约网络带宽,还是从简化报文解析代码,第一种设计都是非常的愚蠢! 
    无独有偶,项目2中基于串口的通信应用层协议也采用了这种设计格式。 
    当问其设计人员为何如此设计时,说一直就是这么设计的,自己也不知道这么设计的原因,还美滋滋地说一直没有什么问题,真想揍他一拳。

    2 糟糕设计之二:用结构体代码而不是文本描述消息结构

    项目2中,根本无协议的描述文本,只有一个包含结构体定义的头文件供协议的使用者参考。

    通信就会涉及到多个机器,所以通信协议必须要能跨平台。而我们知道

    struct A
    {
        char x;
        int y;
    };

    在不同编译器,不同平台,不同编译选项下会有不同的二进制布局。况且协议使用者也可能看不懂C系语言代码。更搞笑的是,头文件中竟然没有强制结构体单字节对齐。

    问到协议的设计者设计思路时,说我们公司一直这样啊,一直没问题啊。之所以没有问题,是因为使用这个协议的所有机器都是同一CPU型号,同一开发环境,同一操作系统。

    3 糟糕设计之三:传送二进制浮点数

    浮点数的二进制格式并不是只有一种,不同平台采用不同的方式存放。这要比大端小端的整数差别更加严重。所以跨平台传送二进制浮点数是非常不安全的。而在项目2中,消息中大量使用了二进制浮点数。

    要传送浮点数,通常有两种解决方式:

    • 文本化。也就是传送描述浮点数的字符串,我们知道字符串是完全跨平台的,尤其是在UTF-8这样全球统一字符编码的情况下。
    • 转换为整数。例如1.2,可以用整数12代替,只是要规定单位为0.1即可。

    4 糟糕设计之三:大量备用字段

    项目二的消息结构体类似如下:

    struct A
    {
        char name[16];
        int age;
        int spare1;
        short spare2;
        short spare3;
        int spare4;
    };

    大量的备用字段充斥在结构体中。少量的备用字段可以理解,如此大量的后备力量,真是深远谋虑啊。真不知道协议使用者在看到spare时会不会吐。如果真的需要这么多备用字段,完全可以重新定义一个消息结构了。

    5 糟糕设计之四:照猫画虎的握手和校验

    握手和校验是保证安全完整通信的基本手段,但是其实现却非常不简单,看看TCP的实现代码就知道了,需要考虑各种异常情况。项目二中串口设备和主机之间照猫画虎地定义了一个握手协议。开机后 设备向主机一直发送AA,主机收到AA后向设备发送AA,设备收到AA后向主机发送55,主机收到55后向设备发送55。这个简单的握手存在很多问题,随便说几个:

    • 完全没有必要握手。一般的串口设备无需知道主机的工作状态,主机如果想了解设备状态,发个询问报文即可。
    • 如果主机发送AA后程序退出,那么串口设备永远也等不到来自主机的55。
    • 如果主机中途关掉,在运行时可能收到来自串口设备的AA,而此时的AA其实只是消息报文的一个字节,而不是握手信号。

    只要仔细想想,还有很多类似的情况需要处理。而且实际使用过程中,确实发生了上面的情况,致使必须重启串口设备或主机。

    还是项目2中,基于UDP的应用层协议自行设计了校验。其实这也无可厚非,比如著名的tftp就是这样的协议。只是设计者考虑不周,各种问题频出,最终的结果是这些校验字段根本就没有实际使用,白白浪费了网络带宽。需要说明的是,这个协议的设计者还是国内很大的一家公司,当然是国企,你懂的。

    展开全文
  • 这次说说系统的应用层通信协议。  这个也是看了一些东西,分析腾讯的通信协议的文章真是多如牛毛。看了许多,不过惭愧,真正让我特别明白的也就是一篇,附上链接...

        上次大概说了一下系统的主要框架的选择。这次说说系统的应用层通信协议。

       这个也是看了一些东西,分析腾讯的通信协议的文章真是多如牛毛。看了许多,不过惭愧,真正让我特别明白的也就是一篇,附上链接http://blog.csdn.net/handsy/article/details/6446721。这篇博客可能是QQ比较早版本的应用层协议的具体内容,我也基本上属于照猫画虎,在协议的定义上基本都是参照了这篇博客,对于要实现类似QQ诸多功能的程序,还是很有借鉴意义的。不过这篇博客并没有附带介绍QQ的消息头,不过这个网上也有一些文章分析的,不过我都没太看懂,大概意思是类似下面的结构体:

    typedef struct _e_message_header
    {
        uint8_t     magic;
        uint16_t    version;        //use EASYCHAT_VERSION
        uint16_t    cmd;            //communication: 0x01(tcp)       keepalive: 0x0A(udp)
        uint16_t    seq;
        uint8_t     indicator;              //unused: fixed value 0x81;
        uint8_t     sender_type;            //server: 0x01      client: 0x0A
        uint8_t     receiver_type;          //server: 0x01      client: 0x0A
        uint8_t     msg_type;               //MSGTYPE_XXX
        uint32_t    msg_len;
    } eMessageHeader;

        这个结构体实际工作效果还不错,基本能满足完成功能所需的字段以及以后的程序扩展性和版本的升级。

        通信协议剩下的关键部分就是实现各种消息来满足功能的要求。前面说的那篇博客讲到的我基本都定义了,后来由于一些功能的扩展以及TCP的一些局限性,还额外定义了一些消息。具体消息的宏定义如下:

    #define     MSGTYPE_REGISTER            0x01
    #define     MSGTYPE_LOGIN               0x02
    #define     MSGTYPE_TEXTMSG             0x03
    #define     MSGTYPE_GROUPTEXTMSG        0x04
    #define     MSGTYPE_REQUESTFRIENDINFO   0x05
    #define     MSGTYPE_ADDGROUP            0x06
    #define     MSGTYPE_MODIFYGROUPNAME     0x07
    #define     MSGTYPE_DELETEGROUP         0x08
    #define     MSGTYPE_MOVEGROUPMEMBER     0x09
    #define     MSGTYPE_REQUESTONLINE       0x0A
    #define     MSGTYPE_CUSTOMREQUEST       0x0B        //自定义查找
    #define     MSGTYPE_ADDFRIEND           0x0C
    #define     MSGTYPE_ADDFRIENDWITHREASON 0x0D
    #define     MSGTYPE_DELETEFRIEND        0x0E
    #define     MSGTYPE_CHANGESTATUS        0x10
    #define     MSGTYPE_MONITOR             0x11        //未实现
    #define     MSGTYPE_MODIFYINFORMATION   0x12
    #define     MSGTYPE_REQUESTSENDFILE     0x13
    #define     MSGTYPE_ANSWERSENDFILE      0x14
    #define     MSGTYPE_SENDFILE            0x15
    #define     MSGTYPE_LINKTEST            0x16
    #define     MSGTYPE_ANSWERADDFRIEND     0x17
    #define     MSGTYPE_WAITCONNECT         0x18        //等待指定的好友进行连接
    #define     MSGTYPE_STOPWAIT            0x19        //停止对指定好友的连接等待
    #define     MSGTYPE_REQUESTSYSTEMMSG    0x1A        //请求服务器中存储的系统消息
    #define     MSGTYPE_REQUESTFRIENDMSG    0x1B        //请求服务器中存储的好友消息
    #define     MSGTYPE_REQUESTVIDEOCHAT        0x1C
    #define     MSGTYPE_ANSWERVIDEOCHAT         0x1D
    #define     MSGTYPE_STOPVIDEOCHAT           0x1E

    #define     MSGTYPE_ADVERTISEMENTCLICK  0x20        //向服务器汇报广告点击




    #define     NOTIFYTYPE_REGISTERRESULT           0x01
    #define     NOTIFYTYPE_LOGINRESULT              0x02
    #define     NOTIFYTYPE_MESSAGE                  0x03
    #define     NOTIFYTYPE_FRIENDINFO               0x04
    #define     NOTIFYTYPE_ADDGROUPRESULT           0x05
    #define     NOTIFYTYPE_MODIFYGROUPRESULT        0x06
    #define     NOTIFYTYPE_DELETEGROUPRESULT        0x07
    #define     NOTIFYTYPE_MOVEGROUPMEMBERRESULT    0x08
    #define     NOTIFYTYPE_REQUESTONLINERESULT      0x09
    #define     NOTIFYTYPE_CUSTOMREQUESTRESULT      0x0A
    #define     NOTIFYTYPE_ADDFRIENDRESULT          0x0B
    #define     NOTIFYTYPE_ADDFRIEND                0x0C
    #define     NOTIFYTYPE_DELETEFRIENDRESULT       0x0E
    #define     NOTIFYTYPE_CHANGESTATUSRESULT       0x10
    #define     NOTIFYTYPE_MODIFYINFORMATIONRESULT  0x11
    #define     NOTIFYTYPE_REQUESTSENDFILE          0x12
    #define     NOTIFYTYPE_REQUESTSENDFILERESULT    0x13
    #define     NOTIFYTYPE_SENDFILE                 0x14
    #define     NOTIFYTYPE_FRIENDSTATUS             0x15        //udp
    #define     NOTIFYTYPE_LINKTEST                 0x16
    #define     NOTIFYTYPE_WAITCONNECTRESULT        0x17        //服务器返回用户等待连接申请的结果
    #define     NOTIFYTYPE_STOPWAITRESULT           0x18        //服务器返回用户停止等待申请的结果


    #define     NOTIFYTYPE_RING                     0x20        //udp
    #define     NOTIFYTYPE_ADVERTISEMENT            0x21        //udp

        由于编辑器的问题,对齐的不是很好。这是我用到的所有的消息类型,具体的消息格式就不贴了,太长了,有500多行。可以根据上面的博客自己实现。也可以将我的发给你。贴这么多,我只是想说:有一个预先设计好的应用层通信协议,可以减少编码工作的不少麻烦,等到后期实现代码的时候,各个功能模块之间基本不会有冲突。QQ的通信协议也是经过了时间的考验的,所以我建议在开发的时候先将通信中要用到的消息都定义好,这样就会做起来很顺手。

        当时看通信协议的时候也看了一些其他的标准协议,比如SIP、XMPP等。现在在看这些名字真是陌生的不行,只能从以前看的论文里的标题里找到了,这些也都没有太深入看。有兴趣的也可以看看。

         设计应用层通信协议这项工作至关重要(虽然是抄的),因为服务器和客户端的交互完全就是通过这个协议来实现的。所以我的做法是定义了一个头文件,里面写了所有消息格式,然后分别放到服务器和客户端版本里,这样才能保证消息格式的一致性。当然中途也进行过修改,改完了就要立即对客户端和服务器进行同步。一旦两个文件不一致,出现各种问题就很郁闷了。

    展开全文
  • 基于UDP的广播系统中应用层通信协议设计与实现
  • 文章首发于同名微信公众号:DigCore ...串口实现了两个终端设备之间进行可靠的通信,串口在这中间完成了传输的作用。本次要讲的是关于数据的协议。   类似场景       洞幺!洞幺!我是洞拐!收到请...
  • 应用层——协议

    2020-05-09 16:50:21
    前言:本章将介绍关于应用层协议,如下图所示 一、应用协议的概要 利用网络的应用程序有很多,包括Web浏览器、电子邮件、远程登陆、文件传输、网络管理等,能够让这些应用进行通信处理的正是应用协议。 ...
  • 此处的文章从微信公众号拷贝而来,图片或者排版上可能存在一定的瑕疵,欢迎点击原文链接阅读)串口实现了两个终端设备之间进行可靠的通信,串口在这中间完成了传输的作用。本次要讲的是关于数据...
  • 在层型的拓扑结构上实现无线HART数据链路层通信协议,这里所设计的算法已成功应用于无线HART单跳网络。  1 无线HART拓扑结构  无线通信网络拓扑主要包括星型和网状两种结构,星型单跳网络支持高可靠性的网络通信...
  • 匿名通信系统是一种建立在应用层之上结合利用数据转发、内容加密、流量混淆等多种隐私保护技术来隐藏通信实体关系和内容的覆盖网络。然而,作为覆盖网络运行的匿名通信系统,在性能和安全保障上的平衡问题上存在不足...
  • 同时有些协议可能是没有标准的,需要我们自己设计一套通信协议,当然我们肯定在某些已有协议之上再进行自定义。比如我们要定义T-Box与车联网平台的通讯,那么肯定会使用TCP/UDP作为基础协议,再基于这一的协议进行...
  • 文章首发于同名微信公众号:DigCore 欢迎关注同名微信公众号:DigCore,及时获取最新技术博文。   ...从以上的部分demo例程来看,并结文章《嵌入式硬件通信接口协议-UART(一)协议基础》的...
  • 如何设计应用层协议(草稿)

    千次阅读 2018-05-24 07:29:49
    应用层协议应当定义什么 应用进程交换的报文类型,如请求报文和相应报文 各种报文类型的语法,如报文中的各个字段及其详细描述 字段的语义,即包含在字段中的信息的含义 进程何时,如何发送报文,以及及时对报文进行...
  • 本文在ZigBee2007协议栈基础上设计开发了一个应用层ZigBee协议,实现了协调器和终端模块之间的双向传输预设格式的数据。ZigBee协议通过对无线模块内的各种硬件资源标准化编码,实现了使用统一的的方法来访问控制模块...
  • 02 应用层协议

    2021-01-18 16:46:46
    02 应用层协议。 往期检索:程序设计学习笔记——目录 创建时间:2021年1月18日 软件: eNsp_Client 、SecureCRT 先放一张思维导图,大致知道操作系统的具体功能和目标,然后再一一展开叙述。 网络协议基础...
  • 这里指的协议应用层协议,针对应用协议设计,需要注意的有几个基本点:可识别,兼容性,访问控制,可追溯,数据完整性校验。 首先是可识别,一般我们采用一个帧头来表示整个报文的起始位置,这个帧头可以用一个...
  • 提出了应用在无线传感器网络系统的MAC层通信芯片的ASIC设计方案,基于IEEE 802.15.4竞争型MAC协议设计了内嵌CSMA-CA算法控制器的MAC 收发模块以及8位RISC CPU,MAC 收发模块的协处理器可以与RISC CPU进行数据交互...
  • 2.1应用层协议原理

    2021-01-07 17:06:34
    2.1应用层协议原理 2.1.1网络应用程序体系结构 应用程序体系结构: 规定如何在各种端系统上组织应用程序,有研发者设计。 三种类型: 客户机/服务器 对等(P2P) 客户机/服务器与P2P的混合 (1) 客户机/服务器...
  • 摘要: 本文介绍了基于现场可编程门阵列(FPGA) 的以太网MAC 子层协议的硬件实现方法. 硬件结构上由控制模 块、发送模块和接收模块3个部分组成,发送模块和接收模块采用状态机控制数据发送和接收的过程,完成数据的封装...
  • 应用层协议原理

    2017-05-01 18:05:00
    网络核心设备并不在应用层上起作用,而仅在较低层起作用,特别是位于网络层及下面层次。这种基本设计,也即将应用软件限制在端系统的方法,促进了大量的网络应用程序的迅速研发和部署。 一、网络应用程序的体系...
  • 在ZigBee2007协议栈基础上设计开发了一个应用层ZigBee协议,实现了协调器和终端模块之间的双向传输预设格式的数据。ZigBee协议通过对无线模块内的各种硬件资源标准化编码,实现了使用统一的的方法来访问控制模块内部...
  • 给出了利用形式描述语言SDL进行MAC层协议设计开发的完整设计流程;阐述了软件的层次结构,并针对设计中遇到的代码生成器的选择、设计优化、与实时操作系统(RTOS)的集成和环境函数编写等问题进行了深入讨论。 ...
  • 无线HART是一种专门为过程控制领域而设计的网络通信协议,是HART现场总线在无线领域的延伸,其通信模型主要由应用层、网络层、数据链路层、物理层组成。其中数据链路层在物理层提供服务的基础上向网络层提供服务,其...
  • 对于初涉网络编程的开发人员来说,在通信协议设计上一般会有所困惑。一般的网络编程书籍上也较少涉及这方面的内容。估计是觉得太简单了。这块确实是不难,但如果不了解,又很容易出篓子或者绕弯路。下面我就来谈谈...
  • 2.1 应用层协议原理 2.1.1 网络应用程序体系结构 从研发者角度看,网络体系是固定的,并为应用程序提供了特定的服务集合。应用程序体系是由应用程序研发者设计的,规定了如何在各种端系统上组织应用程序。 两类主流...
  • 系统设计,协议先行。 大部分技术人没有接触协议的设计细节,更多的是使用已有...无论如何,了解协议设计的原则,对深入理解系统通信非常有帮助。今天就以即时通讯(后称im)为例,讲讲应用层的协议选型。 一...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,080
精华内容 832
热门标签
关键字:

应用层通信协议设计