-
Notifications
You must be signed in to change notification settings - Fork 10
/
stomp-specification-1.0.html
369 lines (276 loc) · 13.5 KB
/
stomp-specification-1.0.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Architecture
-->
<html lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
<meta content="The Simple Text Oriented Messaging Protocol" name="description"/>
<meta content="stomp,messaging,mom,middleware,specification" name="keywords"/>
<meta content="STOMP Specification" name="author"/>
<link type="text/css" rel="stylesheet" href="styles/impact/css/site.css"/>
<title></title>
</head>
<body>
<div id="navigation">
<div class="wrapper">
<ul>
<li><a href="index.html">STOMP</a></li>
<li><a href="stomp-specification-1.2.html">1.2</a></li>
<li><a href="implementations.html">Implementations</a></li>
</ul> <div></div>
</div>
</div>
<div id="content">
<div class="wrapper">
<h1 id = "Stomp_Protocol_Specification__Version_1_0">Stomp Protocol Specification, Version 1.0</h1>
<p>Initially the client must open a socket (I'm going to presume TCP, but really
it is kind of irrelevant). The client then sends:</p>
<pre><code>CONNECT
login: <username>
passcode:<passcode>
^@</code></pre>
<p>The <code>^@</code> is a null (control-@ in ASCII) byte. The entire thing will be called
a Frame in this doc. The frame starts with a command (in this case CONNECT),
followed by a newline, followed by headers in a <code><key></code>:<code><value></code> with each
header followed by a newline. A blank line indicates the end of the headers
and beginning of the body (the body is empty in this case), and the null
indicates the end of the frame.</p>
<p>After the client sends the CONNECT frame, the server will always acknowledge
the connection, by sending a frame which looks like:</p>
<pre><code>CONNECTED
session: <session-id>
^@</code></pre>
<p>The <code>session-id</code> header is a unique identifier for this session (though it
isn't actually used yet).</p>
<p>At this point there are a number of commands the client may send</p>
<ul>
<li><a href="#frame-SEND">SEND</a></li>
<li><a href="#frame-SUBSCRIBE">SUBSCRIBE</a></li>
<li><a href="#frame-UNSUBSCRIBE">UNSUBSCRIBE</a></li>
<li><a href="#frame-BEGIN">BEGIN</a></li>
<li><a href="#frame-COMMIT">COMMIT</a></li>
<li><a href="#frame-ABORT">ABORT</a></li>
<li><a href="#frame-ACK">ACK</a></li>
<li><a href="#frame-DISCONNECT">DISCONNECT</a></li>
</ul>
<h2 id = "Client_Commands">Client Commands</h2>
<h3 id="frame-SEND">SEND</h3>
<p>The SEND command sends a message to a destination in the messaging system. It
has one required header, <em>destination</em>, which indicates where to send the
message. The body of the SEND command is the message to be sent. For example:</p>
<pre><code>SEND
destination:/queue/a
hello queue a
^@</code></pre>
<p>This sends a message to the <em>/queue/a</em> destination. This name, by the way, is
arbitrary, and despite seeming to indicate that the destination is a “queue”
it does not, in fact, specify any such thing. Destination names are simply
strings which are mapped to some form of destination on the server - how the
server translates these is left to the server implementation. See <a href="http://activemq.apache.org/stomp.html">this note
on mapping destination strings to JMS
Destinations</a> for more detail.</p>
<p>SEND supports a <em>transaction</em> header which allows for transaction sends.</p>
<p>It is recommended that SEND frames include a content-length header which is a
byte count for the length of the message body. If a content-length header is
included, this number of bytes should be read, regardless of whether or not
there are null characters in the body. The frame still needs to be terminated
with a null byte and if a content-length is not specified, the first null
byte encountered signals the end of the frame.</p>
<h3 id="frame-SUBSCRIBE">SUBSCRIBE</h3>
<p>The SUBSCRIBE command is used to register to listen to a given destination.
Like the SEND command, the SUBSCRIBE command requires a <em>destination</em> header
indicating which destination to subscribe to. Any messages received on the
subscription will henceforth be delivered as MESSAGE frames from the server
to the client. The <em>ack</em> header is optional, and defaults to <em>auto</em>.</p>
<pre><code>SUBSCRIBE
destination: /queue/foo
ack: client
^@</code></pre>
<p>In this case the <em>ack</em> header is set to <em>client</em> which means that messages
will only be considered delivered after the client specifically acknowledges
them with an ACK frame. The valid values for <em>ack</em> are <em>auto</em> (the default if
the header is not included) and <em>client</em>.</p>
<p>The body of the SUBSCRIBE command is ignored.</p>
<p>Stomp brokers may support the <em>selector</em> header which allows you to specify
an <a href="http://activemq.apache.org/selectors.html">SQL 92 selector</a> on the
message headers which acts as a filter for content based routing.</p>
<p>You can also specify an <em>id</em> header which can then later on be used to
UNSUBSCRIBE from the specific subscription as you may end up with overlapping
subscriptions using selectors with the same destination. If an <em>id</em> header is
supplied then Stomp brokers should append a <em>subscription</em> header to any
MESSAGE commands which are sent to the client so that the client knows which
subscription the message relates to. If using
<a href="http://activemq.apache.org/wildcards.html">Wildcards</a> and
<a href="http://activemq.apache.org/selectors.html">selectors</a> this can help clients
figure out what subscription caused the message to be created.</p>
<h3 id="frame-UNSUBSCRIBE">UNSUBSCRIBE</h3>
<p>The UNSUBSCRIBE command is used to remove an existing subscription - to no
longer receive messages from that destination. It requires either a
<em>destination</em> header or an <em>id</em> header (if the previous SUBSCRIBE operation
passed an id value). Example:</p>
<pre><code>UNSUBSCRIBE
destination: /queue/a
^@</code></pre>
<h3 id="frame-BEGIN">BEGIN</h3>
<p>BEGIN is used to start a transaction. Transactions in this case apply to
sending and acknowledging - any messages sent or acknowledged during a
transaction will be handled atomically based on the transaction.</p>
<pre><code>BEGIN
transaction: <transaction-identifier>
^@</code></pre>
<p>The <em>transaction</em> header is required, and the transaction identifier will be
used for SEND, COMMIT, ABORT, and ACK frames to bind them to the named
transaction.</p>
<h3 id="frame-COMMIT">COMMIT</h3>
<p>COMMIT is used to commit a transaction in progress.</p>
<pre><code>COMMIT
transaction: <transaction-identifier>
^@</code></pre>
<p>The <em>transaction</em> header is required, you must specify which transaction to
commit!</p>
<h3 id="frame-ACK">ACK</h3>
<p>ACK is used to acknowledge consumption of a message from a subscription using
client acknowledgment. When a client has issued a SUBSCRIBE frame with the
<em>ack</em> header set to <em>client</em> any messages received from that destination will
not be considered to have been consumed (by the server) until the message has
been acknowledged via an ACK.</p>
<p>ACK has one required header, <em>message-id</em>, which must contain a value
matching the <em>message-id</em> for the MESSAGE being acknowledged. Additionally, a
<em>transaction</em> header may be specified, indicating that the message
acknowledgment should be part of the named transaction.</p>
<pre><code>ACK
message-id: <message-identifier>
transaction: <transaction-identifier>
^@</code></pre>
<p>The <em>transaction</em> header is optional.</p>
<h3 id="frame-ABORT">ABORT</h3>
<p>ABORT is used to roll back a transaction in progress.</p>
<pre><code>ABORT
transaction: <transaction-identifier>
^@</code></pre>
<p>The <em>transaction</em> header is required, you must specify which transaction to
abort!</p>
<h3 id="frame-DISCONNECT">DISCONNECT</h3>
<p>DISCONNECT does a graceful disconnect from the server. It is quite polite to
use this before closing the socket.</p>
<pre><code>DISCONNECT
^@</code></pre>
<h2 id = "Standard_Headers">Standard Headers</h2>
<p>Some headers may be used, and have special meaning, with most packets</p>
<h3 id="header-receipt">Receipt</h3>
<p>Any client frame other than CONNECT may specify a <em>receipt</em> header with an
arbitrary value. This will cause the server to acknowledge receipt of the
frame with a RECEIPT frame which contains the value of this header as the
value of the <em>receipt-id</em> header in the RECEIPT packet.</p>
<pre><code>SEND
destination:/queue/a
receipt:message-12345
Hello a!^@</code></pre>
<h2 id = "Server_Frames">Server Frames</h2>
<p>The server will, on occasion, send frames to the client (in additional to the
initial CONNECTED frame). These frames may be one of:</p>
<ul>
<li><a href="#frame-MESSAGE">MESSAGE</a></li>
<li><a href="#frame-RECEIPT">RECEIPT</a></li>
<li><a href="#frame-ERROR">ERROR</a></li>
</ul>
<h3 id="frame-MESSAGE">MESSAGE</h3>
<p>MESSAGE frames are used to convey messages from subscriptions to the client.
The MESSAGE frame will include a header, <em>destination</em>, indicating the
destination the message was delivered to. It will also contain a <em>message-id</em>
header with a unique identifier for that message. The frame body contains the
contents of the message:</p>
<pre><code>MESSAGE
destination:/queue/a
message-id: <message-identifier>
hello queue a^@</code></pre>
<p>It is recommended that MESSAGE frames include a <em>content-length</em> header which
is a byte count for the length of the message body. If a <em>content-length</em>
header is included, this number of bytes should be read, regardless of
whether or not there are null characters in the body. The frame still needs
to be terminated with a null byte, and if a <em>content-length</em> is not specified
the first null byte encountered signals the end of the frame.</p>
<h3 id="frame-RECEIPT">RECEIPT</h3>
<p>Receipts are issued from the server when the client has requested a receipt
for a given command. A RECEIPT frame will include the header <em>receipt-id</em>,
where the value is the value of the <em>receipt</em> header in the frame which this
is a receipt for.</p>
<pre><code>RECEIPT
receipt-id:message-12345
^@</code></pre>
<p>The receipt body will be empty.</p>
<h3 id="frame-ERROR">ERROR</h3>
<p>The server may send ERROR frames if something goes wrong. The error frame
should contain a <em>message</em> header with a short description of the error, and
the body may contain more detailed information (or may be empty).</p>
<pre><code>ERROR
message: malformed packet received
The message:
-----
MESSAGE
destined:/queue/a
Hello queue a!
-----
Did not contain a destination header, which is required
for message propagation.
^@</code></pre>
<p>It is recommended that ERROR frames include a <em>content-length</em> header which
is a byte count for the length of the message body. If a <em>content-length</em>
header is included, this number of bytes should be read, regardless of
whether or not there are null characters in the body. The frame still needs
to be terminated with a null byte, and if a <em>content-length</em> is not specified
the first null byte encountered signals the end of the frame.</p>
<h2 id="augmented-bnf">Augmented BNF</h2>
<p>We will use the augmented Backus-Naur Form (BNF) used in the HTTP/1.1
(rfc2616) to define a valid stomp frame:</p>
<pre><code>LF = <US-ASCII LF, linefeed (octect 10)>
CHAR = <any US-ASCII character (octets 0 - 127)>
OCTET = <any 8-bit sequence of data>
DIGIT = <any US-ASCII digit "0".."9">
NULL = <octect 0>
frame-stream = 1*frame
frame = command LF
*( header LF )
LF
[ content ]
NULL
*( LF )
command = client-command | server-command
client-command = "SEND"
| "SUBSCRIBE"
| "UNSUBSCRIBE"
| "BEGIN"
| "COMMIT"
| "ABORT"
| "ACK"
| "DISCONNECT"
server-command = "CONNECTED"
| "MESSAGE"
| "RECEIPT"
| "ERROR"
header = header-name ":" header-value
header-name = 1*<any CHAR except LF or ":">
header-value = 1*<any CHAR except LF>
content = text-content | binary-content
text-content = 1*<any OCTET except NULL>
binary-content = 1*OCTECT</code></pre>
<p>This spec is licensed under the <a href="http://creativecommons.org/licenses/by/2.5/">Creative Commons Attribution
v2.5</a></p>
<div></div>
</div>
</div>
</body>
</html>