You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org> on 2007/04/06 17:16:33 UTC
[jira] Assigned: (QPID-336) .NET client support for field table
types requires extension (interop issue)
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack reassigned QPID-336:
-------------------------------------
Assignee: Rob Godfrey (was: Marnie McCormack)
Assigning on to Rob (in lieu of Rupert) - believe this may be resolved, confirm with Rupert ?
> .NET client support for field table types requires extension (interop issue)
> ----------------------------------------------------------------------------
>
> Key: QPID-336
> URL: https://issues.apache.org/jira/browse/QPID-336
> Project: Qpid
> Issue Type: Bug
> Components: Dot Net Client
> Affects Versions: M1
> Reporter: Marnie McCormack
> Assigned To: Rob Godfrey
> Attachments: QPID-336-2.diff, QPID-336.diff
>
>
> If you send a message from a Java client and then consume from a .NET client there's an error:
> A first chance exception of type 'Qpid.Framing.AMQFrameDecodingException' occurred in qpid.common.dll
> Additional information: Unsupported field table type: 'x' charcode120
> In the .NET case, this kills the connection to the broker as well, which would seem to be a little extreme.
> .NET client needs to support the same set of field table types as Java client.
> See Field Table extension proposal for AMQP from 108 wiki:
> Field Table Change Proposal
> Field tables are binary structures that contain packed name-value pairs. Each name-value pair is a structure that provides a field name, a field type (referred to as the discriminator), and a field value.
> Currently the following values can be stored in the field table.
> 4.2.5.5 Field Tables
> Field tables are long strings that contain packed name-value pairs.
> Each name-value pair is a structure that provides a field name, a field type, and a field value.
> A field can hold:
> a tiny text string ('S')
> a long string ('S')
> a long signed integer ('I')
> a decimal ('D'), a date and/or time ('T')
> or another field table ('F').
> It is proposed that this section be changed to:
> 4.2.5.5 Field Tables
> Field tables are long binary values that contain packed name-type-value triples.
> Each name-type-value triple is a structure that provides a field name, a field type, and a field value.
> A field can hold:
> A boolean that can take one of the values True or False. The value is
> encoded as a single byte where the value 0 represents false and the
> value 1 represents true. The discriminator is the character 't'.
> A range of different sized signed values. In each case they are
> encoded using two's complement. The list below shows the sizes and the
> discriminators:
> 8: b
> 16: s
> 32: i
> 64: l
> A range of different sized unsigned values. In each case they are
> encoded as an unsigned binary number. The list below shows the sizes and
> the discriminators:
> 8: B
> 16: S
> 32: I
> 64: L
> Floating point types. Floating point types are encoded using the IEEE
> 754 standard. For full details of that encoding please see the "IEEE
> Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard
> 754-1985". The different precisions supported are:
> - single precision, with discriminator f
> - double precision, with discriminator d
> - double-extended, which has an exponent of at least 15 bits in length and
> a signed fraction of at least 64 bits, with discriminator D
> An ASCII character. Encoded as a single character with an ASCII encoding. Discriminator 'k'.
> An ASCII string type, containing ASCII characters. Encoded as a 2 byte
> unsigned integer as the size followed by the characters, using one byte
> per character with an ASCII encoding. Discriminator 'c'.
> A wide string type, containing characters encoded using the broker's
> configured encoding for wide characters. Encoded as a 4 byte unsigned
> integer as the size in bytes followed by the bytes of data. Examples of
> encodings are UTF-8 and UTF-16. Discriminator 'C'.
> A NULL string, No Encoded value. Discriminator 'n'.
> A date time type, containing a 64 bit unsigned integer that represents
> the time to a granularity of seconds encoded in POSIX time_t format. A
> value of 536457599 corresponds to Wednesday December 31 23:35:59 GMT
> 1986. This has a descriminator 't'.
> A binary data type, to allow encoding of arbitrary data. This is
> encoded as a four byte unsigned integer representing the size followed
> by that number of bytes. Discriminator 'x'.
> Another field table 'F'.
> Guidelines for implementers:
> Field names MUST start with a letter, '$' or '#' and may continue with
> letters, '$' or '#', digits, or underlines, to a maximum length of 128
> characters.
> The server SHOULD validate field names and upon receiving an invalid
> field name, it SHOULD signal a connection exception with reply code
> 503 (syntax error). Conformance test: amq_wlp_table_01.
> A peer MUST handle duplicate fields by using only the first instance.
> The above implies that there is a configured wstring encoding at the broker level. I propose that the Connection.Tune method gets an additional field indicating the encoding (e.g. UTF-16 or whatever) that is used by the broker. It is the client's responsibility to do any translation required.
> It is not feasible for the encoding to be negotiated on a per-client basis since that would imply that the broker could do the translation which would mean that the broker needs examines every content header's field table.
> Adapted from original email by Robert Greig (https://amqp.108.redhat.com/servlets/ReadMsg?list=dev&msgNo=169)
> Retrieved from "https://wiki.108.redhat.com/wiki/index.php/FieldTableChangeProposal"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.