Stomp协议以及debug方法

1. http://blog.youkuaiyun.com/zsomsom/article/details/27076249
2. http://blog.youkuaiyun.com/yinwenjie/article/details/50698695  (一系列文章)
   
3. http://www.cnblogs.com/xuelu/p/3812817.html

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

现在我们就来实践一下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具有累积效应，譬如接收了10条消息，如果你ack了第8条消息，那么1-7条消息都会被ack，只有9-10两条消息还保持未ack状态 

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


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

 

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