Re: [amqp-bindmap] [SCTP Binding]

Adding to your questions and observations:-

I think this is soluble if we assume that stream 0 is special, and only after SASL tunnelling / Open has been received, is the connection open.

I agree, but I would like to check that the common POSIX APIs make it possible to get at message size, etc easily. I assume we're using a stream per session?

3. Closing a Connection

If Stream 0 is 'special', then when close is received on it, close happens

Or we could simply make it such that close received on ANY stream closes the connection. AMQP is robust to this sort of communication failure.

I, for one, would want to continue to use SASL. The problems of total ordering and sessions affect this, too, but I believe this is soluble if we we went with the 'only one stream until open received' paradigm above.

An alternative is to just use one SCTP stream and continue as before, multiplexing sessions. Whilst this seemingly loses some of SCTP's advantages, we do gain a VERY simple transition for existing servers - simply replace the constants specified to bind() on POSIX, for example. We do still retain most of the advantages - multi-homing, better acks for dodgy networks, less chance of DoS, etc.

There is an RFC for TLS over SCTP, and there are implementations / patches, arguably not as well maintained, for OpenSSL and GnuTLS. Whether these work with more than one SCTP stream I can't confirm. It seems the GnuTLS patch does.

We need to look at max session negotiation in open, because any SCTP connection is going to specify this (if opened as one-to-many) at bind, eg in setsockopt() - http://www.linuxforu.com/2011/12/socket-api-part-5-sctp/ may help here.

Raphael Cohn
Chief Architect, stormmq

Secretary, OASIS AMQP Standard
raphael.cohn@stormmq.com

+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 12:22, Mr. Rob Godfrey <robert.godfrey@jpmorgan.com> wrote:

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

amqp-bindmap message