|
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
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
+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.comOn 29 January 2013 13:48, <Andreas.Moravec@deutsche-boerse.com> 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
<robert.godfrey@jpmorgan.com> 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
|