博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

STOMP协议详解

Posted on 2017-06-13 16:49  bw_0927  阅读(20113)  评论(0)  编辑  收藏  举报

http://blog.csdn.net/chszs/article/details/46592777

http://nikipore.github.io/stompest/

https://stomp.github.io/stomp-specification-1.1.html#Heart-beating

https://nikipore.github.io/stompest/protocol.html

 

the sender MUST send new data over the network connection at least every <n> milliseconds   配了heartbeat，你就必须主动发数据，否则会被断开

 

 

SUBSCRIBE id Header

 

An id header MUST be included in the frame to uniquely identify the subscription within the STOMP connection session. Since a single connection can have multiple open subscriptions with a server, the id header allows the client and server to relate subsequent ACK, NACK or UNSUBSCRIBEframes to the original subscription.

 

StompConfig(uri, amq_config['USER'], amq_config['PASSWORD'], version=StompSpec.VERSION_1_2)

1.2版本的subscribe消息需要id头

 

 

一、STOMP协议介绍

STOMP即Simple (or Streaming) Text Orientated Messaging Protocol，简单(流)文本定向消息协议，它提供了一个可互操作的连接格式，允许STOMP客户端与任意STOMP消息代理（Broker）进行交互。STOMP协议由于设计简单，易于开发客户端，因此在多种语言和多种平台上得到广泛地应用。

STOMP协议的前身是TTMP协议（一个简单的基于文本的协议），专为消息中间件设计。

STOMP是一个非常简单和容易实现的协议，其设计灵感源自于HTTP的简单性。尽管STOMP协议在服务器端的实现可能有一定的难度，但客户端的实现却很容易。例如，可以使用Telnet登录到任何的STOMP代理，并与STOMP代理进行交互。

STOMP协议与2012年10月22日发布了最新的STOMP 1.2规范。
要查看STOMP 1.2规范，见： https://stomp.github.io/stomp-specification-1.2.html

二、STOMP的实现

业界已经有很多优秀的STOMP的服务器/客户端的开源实现，下面就介绍一下这方面的情况。

1、STOMP服务器

项目名兼容STOMP的版本描述
Apache Apollo 1.0 1.1 1.2 ActiveMQ的继承者 http://activemq.apache.org/apollo
Apache ActiveMQ 1.0 1.1 流行的开源消息服务器 http://activemq.apache.org/
HornetQ 1.0 来自JBoss的消息中间件 http://www.jboss.org/hornetq
RabbitMQ 1.0 1.1 1.2 基于Erlang、支持多种协议的消息Broker，通过插件支持STOMP协议 http://www.rabbitmq.com/plugins.html#rabbitmq-stomp
Stampy 1.2 STOMP 1.2规范的一个Java实现 http://mrstampy.github.com/Stampy/
StompServer 1.0 一个轻量级的纯Ruby实现的STOMP服务器 http://stompserver.rubyforge.org/

这里只列了部分。

2、STOMP客户端库

项目名兼容STOMP的版本描述
activemessaging 1.0 Ruby客户端库 http://code.google.com/p/activemessaging/
onstomp 1.0 1.1 Ruby客户端库 https://rubygems.org/gems/onstomp
Apache CMS 1.0 C++客户端库 http://activemq.apache.org/cms/
Net::STOMP::Client 1.0 1.1 1.2 Perl客户端库 http://search.cpan.org/dist/Net-STOMP-Client/
Gozirra 1.0 Java客户端库 http://www.germane-software.com/software/Java/Gozirra/
libstomp 1.0 C客户端库，基于APR库 http://stomp.codehaus.org/C
Stampy 1.2 Java客户端库 http://mrstampy.github.com/Stampy/
stomp.js 1.0 1.1 JavaScript客户端库 http://jmesnil.net/stomp-websocket/doc/
stompest 1.0 1.1 1.2 Python客户端库，全功能实现，包括同步和异步 https://github.com/nikipore/stompest
StompKit 1.2 Objective-C客户端库，事件驱动 https://github.com/mobile-web-messaging/StompKit/
stompngo 1.0 1.1 1.2 Go客户端库 https://github.com/gmallard/stompngo
stomp.py 1.0 1.1 1.2 Python客户端库 https://github.com/jasonrbriggs/stomp.py
tStomp 1.1 TCL客户端库 https://github.com/siemens/tstomp

这里只列了部分。

三、STOMP协议分析

STOMP协议与HTTP协议很相似，它基于TCP协议，使用了以下命令：

CONNECT
SEND
SUBSCRIBE
UNSUBSCRIBE
BEGIN
COMMIT
ABORT
ACK
NACK
DISCONNECT

STOMP的客户端和服务器之间的通信是通过“帧”（Frame）实现的，每个帧由多“行”（Line）组成。
第一行包含了命令，然后紧跟键值对形式的Header内容。
第二行必须是空行。
第三行开始就是Body内容，末尾都以空字符结尾。
STOMP的客户端和服务器之间的通信是通过MESSAGE帧、RECEIPT帧或ERROR帧实现的，它们的格式相似。

 

 

http://diaocow.iteye.com/blog/1725186

==========

Stomp是一个简单的消息文本协议,它的设计核心理念就是简单与可用性，官方文档：http://stomp.github.com/stomp-specification-1.1.html 

现在我们就来实践一下Stomp协议，你需要的是： 

1.一个支持stomp消息协议的messaging server(譬如activemq，rabbitmq）； 
2.一个终端（譬如linux shell); 
3.一些基本命令与操作（譬如nc，telnet) 

1.建立连接 
当我们（Client端）向服务器发送一个CONNECT Frame，就向服务器发起了一个连接请求，此时服务器端返回一个CONNECTED Frame表示建立连接成功，其中头字段version表示采用的stomp协议版本（这里默认是1.0） 

 
ps: ^@符号 ctrl+@键(用来提交请求），删除之前输入的数据 ctrl+n+backspace键 

当然Client端也可指定所支持的协议版本（accept-version字段，多个版本按递增顺序排列，并用逗号分隔）； 

 

服务器此时返回的CONNECTED Frame中会列出它所支持的协议版本号中最高的那个（如上图的version：1.1） 

如果服务器端不支持客户端所列举的协议版本（比如这里的2.1），那么服务器会返回一个ERROR Frame并且列举出服务器自己所支持的协议版本（如下图的version:1.0,1.1） 

 


2.消息传递 
客户端一旦与服务器端建立连接，那么就可发送下列Frame进行消息传递 

SEND
SUBSCRIBE
UNSUBSCRIBE
ACK
NACK
BEGIN
COMMIT
ABORT
DISCONNECT


SEND Frame 用来将客户端消息发送到目的地（destination）,因此它必须指定一个destination头字段，另外在所有头字段之后，新起一个空行，之后就是需要发送的消息（譬如这里的 hello stomp!) 

 

此时"hello stomp!" 这条消息就被发送到了队列 my_queue中去 

现在我们再起一个客户端clinet_a，来接受这个队列（myqueue）中的消息 

 

SUBSCRIBE Frame 表示客户端希望订阅某一个目的地（destination）的消息（这里是/queue/my_queue），其中头字段id表示在一个会话连接里，唯一标示一个订阅者（subscription），头字段destination标示该订阅者（subscription）需要订阅的目的地（这里是一个队列，/queue/my_queue) 

紧接着，我们就接受到服务器端发送来的消息（MESSAGE Frame），其中message_id:唯一标示了这条消息（后面我们会使用这个消息id进行ack,uack操作），content-length:标示消息体的长度，在所有这些头后面，新起一个空行就是消息内容（如这里的hello stomp!） 

如此时我们希望订阅另一个destination，该如何办呢？，是不是再发送一个SUBSCRIBE Frame就好了？ 

 

结果发现服务器端返回了ERROR Frame 告诉我们SUBSCRIBE失败，原来同一个subscription id只能订阅一个destination，要想订阅令一个destination，必须先发送UNSUBSCRIBE Frame,然后再SUBSCRIBE 到新的目的地 

 

UNSCUBSCRIBE Frame中的id标示需要取消订阅的subscription，然后我们在订阅到新的destination（这里是/queue/other_queue),可以发现订阅成功，服务器没有再发送ERROR Frame 

至此，我们就模拟出了一个PTP（point-to-point）消息模型，下面我们也模拟下另外一个pub/sub消息模型： 

准备工作，新起两个连接订阅到/topic/my_topic上，如下图: 
clinet_a 
 

client b 
 

Send端发送广播消息： 
 

我们去检查下两个消息接收客户端，果然发现收到了这条广播消息^_^ 
client a 
 

client b 
 

默认情况下，只要服务器端发送消息，就认为客户端接收成功（即ack模式为auto），若我们需要更严格的消息保证，则必须采用client模式，即由客户端确认消息的接受 

服务器发送了一个消息到/queue/ackqueue 

 

此时我们的客户端client_a确实接受到了该消息 

 

虽然该消息已经发送到客户端，但是由于该消息没有确认（ack），则该消息还保存在队列/queue/ackqueue中（直到客户端确认才删除），我们可以通过rabbitmq提供的命令来查看（sudo rabbitmqctl list_queues name messages_ready messages_unacknowledged）： 

 

若客户端在确认消息前与客户端断开连接，那么服务器可能(根据不同server的设计而不同)会选择将该消息发送给另一个subscription（这里是client_b） 

 

可以看出rabbit是选择将它发送给另一个subscription， 我们在使用命令查ack_queue队列中是否还有未确认的消息 

 

结果发现没有了 ^_^ 

若是客户端希望确认一个消息，该如何做呢？，只要发送一个ACK Frame即可! 
在ACK Frame中，subscription标示是谁确认消息，message-id标示是确认哪条消息（即MESSAGE Frame中携带的message-id） 

 

另外我在rabbitmq的测试结果发现，ack具有累积效应(因为这里SUBSCRIBE帧的ack头被设置成了‘client’)，譬如接收了10条消息，如果你ack了第8条消息，那么1-7条消息都会被ack，只有9-10两条消息还保持未ack状态 

除了有ACK Frame，还有NACK Frame，它表示客户端未成功接收某条消息，这时候服务器可以选择重发或者丢弃（对于rabbitmq，我的测试结果是选择重发） 


3.断开连接 
说完了连接的建立，消息的发送与接收，现在我们来看看客户端如何与服务器断开连接的，更重要的是如何安全的断开连接 

 

通过发送DISCONNNECT Frame表示向服务器发送一个断开连接请求，其中receipt表示服务器收到请求后请告知客户端，并返回一个相同的receipt-id 


至此关于Stmop绝大部分概念，我们已经实践完毕，如需更详细的还请翻阅官方文档 ^_^ 

 

================

http://www.cnblogs.com/davidwang456/p/4449428.html

 

 

http://nikipore.github.io/stompest/sync.html?highlight=stompest%20sync#module-stompest.sync.client

 

STOMP Frames

STOMP是基于帧的协议，它假定底层为一个2-way的可靠流的网络协议（如TCP）。客户端和服务器通信使用STOMP帧流通讯。帧的结构看起来像：

COMMAND
header1:value1
header2:value2

Body^@

帧以command字符串开始,以EOL结束，其中包括可选回车符（13字节），紧接着是换行符（10字节）。command下面是0个或多个<key>:<value>格式的header条目, 每个条目由EOL结束。一个空白行（即额外EOL）表示header结束和body开始。body连接着NULL字节。本文档中的例子将使用^@,在ASCII中用control-@表示，代表NULL字节。NULL字节可以选择跟多个EOLs。欲了解更多关于STOMP帧的详细信息，请参阅Augmented BNF节本文件。

本文档中引用的所有command 和header 名字都是大小写敏感的.

只有SEND, MESSAGE, 和ERROR帧有body。所有其他的帧不能有body。

 

content-length

content-type

receipt

任何客户端帧(除了CONNECT帧)都可以为receipt header指定任何值。这会让服务端应答带有RECEIPT的客户端帧的处理过程。

如果client或者server收到重复的header条目，只有第一个会被用作header条目的值。其他的值仅仅用来维持状态改变，或者被丢弃。

例如，如果client收到:

MESSAGE
foo:World
foo:Hello

^@

foo header的值为World.

 

大小限制

为了客户端滥用服务端的内存分配，服务端可以设置可分配的内存大小:

  • 单个帧允许帧头的个数
  • header中每一行的最大长度
  • 帧体的大小

如果超出了这些限制，server应该向client发送一个error frame,然后关闭连接.

连接延迟

STOMP servers必须支持client快速地连接server和断开连接。 这意味着server在连接重置前只允许被关闭的连接短时间地延迟.

结果就是，在socket重置前client可能不会收到server发来的最后一个frame(比如ERROR或者RECEIPTframe去应答DISCONNECTframe)

 

  • Client Frames

client可以发送下列列表以外的frame，但是STOMP1.2 server会响应ERROR frame,然后关闭连接。

SUBSCRIBE 消息

SUBSCRIBE frame用于注册给定的目的地. 和SENDframe一样，SUBSCRIBEframe需要包含destination header表明client想要订阅目的地。 被订阅的目的地收到的任何消息将通过MESSAGE frame发送给client。 ack header控制着确认模式。

例子:

SUBSCRIBE
id:0
destination:/queue/foo
ack:client                   //ACK头

^@

如果server不能成功创建此次订阅，那么server将返回ERROR frame然后关闭连接。

STOMP服务器可能支持额外的服务器特定的头文件，来自定义有关订阅传递语义.

SUBSCRIBE消息的 id 头

一个单连接可以对应多个开放的servers订阅,所以必须包含id header去唯一标示这个订阅. 这个id frame可以把此次订阅与接下来的MESSAGE frame和UNSUBSCRIBE frame联系起来。

在相同的连接中，不同的订阅必须拥有不同订阅id。

SUBSCRIBE消息的 ack 头

ack header可用的值有auto, client, client-individual, 默认为auto.

  1. 当ack为auto时，client收到server发来的消息后不需要回复ACK frame. server假定消息发出去后client就已经收到。这种确认方式可以减少消息传输的次数.
  2. 当ack为client时, client必须发送ACK frame给servers, 让它处理消息. 如果在client发送ACK frame之前连接断开了，那么server将假设消息没有被处理，可能会再次发送消息给另外的客户端。

　　　　client发送的ACK frame被当作是积累的确认。这就意味这种确认方式会去操作ACK frame指定的消息和订阅的所有消息. 

　　　　譬如接收了10条消息，如果你ack了第8条消息，那么1-7条消息都会被ack，只有9-10两条消息还保持未ack状态。

　　　　由于client不能处理某些消息，所以client应该发送NACK frame去告诉server它不能消费这些消息。

  1. 当ack模式是client-individual，确认工作就像上面的'client'确认模式(除了由客户端发送的ACK或NACK帧)不会被累计。这意味着，后续ACK, NACK消息帧，也不能影响前面的消息的确认。
ACK 消息

用来确认订阅的消息被消费了.

ACK
id:12345
transaction:tx1

^@

  • Server Frames

server偶尔也会发送frame给客户端(除了连接最初的CONNECTED frame).

这些frames为: * MESSAGE * RECEIPT * ERROR

RECEIPT帧

server成功处理带有receipt头的client frame后， 将发送RECEIPT frame到client.  RECEIPT frame必须包含receipt-id header,它的值为client frame中receipt header的值。

RECEIPT
receipt-id:message-12345

^@

RECEIPT frame是作为server处理的client frame后的应答. 既然STOMP是基于流的，那么receipt也是对server已经收到所有的frames的累积确认。但是，以前的frames可能并没有被完全处理。如果clients断开连接，以前接收到的frames应该继续被server处理。

=====

 

Examples

If you use ActiveMQ to run these examples, make sure you enable the STOMP connector, (see here for details):

<!-- add this to the config file "activemq.xml" -->
<transportConnector name="stomp" uri="stomp://0.0.0.0:61613"/>

For debugging purposes, it is highly recommended to turn on the logger on level DEBUG:

import logging
logging.basicConfig()
logging.getLogger().setLevel(logging.DEBUG)

Producer

from stompest.config import StompConfig
from stompest.sync import Stomp

CONFIG = StompConfig('tcp://localhost:61613')
QUEUE = '/queue/test'

if __name__ == '__main__':
    client = Stomp(CONFIG)
    client.connect()
    client.send(QUEUE, 'test message 1'.encode())
    client.send(QUEUE, 'test message 2'.encode())
    client.disconnect()

Consumer

from stompest.config import StompConfig
from stompest.protocol import StompSpec
from stompest.sync import Stomp
from stompest.error import StompConnectionError, StompProtocolError
import traceback

CONFIG = StompConfig('tcp://localhost:61613')
QUEUE = '/queue/test'

if __name__ == '__main__':
    client = Stomp(CONFIG)
    client.connect()
    client.subscribe(QUEUE, {StompSpec.ACK_HEADER: StompSpec.ACK_CLIENT_INDIVIDUAL})    //客户端的ack模式为client_individual
    while True:
　　　　 try:
　　　　　　if self.client.canRead(timeout=5):
　　       　　frame = client.receiveFrame()      //If we are not connected, this method will raise a StompConnectionError. Keep in mind that this method will block forever if there are no frames incoming on the wire. Be sure to use peek with self.canRead(timeout) before!
　　　         print('Got %s' % frame.info())
      　　    client.ack(frame)
　　　　 except (StompConnectionError, StompProtocolError) as e:
　　　　　　　  self.client.connect()
　 　　　except Exception as e:
　　　　　　　　self.logger.debug(traceback.format_exc())
    client.disconnect()