amqp-bindmap — archive

[SCTP Binding]

From: Raphael Cohn <[email protected]>
To: [email protected]
Date: Tue, 29 Jan 2013 15:56:00 -0000

The other option is DTLS... which is supported in newer versions of OpenSSL and GnuTLS. I know very little about it. Raphael Cohn Chief Architect, stormmq Secretary, OASIS AMQP Standard [email protected] +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 29 January 2013 15:54, Raphael Cohn < [email protected] > wrote: In the absence of anything else, I'd implement TLS atop SCTP as follows:- Have a 'pair' of unidirectional streams for each required 2-way communication; construct the pair by convention, preferably stream 0 out pairs stream 0 in, etc; substitute alternative ssl_read / ssl_write function implementations if using OpenSSL that cal sctp_sendmsg / sctp_readmsg, and treat sctp as if it where a stream (TLS is record delimited, but that's too complex too map as openssl et al assume a stream) use as a pair So... this requires TLS set up for EVERY stream pair. Slow, inefficient, etc. Raphael Cohn Chief Architect, stormmq Secretary, OASIS AMQP Standard [email protected] +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 29 January 2013 15:38, John O'Hara < [email protected] > wrote: TLS is more interesting - would you maintain a separate TLS session for each SCTP stream??? I know there's been some stuff written about this on the SCTP sites - would be interesting to see where that landed. On 29 January 2013 14:41, Raphael Cohn < [email protected] > wrote: > I'd hope not... by 'special stream' I just mean that one expects to receive > SASL then connection open on SCTP stream 0 - which always exists. After > that, it really doesn't matter, although it would be nice to have connection > close on stream 0. In effect, stream 0 is what you get if you bind a socket > to SCTP w/o doing anything special. One needs some sort of convention 'at > start up' to know how to proceed. > > Raphael Cohn > Chief Architect, stormmq > Secretary, OASIS AMQP Standard > [email protected] > +44 7590 675 756 > > UK Office: > Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United > Kingdom > Telephone: +44 845 3712 567 > > Registered office: > 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom > StormMQ Limited is Registered in England and Wales under Company Number > 07175657 > StormMQ.com > > > On 29 January 2013 14:29, Kritikos, Alex < [email protected] > > wrote: >> >> Hi all, >> >> Just a question to all… if we enforce a dedicated stream with some special >> meaning, would that not affect future bindings to other transports? Or will >> there be a registry / some sort of handshake to define the characteristics >> of a special stream? >> >> Thanks, >> >> Alex Kritikos >> Senior Director >> Software AG >> >> On Jan 29, 2013, at 4:21 PM, Raphael Cohn < [email protected] > >> wrote: >> >> Andreas, >> >> Being stimulated by your questions. >> >> Connection Management >> I would prefer to have a dedicated stream for this. It's decidedly easier. >> It's also worth noting that we can send some out-of-band data with a >> message, such as an opaque 32-bit number. This could be an useful way to do >> the 'We're AMQPxxxx' equivalent in SCTP. Frankly, a client star >> >> Session >> Either. The choices we make in SCTP are whether we want to make it easy to >> take an existing implementation for TCP and make it work on SCTP (easy; just >> use one stream and multiplex, we can have a standard in a week that can be >> implemented in a day), or use multiple streams for multiple sessions (not >> too hard, but more work for everyone, but with other potential advantages). >> We might also want to consider if we ever want 'peel-off', where a stream >> can then become its own dedicated separate socket - useful for getting >> epoll, select, etc, to do per session events for high bandwidth sessions, >> rather than per connection, but rather hard to get one's head round. >> >> Regardless, I'm not in favour of mixing AMQP traffic on these streams with >> other protocols. Given the lack of first class support in most network >> eventing frameworks (epoll, etc) for per stream events, it would require >> some truly horrible server logic. >> >> Raph >> >> Raphael Cohn >> Chief Architect, stormmq >> Secretary, OASIS AMQP Standard >> [email protected] >> +44 7590 675 756 >> >> UK Office: >> Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United >> Kingdom >> Telephone: +44 845 3712 567 >> >> Registered office: >> 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom >> StormMQ Limited is Registered in England and Wales under Company Number >> 07175657 >> StormMQ.com >> >> >> On 29 January 2013 13:48, < [email protected] > wrote: >>> >>> >>> Without knowledge of SCTP usage for legacy amqp versions >>> (pre-OASIS-standard), >>> I have more general questions: >>> >>> - Connection management. >>> Need of dedicated management stream? >>> E.g., the first stream for protocol header, open, close >>> - Session. >>> Each session requires its own SCTP stream? >>> Or alternatively/additionally multiplexing like on a TCP connection? >>> - Ordering of operations. >>> Handling of pipelined open, simultaneous close and session end? >>> Maybe, pipelining has to be restricted or disallowed when using >>> multiple streams. E.g. session can only be begun after connection >>> "open" has been acked by the counterparty's "open" and >>> close may only be sent after ending the sessions has been acked >>> by the counterparty's "end" for all sessions. >>> >>> Andreas >>> >>> < [email protected] > wrote on 29.01.2013 13:22:41: >>> >>> >>> > So I guess my open questions on the SCTP Binding are >>> > >>> > 1) How do we mark initiation of the AMQP communication >>> > >>> > In TCP we use a header AMQPxxxx ... which TCP guarantees will arrive >>> > before any subsequent frames. In SCTP am I correct in believing >>> > this guarantee would only hold true if all communication was on the >>> > same SCTP stream. >>> > >>> > The open frame similarly is defined as having to be sent before any >>> > other AMQP traffic on the connection. >>> > >>> > 2) Framing. I believe that we can do away with the need for AMQP >>> > Framing when using SCTP. The SCTP message carries all information >>> > that is currently held in an AMQP frame with the exception of the >>> > unused extended header. Are others comfortable with this approach. >>> > >>> > 3) Closing a connection. Similar issues to opening in that we don't >>> > have the same total ordering guarantees. In the case of a clean >>> > shutdown this is probably not a significant issue (all AMQP Sessions >>> > will have been "end"ed prior to the close being issued... the peer >>> > can take note of the close, and wait until all open sessions are >>> > ended... or timeout after some waiting period). (There may be a >>> > vanishingly small corner case where a sender asyncronously begins, >>> > operates on, and ends a session... and this entire sequenec is >>> > "overtaken" by the close). >>> > >>> > 4) Security... will we continue to use SASL... if so how does the >>> > layering work. We also need to define the TLS equivalent layer. >>> > >>> > What other areas have I ommitted? >>> > >>> > -- Rob >>> >>> >>> >>> ------------------------------------------------------------------------- >>> Deutsche Börse AG >>> Chairman of the Supervisory Board/ >>> Vorsitzender des Aufsichtsrats: >>> Dr. Joachim Faber >>> Executive Board/Vorstand: >>> Dr. Reto Francioni (Chief Executive Officer/Vorsitzender), >>> Andreas Preuss (Deputy Chief Executive Officer/ >>> stellv. Vorsitzender), Frank Gerstenschläger, >>> Gregor Pottmeyer, Hauke Stars, Jeffrey Tessler. >>> Aktiengesellschaft with registered seat in/mit Sitz in >>> Frankfurt am Main. >>> Commercial register/Handelsregister: >>> Local court/Amtsgericht Frankfurt am Main HRB 32232. >>> >>> ----------------------------------------- >>> Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte >>> Informationen. >>> Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte >>> sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren >>> dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen >>> ist nicht gestattet. >>> >>> The information contained in this message is confidential or protected by >>> law. If you are not the intended recipient, please contact the sender and >>> delete this message. Any unauthorised copying of this message or >>> unauthorised distribution of the information contained herein is >>> prohibited. >>> >>> Legally required information for business correspondence/ >>> Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: >>> http://deutsche-boerse.com/letterhead >> >> >> >