Downloaded 220 times
![TLS WS
Connection-Level Security Layers
• Transport-Level Security (TLS/“SSL”)
1. Single-port model for AMQP and secure AMQP
• Sender indicates desire for TLS session with a preamble
(protocol id 2) first, then AMQP version negotiation
occurs. TLS negotiation occurs inline
2. “Pure TLS” model for AMQPS on dedicated port
5671
• Sender opens TLS session to server on port 5671 without
upgrade
3. WebSockets tunnel on port 443
• Sender creates WebSocket with TLS and overlays
AMQP [AMQP 1.0 over WS spec draft]
• SASL Authentication
• Optional. Negotiated with a preamble (protocol id
3) after initial TCP version negotiation and before
AMQP version negotiation
• Supports any SASL authentication model
• SASL External permits binding TLS client
authentication context to the AMQP connection
AMQP TLS
TLS AMQP
AMQP
1
2
3
Connection
TLS Connection
TLS
SASL](https://image.slidesharecdn.com/2015-09-28amqp1-151005115500-lva1-app6892/75/AMQP-1-0-introduction-8-2048.jpg)
![Session
• Binds two unidirectional
channels to form a
bidirectional, sequential
conversation
• Provides a window-based flow
control model
• Number of total transfer frames
that sender and receiver can
hold in buffers at any given time
• Decouples credit-based flow
control driven by API and
capacity management
requirements of the underlying
platform
• A connection can support
Session
Endpoint
Session
Endpoint
Session
CH3
CH7
[CH3] BEGIN(
remote-channel=null, …)
[CH7] BEGIN(
remote-channel=3, …)
END()
END()](https://image.slidesharecdn.com/2015-09-28amqp1-151005115500-lva1-app6892/75/AMQP-1-0-introduction-9-2048.jpg)
![Modeling Bi-Di and
Request/Response
• For a request/response
relationship, the client C initiates
two links with the target node T
• [CT] role=sender
• [TC] role=receiver
• The client’s response node can
be scoped to the conversation
or global. Referenced in
request.reply-to
• Correlation via reply.correlation-
id set to request.correlation-id (or
request.message-id if absent)
ATTACH(role=sender,
source=C, target=T, …)
ATTACH(role=receiver, src=C, trg=T)
Session
Endpoint
Session
Endpoint
Session
request_link
reply_linkLEP
LEP LEP
LEP
TC
ATTACH(role=receiver,
source=T, target=C, …)
ATTACH(role=sender, src=T, trg=C)](https://image.slidesharecdn.com/2015-09-28amqp1-151005115500-lva1-app6892/75/AMQP-1-0-introduction-15-2048.jpg)
![0xC0 0x03
list element
count
0x50 0x02
[0] ubyte 2
0x61 0x07DF
[1] short 2015
0xA1 0x03
[2] string “Hi!”
“Hi!”
List – Polymorphic Sequence of Elements
0xD0 0x04
map
element
count
(K/V pairs) * 2
0xA1 0x04
[K0] string “Key1”
“Key1”
Map – Polymorphic Sequence of Key/Value Pairs
0xA1 0x04
[V0] string “Val1”
“Val1” Key2 Val2
[K1] [V1]
0xE0 0x05
array element
count
0x07DF
[0]
Array – Monomorphic Sequence of Elements
0x61
element ctor
0x07DF 0x07DF 0x07DF 0x07DF
[1] [2] [3] [4]short](https://image.slidesharecdn.com/2015-09-28amqp1-151005115500-lva1-app6892/75/AMQP-1-0-introduction-29-2048.jpg)
![{
“books” : [
{
“title” : “Normal Accidents”,
“authors” : [“Charles Perrow”],
“isbn” : “978-0-691-00412-9”
},
{
“title” : “Rockets and People, V3”,
“authors” : [“Boris Chertok”,
“Asif Siddiqi”],
“isbn” : “978-0-160-81733-5”
}
]
}
JSON to AMQP - Schemaless
map 2
str8-utf 5 “books” list 2
map 6
str8-utf 5 “title” strf8-utf 16 “Normal Accidents”,
str8-utf 7 “authors” array 1 str8-utf
14 “Charles Perrow”
str8-utf 4 “isbn” strf8-utf 16 “978-0-691-00412-9”
map 6
str8-utf 5 “title” strf8-utf “Rockets and People, V3”
str8-utf 7 “authors” array 2 str8-utf
13 “Boris Chertok”,
12 “Asif Siddiqi”
str8-utf 4 “isbn” str8-utf 16 “978-0-160-81733-5”
Identical in shape, easy from/to mapping
nearly identical in concrete footprint, but AMQP with deeper type system
0xD0 0xC0 0xA1 0xE0](https://image.slidesharecdn.com/2015-09-28amqp1-151005115500-lva1-app6892/75/AMQP-1-0-introduction-34-2048.jpg)
![{
“books” : [
{
“title” : “Normal Accidents”,
“authors” : [“Charles Perrow”],
“isbn” : “978-0-691-00412-9”
},
{
“title” : “Rockets and People, V3”,
“authors” : [“Boris Chertok”,
“Asif Siddiqi”],
“isbn” : “978-0-160-81733-5”
}
]
}
JSON to AMQP – Using Schema
map 2
str8-utf 5 “books” list 2
desc ulong 0x0000000300000002 list
strf8-utf 16 “Normal Accidents”,
array 1 str8-utf 14 “Charles Perrow”
strf8-utf 16 “978-0-691-00412-9”
desc ulong 0x0000000300000002 list
strf8-utf “Rockets and People, V3”
array 2 str8-utf
13 “Boris Chertok”,
12 “Asif Siddiqi”
str8-utf 16 “978-0-160-81733-5”
AMQP more compact as descriptive metadata is externalized into
schema
<type class="composite" name="book" label="example composite type">
<descriptor name="example:book:list" code="0x00000003:0x00000002"/>
<field name="title" type="string" mandatory="true" />
<field name="authors" type="string" multiple="true"/>
<field name="isbn" type="string"/>
</type>](https://image.slidesharecdn.com/2015-09-28amqp1-151005115500-lva1-app6892/75/AMQP-1-0-introduction-35-2048.jpg)
More Related Content
Similar to AMQP 1.0 introduction
AMQP 1.0 introduction
- 1. Introduction to AMQP 1.0 AMQPFoundations Clemens Vasters Architect, Messaging, Microsoft Corporation clemensv@microsoft.com © 2015 Microsoft Corporation All content in the presentation is available for reuse under CC-BY 4.0 https://creativecommons.org/licenses/by/4.0/
- 2. What is AMQP1.0? • Secure, compact, symmetric, multiplexed, reliable, binary transfer protocol to move messages between applications • International ISO/IEC 19464:2014 standard • Layered model • Transport and connection security protocol • Frame transfer protocol • Message transfer protocol • Not tied to any particular message source or target model or topology. Supports classic message brokers, modern hyper-scale messaging infrastructure, and peer-to-peer exchange
- 3. Container Incoming Connection Endpoint Container Frame Transfer ProtocolOverview • Containers (Apps) connect to other containers • Connections manage transfer capacity (frame size, channel count) • Bidirectional sessions formed over pairs of unidirectional channels • Sessions allow for multiplexed conversations between Connection CH0 CH0 CH1 CH1 Outgoing Connectio n Endpoint Session Endpoint Session Endpoin t Session CH2 CH2
- 4. Container Hierarchic al Node Topology • Container • Communicatingapp • Node • Addressable entity within the app • Nodes can be organized in any way the application sees fit; flat, hierarchy, or graph • Node can be a queue or topic or relay or event store or … • Link • Links connect via paths to nodes Nodes a b c d b1 b2 b3 b4 / Flat Node Topology a b c d Session Endpoi nt Link Endpoint a Link Endpoint c Session Endpoi nt Link Endpoint /a Link Endpoint /b/b4 Containers and Nodes
- 5. ContainerContainer Message Transfer ProtocolOverview • Unidirectional, named links are formed over sessions • Links manage flow individually through link credits • Links can outlive collapsed connection/sessions and can be recovered Session Endpoint Session Endpoint Session Link Endpoint Link Endpoint downstream_link_name Link Endpoint Link Endpointupstream_link_name M Node Node
- 6. AMQP 1.0 CoreProtocol Elements Connections, Security, Sessions, and Links
- 7. Connection • Layered overnetwork stream- transport (usually TCP; SCTP, Pipes are suitable) • Connection provides a reliably ordered sequence of frames w/ negotiated maximum frame size • Frames flow over a negotiated number of multiplexed, unidirectional channels • Explicit idle-timeout management • Connection preamble indicates protocol version. Integration with transport-level security; TLS and SASL security can be negotiated inline. Incoming Connection EndpointConnection CH0 CH0 CH1 CH1 CH2 CH2 Outgoing Connectio n Endpoint OPEN(container-id=0, hostname=ep.example.com, …) OPEN(container-id=0, max-frame-size=262144, …) CLOSE() CLOSE()
- 8. TLS WS Connection-Level SecurityLayers • Transport-Level Security (TLS/“SSL”) 1. Single-port model for AMQP and secure AMQP • Sender indicates desire for TLS session with a preamble (protocol id 2) first, then AMQP version negotiation occurs. TLS negotiation occurs inline 2. “Pure TLS” model for AMQPS on dedicated port 5671 • Sender opens TLS session to server on port 5671 without upgrade 3. WebSockets tunnel on port 443 • Sender creates WebSocket with TLS and overlays AMQP [AMQP 1.0 over WS spec draft] • SASL Authentication • Optional. Negotiated with a preamble (protocol id 3) after initial TCP version negotiation and before AMQP version negotiation • Supports any SASL authentication model • SASL External permits binding TLS client authentication context to the AMQP connection AMQP TLS TLS AMQP AMQP 1 2 3 Connection TLS Connection TLS SASL
- 9. Session • Binds twounidirectional channels to form a bidirectional, sequential conversation • Provides a window-based flow control model • Number of total transfer frames that sender and receiver can hold in buffers at any given time • Decouples credit-based flow control driven by API and capacity management requirements of the underlying platform • A connection can support Session Endpoint Session Endpoint Session CH3 CH7 [CH3] BEGIN( remote-channel=null, …) [CH7] BEGIN( remote-channel=3, …) END() END()
- 10. Link • Named, unidirectionaltransfer route for messages from “source” to “target” node • A session can accommodate any number of concurrent links • Links in either direction can be initiated by either peer. • Links can be recovered on a different connection/session when the previous broke • Credit-based flow control to model flow management for various API shapes ATTACH(name=N, handle=1, role=sender, source=A, target=B, …) ATTACH(name=N, handle=2, role=receiver, source=A, target=B, …) Link Endpoint Link Endpoint Session Endpoint Session Endpoint Session link_name DETACH() DETACH()
- 11.
- 12. Message Transfers –Settlement • Messages are transferred fire-and- forget (“settled”) or requiring explicit settlement, allowing for various delivery state handling and delivery assurance models • At-Most-Once / Fire-And-Forget • TRANSFER(settled=true) • At-Least-Once • TRANSFER(delivery_tag=DT, settled=false, state=S_0) • DISPOSITION(delivery_tag=DT, settled=true, state=T_0) Sende r Receive r Session Endpoint Session Endpoint Session link_name Cr TRANSFER(…, settled=false, …) DISPOSITION(…, settled=true, …)
- 13. Message Transfers –Delivery State • Intermediary States (transfer ongoing) • received – used for link recovery negotiation, indicating that an unsettled message had been received • Terminal States (transfer is done) • accepted – the message has been accepted by the receiver (OK) • rejected – the message has been rejected by the receiver (with error/diagnostics details) • released – the message has been abandoned by the receiver and should be redelivered • modified – the message has been released (see above) and should be modified at the source as indicated in the Sende r Receive r Session Endpoint Session Endpoint Session link_name Cr TRANSFER(settled=false, state=null, …) DISPOSITION(settled=true, state=accepted, …)
- 14. Message Transfer –Recovering Links • Links can be recovered from previous, broken or abandoned connections/sessions • Message delivery states are exchanged as the link is re-attached by the peers • Transfers are subsequently recovered to resend, reconcile state, or continue settlement • TRANSFER(…,resume=true, …) Sende r Receive r Session Endpoint Session Endpoint Session link_name Cr ATTACH(role=sender, src=A, trg=B, unsettled = { 1-> null, 2-> null, 3-> accepted, 4-> null }, …) ATTACH(role=sender, src=A, trg=B, unsettled = { 1-> released, 2-> null, 3-> accepted }, …)
- 15. Modeling Bi-Di and Request/Response •For a request/response relationship, the client C initiates two links with the target node T • [CT] role=sender • [TC] role=receiver • The client’s response node can be scoped to the conversation or global. Referenced in request.reply-to • Correlation via reply.correlation- id set to request.correlation-id (or request.message-id if absent) ATTACH(role=sender, source=C, target=T, …) ATTACH(role=receiver, src=C, trg=T) Session Endpoint Session Endpoint Session request_link reply_linkLEP LEP LEP LEP TC ATTACH(role=receiver, source=T, target=C, …) ATTACH(role=sender, src=T, trg=C)
- 16. Transfers – FlowControl
- 17. AMQP Body FrameTypes Type Connecti n Session Link Description OPEN Handle Connection open BEGIN Inspect Handle Session begin ATTACH Inspect Handle Link attach FLOW Inspect Handle Update flow control state TRANSFER Inspect Handle Transfer message DISPOSITION Inspect Handle Update transfer state DETACH Inspect Handle Link detach END Inspect Handle Session end CLOSE Handle Connection close ✔ ✔ ✔ ✔ ✔ ✔ Already discussed
- 18. • Each sessionendpoint has an incoming and outgoing transfer window defining an upper bound for messages in transit • Window size is expressed in frame count; maximum frame size and window size gate the memory capacity required for a session • Transfers decrement the remaining window sizes. An outgoing window size of <=0 suspends transfers. Window sizes are updated/reset with FLOW • Each link has an associated link-credit, which is the number of messages the receiver is currently willing to accept • Messages can flow when the remaining link-credit is greater than zero. Only the receiver can manipulate the link credit value. • Transfers decrement the remaining link credit. A link credit of <=0 suspends transfers. Link credit is updated with FLOW Session Flow Control Platform Resource Management Link Flow Control Application-Level Message Flow Management Session Endpoint Session Endpoint Session CH3 CH7 Ou t In In Ou t Link Endpoi nt Link Endpoi nt Session Endpoint Session Endpoint Session link_name Cr
- 19. Wait! Why twoflow control models? • Session flow control protects the platform • Guards high-scale and hyper-scale platform implementations from overcommitting transfer resources to sessions; shields from unexpected transfer bursts • Allows for session-level capacity management and throughput throttling • Link flow control protects the application and supports API gestures • Guards an application node from having to accept more messages than it can currently handle. • Prevents concurrent, multiplexed session/link traffic from being backed up behind messages that cannot currently be handled • Enables on-demand receive, pre-fetch receive, and just-in-time
- 20. Some API Patterns Imperative:receiver.Receive() Sende r Receive r Session Endpoint Session Endpoint Session link_name Cr TRANSFER() FLOW(link-credit=1) Reactive: observer.Subscribe(callback) Sende r Observer Session Endpoint Session Endpoint Session link_name Cr TRANSFER() FLOW(link-credit={concur-ops-limit}) Throttled: queueClient.Send() Sende r Queue Session Endpoint Session Endpoint Session link_name Cr FLOW(link-credit={throttle-delta}) Prefetch: receiver.SetPrefetch(10) Sende r Receive r Session Endpoint Session Endpoint Session link_name Cr TRANSFER() FLOW(link-credit=10) TRANSFER() Credit limited by concurrent operations that the reactive system can perform Credit limited by how many messages the application wants to keep available for immediate processing Credit limited by how many messages the receiving queue can store vs. sender’s throughput capacity
- 21. Application Timeout/Cancellation/Pause “drain” allows anyimmediately pending transfers to complete and then promptly reduces the link credit to zero. Sende r Receive r Session Endpoint Session Endpoint Session link_name Cr FLOW(link-credit=1) …. time passes … FLOW(drain=true) Setting the link-credit to zero immediately stops the link. Pending messages are no longer transferred. Resume with increasing credit. Sende r Receive r Session Endpoint Session Endpoint Session link_name Cr FLOW(link-credit=1) …. time passes … FLOW(link-credit=0)
- 22. AMQP on theWire Primitive Types
- 23. The AMQP TypeSystem • AMQP has its own, portable, language-independent type system • Used for all core AMQP protocol elements • Optimized for fast and flexible processing and compact representation • Defines a broad range of primitive and composite types • Permits descriptive references to external type systems • Can be used to express and encode message payloads • Supports schema-bound and schema-free encoding • Schema-bound (like Avro/ProtoBuf/Thrift) • All fixed protocol elements • Only transmit data and rely on out-of-band-shared metadata for interpretation.
- 24. Schema Example –Composite Type • AMQP Schema notation is XML • DTD included in the core spec • Type classes • primitive – built-in types • Includes array, list, and map • composite – multi-value type • Inherits from “list” primitive • restricted – restriction of existing type • Restricts source type value space • Archetypes • provides – categorization of types • Descriptor • Unique string and numerical descriptors • Composite: Fields • Zero or more fields <type name="properties" class="composite" source="list" provides="section"> <descriptor name="amqp:properties:list" code="0x00000000:0x00000073"/> <field name="message-id" type="*" requires="message-id"/> <field name="user-id" type="binary"/> <field name="to" type="*" requires="address"/> <field name="subject" type="string"/> <field name="reply-to" type="*" requires="address"/> <field name="correlation-id" type="*" requires="message-id"/> <field name="content-type" type="symbol"/> <field name="content-encoding" type="symbol"/> <field name="absolute-expiry-time" type="timestamp"/> <field name="creation-time" type="timestamp"/> <field name="group-id" type="string"/> <field name="group-sequence" type="sequence-no"/> <field name="reply-to-group-id" type="string"/> </type> properties – composite type schema
- 25. Schema Example –Restricted Type • Restricted types inherit source type • here: ubyte, unsigned byte • Type may constrain the value space • Explicit permitted values • Named choices act as alias • May directly alias source • May override source descriptor <type name="sender-settle-mode" class="restricted" source="ubyte"> <choice name="unsettled" value="0"/> <choice name="settled" value="1"/> <choice name="mixed" value="2"/> </type> sender-settle-mode – restricted type schema <type name="seconds" class="restricted" source="uint"/> seconds – restricted type schema <type name="delivery-annotations" class="restricted“ source="annotations" provides="section"> <descriptor name="amqp:delivery-annotations:map“ code="0x00000000:0x00000071"/> </type> delivery-annotations – restricted type schema
- 26. Data on thewire • All data elements are prefixed with a “constructor” indicating type • Built-in, primitive types use a single octet (0xA1 designates str8- utf) 0xA1 “Constructor” 0x1E Type-specific preamble “Hello Glorious Messaging World” Type-specific data str8-utf str8-utf length str8-utf data 0x00 Constructor descriptor follows 0xA3 sym8 0x11 sym8 length “example:book:list” 0x0C sym8 value – type name primitive Descriptor … contents …
- 27. Fixed Size Primitives •Fixed size primitives are organized by encoding size • null, Boolean true and false, and zero-valued uint and ulong can be expressed with a constructor (no data byte) • uint and ulong valued < 256 encodes into 1 data byte • int and long valued from -128 to 127 encodes into 1 data byte 0 1 2 4 8 16 null 0x40 boolean 0x41: true 0x42: false 0x56 ubyte 0x50 ushort 0x60 uint 0x43: v=0 0x52: v<256 0x70 ulong 0x44: v=0 0x53: v<256 0x80 byte 0x51 short 0x61 int 0x54: -128<v<127 long 0x55: -128<v<127 0x81 float 0x72 double 0x82 decimal32 0x74 decimal64 0x84 decimal12 0x94 char 0x73 timestamp 0x83 uuid 0x98 data bytes occupied by type
- 28. Variable Size Primitives •Variable size primitive encodings have a 1 or 4 byte preamble. Which encoding is used depends on the actual data size. • UTF-8 strings, symbols, and binary data of up to 255 bytes has a single byte preamble, otherwise a 4 byte preamble is used 0xA1 0x1E 1 byte ... up to 255 byte str8-utf str8-utf length str8-utf data 0xB1 0x00000100 4 byte ... up to 232-1 byte str32-utf str32-utf length str32-utf data 1 4 binary – vbin8 0xA0 binary – vbin32 0xB0 string – str8-utf 0xA1 string – str32-utf 0xB1 symbol – sym8 0xA3 symbol – sym32 0xB3 preamble size
- 29. 0xC0 0x03 list element count 0x500x02 [0] ubyte 2 0x61 0x07DF [1] short 2015 0xA1 0x03 [2] string “Hi!” “Hi!” List – Polymorphic Sequence of Elements 0xD0 0x04 map element count (K/V pairs) * 2 0xA1 0x04 [K0] string “Key1” “Key1” Map – Polymorphic Sequence of Key/Value Pairs 0xA1 0x04 [V0] string “Val1” “Val1” Key2 Val2 [K1] [V1] 0xE0 0x05 array element count 0x07DF [0] Array – Monomorphic Sequence of Elements 0x61 element ctor 0x07DF 0x07DF 0x07DF 0x07DF [1] [2] [3] [4]short
- 30. AMQP on theWire Composite Types and Messages
- 31. AMQP Messages • Thestandard AMQP message format shown here is replaceable/extensible. • Message format kind and version is selected on TRANSFER frame. Default format is zero. • Bare Message core is immutable from sender to ultimate receiver through all intermediaries • Annotated Message frame may be altered by intermediaries • All sections defined as composite types (archetype “section”) header transfer headers delivery-annotations custom delivery metadata message- annotations infrastructure-specific properties properties standard message properties application- properties application-defined metadata Message Body (explained later) footer custom metadata about the annotated msg (e.g. signature) Annotated Message Bare Message 0..1 0..1 0..1 0..1 0..1 0..1 1
- 32. Composite Type Encoding • Prefixedwith type descriptor • Encoded as list • List contains elements in schema order • Trailing elements can be omitted <type name="properties" class="composite" source="list" provides="section"> <descriptor name="amqp:properties:list" code="0x00000000:0x00000073"/> <field name="message-id" type="*" requires="message-id"/> <field name="user-id" type="binary"/> <field name="to" type="*" requires="address"/> <field name="subject" type="string"/> <field name="reply-to" type="*" requires="address"/> <field name="correlation-id" type="*" requires="message-id"/> <field name="content-type" type="symbol"/> <field name="content-encoding" type="symbol"/> <field name="absolute-expiry-time" type="timestamp"/> <field name="creation-time" type="timestamp"/> <field name="group-id" type="string"/> <field name="group-sequence" type="sequence-no"/> <field name="reply-to-group-id" type="string"/> </type> properties – composite type schema 0xC0 0x04 list element count 0xA1 0x04 “A4D5” 0xA1 0x08 “clemensv” 0xA1 0x02 “q1” 0xA1 0x05 “hello” 0x00 descriptor 0x53 ulong8 0x73 code
- 33. The AMQP messagebody consists of one of the following three choices: • One or more data sections • Binary data up to remaining maximum frame size • Hints to interpret this data can be carried in the standard content-type and content-encoding properties. • JSON, MsgPack, Avro, Thrift, XML, etc. payloads • One or more amqp-sequence sections • A sequence is a list of AMQP encoded values • A single amqp-value section • A single AMQP value (including null) • Can be a composite type value data raw binary data amqp-sequence sequence of data elements 1..* or amqp-value single data value or 1..* 1 Application Data – AMQP Message Body
- 34. { “books” : [ { “title”: “Normal Accidents”, “authors” : [“Charles Perrow”], “isbn” : “978-0-691-00412-9” }, { “title” : “Rockets and People, V3”, “authors” : [“Boris Chertok”, “Asif Siddiqi”], “isbn” : “978-0-160-81733-5” } ] } JSON to AMQP - Schemaless map 2 str8-utf 5 “books” list 2 map 6 str8-utf 5 “title” strf8-utf 16 “Normal Accidents”, str8-utf 7 “authors” array 1 str8-utf 14 “Charles Perrow” str8-utf 4 “isbn” strf8-utf 16 “978-0-691-00412-9” map 6 str8-utf 5 “title” strf8-utf “Rockets and People, V3” str8-utf 7 “authors” array 2 str8-utf 13 “Boris Chertok”, 12 “Asif Siddiqi” str8-utf 4 “isbn” str8-utf 16 “978-0-160-81733-5” Identical in shape, easy from/to mapping nearly identical in concrete footprint, but AMQP with deeper type system 0xD0 0xC0 0xA1 0xE0
- 35. { “books” : [ { “title”: “Normal Accidents”, “authors” : [“Charles Perrow”], “isbn” : “978-0-691-00412-9” }, { “title” : “Rockets and People, V3”, “authors” : [“Boris Chertok”, “Asif Siddiqi”], “isbn” : “978-0-160-81733-5” } ] } JSON to AMQP – Using Schema map 2 str8-utf 5 “books” list 2 desc ulong 0x0000000300000002 list strf8-utf 16 “Normal Accidents”, array 1 str8-utf 14 “Charles Perrow” strf8-utf 16 “978-0-691-00412-9” desc ulong 0x0000000300000002 list strf8-utf “Rockets and People, V3” array 2 str8-utf 13 “Boris Chertok”, 12 “Asif Siddiqi” str8-utf 16 “978-0-160-81733-5” AMQP more compact as descriptive metadata is externalized into schema <type class="composite" name="book" label="example composite type"> <descriptor name="example:book:list" code="0x00000003:0x00000002"/> <field name="title" type="string" mandatory="true" /> <field name="authors" type="string" multiple="true"/> <field name="isbn" type="string"/> </type>
- 36. AMQP Frames • Frameheader (8 byte) • Overall frame size (ulong) • Data offset (count of 4-byte words, byte) • Frame type indicator (byte) • Channel identifier (ushort) • Performative • Composite type describing the AMQP operation • Open, Begin, Attach, Flow, Transfer, Disposition, Detach, End, Close • Payload • Performative-dependent payload, immediately following the performative. • Currently only defined to be used for frame header size, 4 bytes offset, 1 byte type, 1 byte (AMQP 0x00 / SASL 0x01) channel-id (2 byte) performative (@ size-offset*4) Open, Begin, Attach, Flow, Transfer, Disposition, Detach, End, Close payload AMQP Message (w/ Transfer)
- 37. Wire Footprint? • MinimalAMQP transfer footprint for a message containing the string “Hello!” • Just 35 bytes transfer overhead. • plus IP, TCP, TLS (~100 byte) Frame Header ..... 8 bytes Transfer Performative 5b link-handle (1b) 1+4b delivery-id (1b) 1+4b delivery-tag (2+1b) 2+4b message-format 1b (theoretical min 11 bytes) .... 22 bytes AMQP Message amqp-value 3b “Hello!” 2+6b .... 11 bytes ============= 41 bytes
- 38. ... there’s more Transactions Addressing Management ClaimsBased Security ... next time ...