On 03/27/2013 11:53 AM, Keith W wrote:
Hi all

Phil and I are tasked with producing a comprehensive set of system
tests for Proton Engine.

The aim is to produce a test suite that will execute against all
Proton implementations thus guaranteeing that all exhibit identical
behaviour and assuring conformance with the AMQP 1-0 specification.

This work has highlighted the need to define how Proton Engine API
behaves under error conditions.

To start a discussion, below we have identified below six different
types of error and posed a number of questions regarding the behaviour
of the Engine API. Thoughts?

Regards, Keith.


We have identified two sources of test-cases:

A) AMQP specification (parts 1 and 2).  For example, the spec states
(2.4.1) "the open frame can only be sent on channel 0" suggesting a
test case should exercise the path where Proton receives an Open on a
channel number other than 0, and similarly (2.4.2) "[The Close] frame
MUST be the last thing ever written onto a connection" suggests a test
case where Proton receives another frame after the receipt of Close.

B) Proton-API itself suggests test-cases. For example, what if a user
tries to bind a connection to more than one transport, opens too many
channels, or calls connection close on a connection that has already
been closed.

Error conditions

Numbers 1-4 relate to the bottom half (i.e. the transport I/O functions):

1) bytes that do not conform to AMQP 1.0 Part 1 [e.g. inconsistent size/doff]

2) bytes that while constituting a valid frame (conforms to Part
2.3.1) are an invalid AMQP frame (violates Part 2.3.2) [e.g.
frame-body containing a primitive string rather than performative]

3) bytes that constitute a valid AMQP frame (conforms to Part 2.3.2) but:
  3A) performative is malformed [e.g. field with unexpected type or
mandatory with value null]
  3B) performative with additional fields [e.g. a Close with additional fields ]
  3C) frame that breaks a AMQP business rule [e.g. Open received on
non-zero channel]

4) state error [e.g. Begin performative received before Open, Attach
on unknown channel number etc]

Numbers 5-6 relate to the top half (i.e. the functions relating to
Connection, Session, etc):

5) illegal parameters to a method call [e.g.
pn_connection_set_container with null container name]
6) illegal state [e.g. pn_connection_open called twice, pn_session
called on unopened connection, pn_session called too many times etc]


When the bottom half encounters input characterised by 1-4, how does
the botton-half of the API behave? What is the effect on the top half?

1. Will the bottom half continue to accept more input?
2. Will the botton-half continue to produce output?
3. How will the application using top half API know an error has
occured? What are the application's responsibilities when it learns of
an error?
4. If a connection is already opened, how (if at all) does the
presense of the error condition affect the connection?

When the top half used in a manner characterised by 5-6, how does the
top half behave?  What, if any, is the affect on the bottom half?

I think bottom-half errors should be handled more severely than top-half errors. In the 1-4 cases (bottom half), the connection should be closed in the same manner as if the socket was suddenly closed. The top half can then respond to the loss of the connection in the normal way, as though the transport connection was lost.

I will go further and say that the bottom half should determine as early as possible that the stream is ill-formed. It would be bad for the bottom half to receive and buffer a gigabyte of data before checking to see if the header is well-formed. We should be thinking about how denial of service attacks might be perpetrated against Proton.

The top-half cases should return error codes or throw exceptions to the application.


Reply via email to