精华内容
下载资源
问答
  • OpenFlow消息类型

    千次阅读 2018-07-08 21:16:09
    最近在接触SDN(软件定义网络),本文针对SDN南向接口中的OpenFlow协议消息类型进行简单整理,参考链接为... OpenFlow协议支持三种消息类型,分别为:controll...

          最近在接触SDN(软件定义网络),本文针对SDN南向接口中的OpenFlow协议消息类型进行简单整理,参考链接为http://www.opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf。文中存在诸多不足,仅供参考。

           OpenFlow协议支持三种消息类型,分别为:controller-to-switch,asychronous(异步)和symmetric(对称),每一类消息又有多个子消息类型。其中,controller-to-swicth消息是由交换机发起的,用于管理和检查交互就状态;asychnomous消息是由交互就发起的,用于将网络事件和交换机状态改变信息更新到控制器;symmetric消息是由控制器或交换机发起的。每类消息包含的子消息类型如下所述。

           1、Controller-to-Switch

           Features: 控制器通过向交换机发送features消息,用于请求交换机身份和基本能力信息,且交换机必须对此类消息进行应答。features消息通常在安全通道建立时执行。

          Configuration: 控制器设置或查询交换机上的配置信息,交换机仅需要应答查询信息。

          Modify-State: 控制器通过发送Modify-State消息管理交换机流表项和端口状态等。

          Read-State: Read-State消息用于控制器收集交换机上的各种信息,包括配置、统计等信息。

          Packet-Out: 用于控制器通过交换机指定端口转发数据包。

          Barrier: 用于控制器确保消息依赖满足,或接收完成操作的通知。

          Role-Request: 用于控制器设置或查询安全通道的角色信息。当交换机连接多个控制器时,此类消息是非常有用的。

          Asynchronous-Configuration: 用于针对从安全通道接收到的异步消息添加额外的控制器或查询该控制器。此类消息通常在安全  通道建立时执行,且在交换机连接多个控制器时非常有用。

          2、Asynchronous

          Packet-In: 交换机收到一个网络数据包,在流表中没有匹配项,则发送Packet-In消息给控制器。如果交换机缓存足够多,网络数据包被临时存放在缓存中,网络数据包部分内容和在交换机缓存中的序号一同发给控制器;如果交换机缓存不足则将整个数据包发送给控制器。

         Flow-Removed: 交换机中的流表因为超时或者修改等原因被删除掉,会触发flow-removed消息。

         Port-Status: 交换机端口状态发送变化时触发port-status消息。

         Error: 交换机发生故障时触发error消息。

         3、Symmetric

         Hello: 用于交换机和控制器建立连接。

         Echo: 交换机和控制器均可发送echo消息,接收者需要回复echo reply。该消息用于测量延迟、带宽等。

         Experimenter: 用于在OpenFlow消息类型空间中为OpenFlow交换机提供额外的功能。

    展开全文
  • ICMP消息类型

    千次阅读 2013-09-04 11:37:49
    ICMP是TCP/IP协议族的一个子协议,属于网络层协议,主要用于在主机与路由器之间传递控制信息,包括报告错误、交换受限控制和状态信息等。当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时...

      ICMP是TCP/IP协议族的一个子协议,属于网络层协议,主要用于在主机与路由器之间传递控制信息,包括报告错误、交换受限控制和状态信息等。当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时,会自动发送ICMP消息。















    在Ping和tracert不同主机时,如果ICMP到达中间某台路由器时TTL值减为0,此时,如果该路由器向源主机发送TTL-expired响应消息,则主机上显示TTL-expired消息;否则,就显示 Request time  out消息。

    展开全文
  • sip消息类型和消息格式

    千次阅读 2016-03-03 16:19:32
    SIP消息主要分为两大类: 一类是由客户端发往服务器的请求消息(Request); 一类是由服务器发往客户端的应答消息(Response). 一个基本的SIP消息包括起始行、一个或多个头字段、说明头字段结束的空行和一个可选的...
    SIP是一个基于文本的协议,使用的是UTF-8字符集.
    SIP消息主要分为两大类:
    一类是由客户端发往服务器的请求消息(Request);
    一类是由服务器发往客户端的应答消息(Response).


    一个基本的SIP消息包括起始行、一个或多个头字段、说明头字段结束的空行和一个可选的消息体。
    消息=起始行(包括请求行/状态行;请求行规定了请求的类别,而状态行指出了每个请求的状态,比如是成功还是失败。如果是失败的话还要给出失败的原因或类型。)
              *头字段
              CRLF
               [消息体] (消息首部给出了关于请求或应答的更多信息一般包括消息的来源、规定的消息接收方,另外还包括一些其他方面的重要信息。消息体通常描述将要建立会议的类型包括所交换媒体的描述,但不具体定义消息体的内容或结构,其结构或内容使用另外一个协议来描述,就是会话描述协议SDP。)
    请求消息
    请求行 = 方法 + 空格 + 请求地址 + SIP版本号 + 空行
    通过一个请求行作为起始行,请求行包括了方法名、请求的URL、协议版本号、中间用空格分开。
    六种请求方法:
    INVITE               发出呼叫会话请求
    ACK                   INVITE请求被最终请求
    BYE                   释放一个呼叫会话
    CANCEL           取消挂起的呼叫
    REGISTER       登记注册用户代理
    OPTIONS          查询服务器能力


    应答消息
    状态行 = SIP版本 + 空格 + 状态码 + 空格 + 相关文本短语 + 空行


    SIP应答消息状态码与功能
    类型 状态码 状态说明
    临时应答(1XX) 100 Trying 正在处理中
    180 Ringing 振铃
    181 call being forwarder 呼叫正在前向
    182 queue 排队
    181* session progress 会话进行

    会话成功(2XX) 200 OK 会话成功

    重定向(3XX)
    300 multiple 多重选择
    301 moved permanently 永久移动
    302 moved temporaily 临时移动
    305 use proxy 用户代理
    380 alternative service 替代服务

    请求失败(4XX)
    400 bad request 错误请求
    401unauthorized 未授权
    402 payment required 付费要求
    403 forbidden 禁止
    404 not found 未发现
    405 method no allowed 方法不允许
    406 not acceptable 不可接受
    407 proxy authentication required 代理需要认证
    408 request timeout 请求超时
    410 gone 离开
    413 request entity too large 请求实体太大
    414 request-url too long 请求URL太长
    415 unsupported media type 不支持的媒体类型
    416 unsupported url scheme 不支持的URL计划
    420 bad extension 不良扩展
    421 extension required 需要扩展 
    423 interval too brief 间隔太短
    480 temporarily unavailable 临时失效
    481 call/transaction does not exist 呼叫/事务不存在
    482 loop detected 发现环路
    483 too many hops 跳数太多
    484 address incomplete 地址不完整
    485 ambiguous 不明朗
    486 busy here 这里忙
    487 request terminated 请求终止
    488 not acceptable here 这里请求不可接受
    491 request pending 未决请求
    493 undecipherable 不可辨识

    服务器失败(5XX)
    500 server internal error 服务器内部错误
    501 not implemented 不可执行
    502 bad gateway 坏网关
    503 service unavailable 服务无效
    504 server time-out 服务器超时
    505 version not supported 版本不支持
    513 message too large 消息太大

    全局性错误(6XX)
    600 busy everywhere 全忙
    603 decline 丢弃
    604 does not exist anywhere 不存在
    606 not acceptable 不可接受


    SIP应答代码(这个是详细的应答码解释)
    应答码是包含并且扩展了HTTP/1.1应答码。并不是所有的HTTP/1.1应答码都适当应用,只有在这里指出的是适当的。其他HTTP/1.1应答码不应当使用。并且,SIP也定义了新的应答码系列,6xx。

    1 临时应答1xx 
    临时应答,也就是消息性质的应答,标志了对方服务器正在处理请求,并且还没有决定最后的应答。如果服务器处理请求需要花200ms以上才能产生终结应答的时候,它应当发送一个1xx应答。 
    注意1xx应答并不是可靠传输的。他们不会导致客户端传送一个ACK应答。临时性质的(1xx)应答可以包含消息体,包含会话描述。 
    1.1 100 Trying 
    这个应答表示下一个节点的服务器已经接收到了这个请求并且还没有执行这个请求的特定动作(比如,正在打开数据库的时候)。这个应答,就像其他临时应答一样,种植了UAC重新传送INVITE请求。100(Trying)应答和其他临时应答不同的是,在这里,它永远不会被有状态proxy转发到上行流中。 
    1.2 180 Ringing 
    UA收到INVITE请求并且试图提示给用户。这个应答应当出世化一个本地回铃。 
    1.3 818 Call is Being Forwarded(呼叫被转发) 
    服务器可以用这个应答代码来表示呼叫正在转发到另一个目的地集合。 
    1.4 182 Queued 
    当呼叫的对方暂时不能接收呼叫的时候,并且服务器决定将呼叫排队等候,而不是拒绝呼叫的时候,那么就应当发出这个应答。当被叫方一旦恢复接收呼叫,他会返回合适的终结应答。对于这个呼叫状态,可以有一个表示原因的短语,比如:”5 calls queued;expected waiting time is 15minutes”。服务器可以给出好几个182(Queued)应答告诉呼叫方排队的情况(比如排队靠前了等等)。 
    1.5 183 会话进度 
    183(Session Progress)应答用于提示建立对话的进度信息。Reason-Phrase(表达原因的句子)、头域或者消息体可以用于提示呼叫进度的更消息的信息。 

    2 成功信息2xx 
    这个应答表示请求是成功的。 
    2.1 200 OK 
    请求已经处理成功。这个信息取决于不同方法的请求的应答。 

    3 转发请求3XX 
    3xx系列的应答是用于提示用户的新位置信息的,或者为了满足呼叫而转发的额外服务地点。 
    3.1 300 Multiple Choices 
    请求的地址有多个选择,每个选择都有自己的地址,用户或者(UA)可以选择合适的通讯终端,并且转发这个请求到这个地址。 
    应答可以包含一个具有每一个地点的在Accept请求头域中允许的资源特性,这样用户或者UA可以选择一个最合适的地址来转发请求。没有未这个应答的消息体定义MIME类型。 
    这些地址选择也应当在Contact头域中列出(20.10节)。不同于HTTP,SIP应答可以包含多个Contact头域或者一个Contact头域中具有一个地址列表。UA可以使用Contact头域来自动转发或者要求用户确认转发。不过,本规范没有定义自动转发的标准。 
    如果被叫方可以在多个地址被找到,并且服务器不能或者不愿意转发请求的时候,可以使用这个应答来给呼叫方。 
    3.2 301 Moved Permently 
    当不能在Request-URI指定的地址找到用户的时候,请求的客户端应当使用Contact头域(20.10)所指出的新的地址重新尝试。请求者应当用这个新的值来更新本地的目录,地址本,和用户地址cache,并且在后续请求中,发送到这个/这些列出的地址。 
    3.3 302 Moved Temporarily 
    请求方应当把请求重新发到这个Contact头域所指出的新地址(20.10)。新请求的Request-URI应当用这个应答的Contact头域所指出的值。 
    在应答中的Expires(20.19节)或者Contact头域的expires参数定义了这个Contact URI的生存周期。UA或者proxy在这个生存周期内cache这个URI。如果没有严格的有效时见,那么这个地址仅仅本次有效,并且不能在以后的事务中保存。 
    如果cache的Contact头域的值失败了,那么被转发请求的Request-URI应当再次尝试一次。临时URI可以比超时时间更快的失效,并且可以有一个新的临时URI。 
    3.4 305 Use Proxy 
    请求的资源必须通过Contact头域中指出的proxy来访问。Contact头域指定了一个proxy的URI。接收到这个应答的对象应当通过这个proxy重新发送这个单个请求。305(UseProxy)必须是UAS产生的。 
    3.5 380 Alternative Service 
    呼叫不成工,但是可以尝试另外的服务。另外的服务在应答的消息体中定义。消息体的格式在这里没有定义,可能在以后的规范中定义。 

    4 请求失败4xx 
    4xx应答定义了特定服务器响应的请求失败的情况。客户端不应当在不更改请求的情况下重新尝试同一个请求。(例如,增加合适的认证信息)。不过,同一个请求交给不同服务器也许就会成功。 
    4.1 400 Bad Request 
    请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误,比如”Missing Call-ID header field”。 
    4.2 401 Unauthorized 
    请求需要用户认证。这个应答是由UAS和注册服务器产生的,当407(Proxy Authentication Required)是proxy服务器产生的。 
    4.3 402 Payment Required 
    保留/以后使用 
    4.4 403 Forbidden 
    服务端支持这个请求,但是拒绝执行请求。增加验证信息是没有必要的,并且请求应当不被重试。 
    4.5 404 Not Found 
    服务器返回最终信息:用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下, 也会产生这个应答。 
    4.6 405 Method Not Allowed 
    服务器支持Request-Line中的方法,但是对于这个Request-URI中的地址来说,是不允许应用这个方法的。 
    应答必须包括一个Allow头域,这个头域包含了指定地址允许的方法列表。
    4.7 Not Acceptable 
    请求中的资源只会导致产生一个在请求中的Accept头域外的,内容无法接收的错误。 
    4.8 407 Proxy Authentication Required 
    这个返回码和401(Unauthorized)很类四,但是标志了客户端应当首先在proxy上通过认证。SIP对认证的访问请参见26节和22.3节。 
    这个返回码用于应用程序访问通讯网关(比如,电话网关),而很少用于被叫方要求认证。 
    4.9 408 Request Timeout 
    在一段时间内,服务器不能产生一个终结应答,例如,如果它无法及时决定用户的位置。客户端可以在稍后不更改请求的内容然后重新尝试请求。 
    4.10 410 Gone 
    请求的资源在本服务器上已经不存在了,并且不知道应当把请求转发到哪里。这个问题将会使永久性的。如果服务器不知道,或者不容易检测,这个资源消失是临时性质的还是永久性质的,那么应当返回一个404(Not Found)。 
    4.11 413请求实体过大。 
    服务器拒绝处理请求,因为这个请求的实体超过了服务器希望或者能够处理的大小。这个服务器应当关闭连接避免客户端重发这个请求。 
    如果这个情况是暂时的,那么服务端应当包含一个Retry-After头域来表明这是一个暂时的故障,并且客户端可以过一段时间再次尝试。 
    4.12 414 Request-URI Too Long 
    服务器拒绝这个请求,因为Request-URI超过了服务器能够处理的长度。 
    4.13 415 Unsupported Media Type 
    服务器由于请求的消息体的格式本服务器不支持,所以拒绝处理这个请求。这个服务器必须根据内容的故障类型,返回一个Accept,Accpet-Encoding,或者Accept-Language头域列表。UAC根据8.1.3.5节定义的方法处理这个应答。 
    4.14 416 Unsupported URI Scheme 
    服务器由于不支持Request-URI中的URI方案而终止处理这个请求。客户端处理这个应答参照8.1.3.5。 
    4.15 Bad Extension 
    服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不支持的扩展。UAC处理这个应答请参见8.1.3.5 
    4.16 421Extension Required 
    UAS需要特定的扩展来处理这个请求,但是这个扩展并没有在请求的Supported头域中列出。具有这个应答码的应答必须包含一个Require头域列出所需要的扩展。 
    UAS不应当使用这个应答除非它真的不能给客户端提供有效的服务。相反,如果在Support头域中没有列出需要的扩展,服务器应当根据基准的SIP兼容的方法和客户端支持的扩展来进行处理。 
    4.17 423 Interval Too Brief 
    服务器因为在请求中设置的资源刷新时间(或者有效时间)过短而拒绝请求。这个应答可以用于注册服务器来拒绝那些Contact头域有效期过短的注册请求。这个应答的用法和相关的Min-Expires头域在10.2.8,10.3,20.23节中介绍和说明。 
    4.18 480 Temporarily Unavailable 
    请求成功到达被叫方的终端系统,但是被叫方当前不可用(例如,没有登陆,或者登陆了但是状态是不能通讯,或者有”请勿打扰”的标记)。应答应当在Retry-After中标志一个合适的重发时间。这个用户也有可能在其他地方是有效的(在本服务器中不知道)。Reason-Phrase(原因短句)应当提示更详细的原因,为什么被叫方暂时不可用。这个值应当是可以被UA设置的。状态码486(Busy Here)可以用来更精确的表示本请求失败的特定原因。 
    这个状态码也可以是转发服务或者proxy服务器返回的,因为他们发现Request-URI指定的用户存在,但是没有一个给这个用户的合适的当前转发的地址。 
    4.19 481 Call/Transaction Does Not Exist 
    这个状态表示了UAS接收到请求,但是没有和现存的对话或者事务匹配。 
    4.20 482 Loop Detected 
    服务器检测到了一个循环(16.3/4) 
    4.21 483 Too Many Hops 
    服务器接收到了一个请求包含的Max-Forwards(20.22)头域是0 
    4.22 484 Address InComplete 
    服务器接收到了一个请求,它的Request-URI是不完整的。在原因短语中应当有附加的信息说明。这个状态码可以和拨号交叠。在和拨号交叠中,客户端不知道拨号串的长度。它发送增加长度的字串,并且提示用户输入更多的字串,直到不在出现484(Address Incomplete)应答为止。 
    4.23 485 Ambiguous 
    Request-URI是不明确的。应答可以在Contact头域中包含一个可能的明确的地址列表。这个提示列表肯囊个在安全性和隐私性对用户或者组织造成破坏。必须能够由配置决定是否以404(NotFound)代替这个应答,又或者禁止对不明确的地址使用可能的选择列表。 
    给带有Request-URI的请求的一个应答例子: 
    sip: lee@example.com: 
    SIP/2.0 485 Ambiguous 
    Contact: Carol Lee 
    Contact: Ping Lee 
    Contact: Lee M.Foote 
    部分email和语音邮箱系统提供了这个功能。这个状态码和3xx状态码不同:对于300来说,它是假定同一个人或者服务有不同的地址选择。所以对3xx来说,自动选择系统或者连续查找就有效,但是对485(Ambiguous)应答来说,一定要用户的干预。 
    4.24 486 Busy Here 
    当成功联系到被叫方的终端系统,但是被叫方当前在这个终端系统上不能接听这个电话,那么应答应当回给呼叫方一个更合适的时间在Retry-After头域重试。这个用户也许在其他地方有效,比如电话邮箱系统等等。如果我们知道没有其他终端系统能够接听这个呼叫,那么应当返回一个状态码600(Busy Everywhere)。 
    4.25 487 Request Terminated 
    请求被BYE或者CANCEL所终止。这个应答永远不会给CANCEL请求本身回复。 
    4.26 488 Not Acceptable Here 
    这个应答和606(Not Acceptable)有相同的含义,但是只是应用于Request-URI所指出的特定资源不能接受,在其他地方请求可能可以接受。 
    包含了媒体兼容性描述的消息体可以出现在应答中,并且根据INVITE请求中的Accept头域进行规格化(如果没有Accept头域,那么就是application/sdp)。这个应答就像给OPTIONS请求的200(OK)应答的消息体一样。 
    4.27 491 Request Pending 
    在同一个对话中,UAS接收到的请求有一个依赖的请求正在处理。14.2描述了这种情况应当怎样解决。 
    4.28 493 Undecipherable 
    UAS接收到了一个请求,包含了一个加密的MIME,并且不知道或者没有提供合适的解密密钥。这个应答可以包含单个包体,这个包体包含了合适的公钥,这个公钥用于给这个UAS通讯中加密包体使用的。细节描述在23.2节。 

    5 Server Failure 5xx 
    5xx应答是当服务器本身故障的时候给出的失败应答。 
    5.1 500 Server Internal Error 
    服务器遇到了未知的情况,并且不能继续处理请求。客户端可以显示特定的错误情况,并且可以在几秒种以后重新尝试这个请求。 
    如果这个情况是临时的,服务器应当在Retry-After头域标志客户端过多少秒钟之后重新尝试这个请求。
    5.2 501 Not Implemented 
    服务器没有实现相关的请求功能。当UAS不认识请求的方法的时候,并且对每一个用户都无法支持这个方法的时候,应当返回这个应答。(proxy不考虑请求的方法而转发请求)。 
    注意405(Method Not Allowed)是因为服务器实现了这个请求方法,但是这个请求方法在特定请求中不被支持。 
    5.3 502 Bad Gateway 
    如果服务器,作为gateway或者proxy存在,从下行服务器上接收到了一个非法的应答(这个应答对应的请求是本服务器为了完成请求而转发给下行服务器的)。 
    5.4 503 Service Unavailable 
    由于临时的过载或者服务器管理导致的服务器暂时不可用。这个服务器可以在应答中增加一个Retry-After来让客户端重试这个请求。如果没有Retry-After指出,客户端必须就像收到了一个500(Server Internal Error)应答一样处理。 
    客户端(proxy或者UAC)收到503(Service Unavailable)应当尝试转发这个请求到另外一个服务器处理。并且在Retry-After头域中指定的时间内,不应当转发其他请求到这个服务器。 
    作为503(Service Unavaliable)的替代,服务器可以拒绝连接或者把请求扔掉。 
    5.5 504 Server Time-out 
    服务器在一个外部服务器上没有收到一个及时的应答。这个外部服务器是本服务器用来访问处理这个请求所需要的。如果从上行服务器上收到的请求中的Expires头域超时,那么应当返回一个408(Request TimeOut)错误。 
    5.6 505 Version Not Supported 
    服务器不支持对应的SIP版本。服务器是无法处理具有客户端提供的相同主版本号的请求,就会导致这样的错误信息。 
    5.7 Message To Large 
    服务器无法处理请求,因为消息长度超过了处理的长度。 

    6 Global Failures 6xx 
    6xx应答意味这服务器给特定用户有一个最终的信息,并不只是在Request-URI的特定实例有最终信息。 
    6.1 600 Busy Everywhere 
    成功联系到被叫方的终端系统,但是被叫方处于忙的状态,并不打算接听电话。这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。如果被叫方不希望提示拒绝的原因,被叫方应当使用603(Decline)。只有当终端系统知道没有其他终端节点(比如语音邮箱系统)能够访问到这个用户的时候才能使用这个应答。否则应当返回一个486(Busy Here)的应答。
    6.2 603 Decline 
    当成功访问到被叫方的设备,但是用户明确的不想应答。这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。 
    6.3 604 Does Not Exists Anywhere 
    服务器验证了在请求中Request-URI的用户信息,哪里都不存在 
    6.4 606 Not Acceptable 
    当成功联系到一个UA,但是会话描述的一些部分比如请求的媒体,带宽,或者地址类型不被接收。 
    606(NotAcceptable)应答意味着用户希望通讯,但是不能充分支持会话描述。606(Not Acceptable)应答可以在Warning头域中包含一个原因列表,用于解释为何会话描述不能被支持。警告原因代码在20.43节中列出。 
    在应答中,可以出现一个包含媒体兼容性描述的消息体,这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化(如果没有Accept头域,那么就是application/sdp),就像给OPTIONS亲求的200(OK)应答中的消息一样。 
    我们希望这些媒体协商不要经常需要,并且当一个新用户被邀请加入已经存在的会话的时候,这个媒体协商可能不需要。这取决于邀请的初始化者是否需要对606(Not Acceptable)进行处理。 
    这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。
    展开全文
  • 微信的消息类型

    千次阅读 2018-08-09 12:33:33
    文本消息 3 图片消息 34 语音消息 37 好友确认消息 40 POSSIBLEFRIEND_MSG 42 共享名片 43 视频消息 47 动画表情 48 位置消息 49 分享链接 50 VOIPMSG 51 ...
    MsgType 说明
    1 文本消息
    3 图片消息
    34 语音消息
    37 好友确认消息
    40 POSSIBLEFRIEND_MSG
    42 共享名片
    43 视频消息
    47 动画表情
    48 位置消息
    49 分享链接
    50 VOIPMSG
    51 微信初始化消息
    52 VOIPNOTIFY
    53 VOIPINVITE
    62 小视频
    9999 SYSNOTICE
    10000 系统消息
    10002 撤回消息
    展开全文
  • 在ROS中定义并使用自己的消息类型

    千次阅读 2017-05-15 15:54:58
    但是总时候系统自带的消息类型无法满足工程的特殊需要,这时我们可以自定义消息类型。  本文假设需求如下:节点node1每次向外发送的数据是point点的集合,但是点集中点数动态变化, 每个点用a, b, c表示其三维...
  • Windows消息类型及说明

    千次阅读 2016-12-02 11:14:06
    窗口消息,一般用在SendMessage,PostMessage这样的消息函数中 SM_ Static Message 静态标签消息 SS_ Static Style 静态标签风格 BM_ Button Message 按钮消息 BS_ ...
  • ros:消息类型总结

    千次阅读 2019-04-11 15:25:16
    1, rostopic info [消息名字]; 可以得到Type:信息. 例 $ rostopic info /odom Type: nav_msgs/Odometry Publishers: * /mobile_base_nodelet_manager (http://192.168.137.5:59351/) Subscribers: None 2, 根据上述...
  • ET框架---消息类型浅析

    千次阅读 2018-04-13 15:15:15
    在我写之前,已经其他人对ET的消息类型做了分析,大家可以先去看一下。ET消息流程。 里面对ET消息的类图很详细的分析。 这里,我在讲一下我自己的理解,方便看完后还是一脸懵逼的同学理解。 我们先别管那些类...
  • SIP请求消息类型与应答码

    千次阅读 2016-04-04 15:59:45
    许多类型消息请求。SIP通过请求和应答传递、交流。下面表格中描述的是许多重要类型的请求: 大多数时间内,你会使用到 REGISTER, INVITE, BYE 还有 CANCEL。而另外一些消息会被用在其他的特性当中。举例来说...
  • BGP消息类型及配置BGP

    千次阅读 2013-07-03 11:04:36
    * BGP消息类型  -- Open: 用于建立BGP对等体之间的连接关系  -- Keepalive: 周期性地向BGP对等体发出Keepalive消息, 用来保持连接的有效性  -- Update: 携带的是路由更新(删减、增加)信息  -- Notification: ...
  • ROS的常见的消息类型

    千次阅读 2019-12-12 10:07:37
    rviz中显示的是一个方向的箭头 std_msgs / Header header string child_frame_id geometry_msgs / PoseWithCovariance pose //位置和方向 geometry_msgs / TwistWithCovariance twist //角速度和线速度 ...
  • Redis 5.0 带来了 Stream 类型,从字面上看是流类型,但其实从功能上看,应该是 Redis 对消息队列(MQ,Message Queue)的完善实现。用过 Redis 做消息队列的都了解,基于 Reids 的消息队列实现很多种,例如:PUB/...
  • ROS实操入门系列(六)ROS topic通讯之自定义复杂msg消息类型解决实际需求 常见Msg消息需求一自定义消息编写代码需求一升级,需要定义更多的复杂消息(下一章) msg消息 是ROS topic通讯节点间传递的内容。msg消息描述...
  • ERR 当RobooHELP帮助编译器企图编译一个帮助系统源文件时用来存储错误消息的文件 EPX ERWin文件 ESPS ESPS音频文件 EUI Ensoniq ESP家族的压缩磁盘映像 EVY 特使文档 EWL Microsoft Encarta文档 EXC Microsoft...
  • 用户消息类型 对于用户通过键盘或者触摸屏等输入设备产生的消息是不会直接进入到View系统中的,而是首先被消息处理前端做了一层拦截和消息码的转换,完成从原始的硬件码值到操作系统所能识别的码值转换,之后Wms...
  • 发布的主题名称 (定义了消息发布类型: ControlRobot::RobotControl ) ros: :Rate loop_rate( 10 ); while ( ros: :ok ()){ ControlRobot::RobotControl RobotCordinate ; // 相当于定义了一个结构体...
  • 在传统的服务器系统中,服务器仅针对接收到的客户端消息进行解析,并处理后回复响应...不同类型的设备的消息处理机制不同,同一类型的网页端和移动端的消息处理也可能存在些许差别。此时服务器就需要对多种类型的设...
  • InnerException 消息是“反序列化对象 属于类型 System.String 时出现错误。读取 XML 数据时,超出最大字符串内容长度配额 (8192)。通过更改在创建 XML 读取器时所使用的 XmlDictionaryReaderQuotas 对象...
  • InnerException 消息是“反序列化对象 属于类型 System.String 时出现错误。读取 XML 数据时,超出最大字符串内容长度配额 (8192)。通过更改在创建 XML 读取器时所使用的 XmlDictionaryReaderQuotas 对象的 ...
  • 早在一年之前,就曾负责一款IM移动通信类型的App开发,部分相关的功能都是仿照微信来进行,例如:聊天,通信录,朋友圈等。由于,整个团队都没有IM方面的经验, 我们只能不断地摸索前进,所以这篇文章也只适合初级IM...
  •  早在一年之前,就曾负责一款IM移动通信类型的App开发,部分相关的功能都是仿照微信来进行,例如:聊天,通信录,朋友圈 等。由于,整个团队都没有IM方面的经验,我们只能不断地摸索前进,所以这篇文章也只适合...
  • 类似于微信客户度那样,哪一个模块有消息更新,那个模块上面就个小红点来提示用户:hey,guys,You have got the new messages,click me。所以在服务器推送过来的消息,必须要让客户端清晰的解说出来----这条消息是...
  • 第1章 L3 RRC层功能概述...RRC协议两个大的基本功能 (1)在基站和手机之间传递L3层无线资源控制信令, 即接入层信令AS,比如为终端建立无线数据承载, (2)帮助手机和核心网信令网关在空口传递"非接入层信令NAS...
  • MFC消息分类与消息队列

    千次阅读 2017-02-08 11:22:22
    而wParam,lParam是其最灵活的两个变量,为不同的消息类型时,存放数据的含义也不一样。 time表示产生消息的时间,pt表示产生消息时鼠标的位置。 按照类型,Windows将消息分为: (0) 消息ID范围 系统定义...
  • 消息缓冲机制

    千次阅读 2017-04-08 16:54:57
    消息是指具有类型和数量的一个数据。消息分共有和私有的,如果消息为私有的,只能被创建消息队列的进程和其子进程访问;如果是公有的,可以被系统中知道消息队列名的所有进程访问。消息可以按类型访问,因此,不必按...
  • Android消息推送:第三方消息推送平台详细解析

    万次阅读 多人点赞 2016-10-19 19:33:50
    消息推送在Android开发中应用的场景是越来越多了,比如说电商产品进行活动宣传、资讯类产品进行新闻推送等等,如下图: 本文将介绍Android中实现消息推送的第三方推送的详细解决方案 阅读本文前,建议先阅读我的写...
  • JAVA的简单数据类型和复合数据类型

    千次阅读 2013-05-01 20:31:14
    Java的简单数据类型 数据类型 数据类型就是对内存位置的抽象表达。程序员可以利用多种数据类型:某些由编程语言定义,某些由外部库定义,还有些则由程序员来定义。很多编程语言都依赖于特定的计算机类型和对...
  • Windows 消息机制

    千次阅读 2013-05-20 20:22:20
    参考一: Windows消息机制要点 1. 窗口过程 ... 每个窗口会一个称为窗口过程的回调函数(WndProc),它带四个参数,分别为:窗口句柄(Window Handle),消息ID(Message ID),和...2 消息类型 1) 系统定义消息(S
  • MFC 消息响应与消息处理过程

    千次阅读 2015-08-24 15:32:35
    WPARAM 和 LPARAM,消息响应机制 wParam和lParam 这两个是Win16系统遗留下来的产物,在Win16API中WndProc两个参数: 一个是WORD类型的16位整型变量;另一个是LONG类型的32位整型变量。因此根据匈牙利命名法,16位...
  • protobuf 数据类型

    千次阅读 2017-03-26 16:44:54
    要通信,必须协议,否则双方无法理解对方的码流。在protobuf中,协议是由一系列的消息组成的。...字段格式:限定修饰符① | 数据类型② | 字段名称③ | = | 字段编码值④ | [字段默认值⑤] 例如:repe

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 223,226
精华内容 89,290
关键字:

属于消息类型的有