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 <> 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
> > +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 <>
> 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 <> >> 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 >> >> +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, <> 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 >>> >>> <> 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 >> >> >> >
