[
https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Restrepo updated QPID-336:
--------------------------------
Attachment: QPID-336.diff
Attached is a proposed patch to improve this issue. It ports the basic AMQType
enumeration from the Java code and related classes (AMQTypedValue, AMQTypeMap)
and backported the existing FieldTable class from the Java client to the .NET
client to use the new classes and remove all serialization code from the class.
It also completes some of the putXXX() and getXXX() methods in the Buffer
classes and removes some duplicated and cleans up code the EncodingUtils class.
It currently implements most types outlined in the proposed field table types
except:
- Types unimplemented in the Java client are left like that in the .NET code
- Some types are disabled to avoid conflicting type codes
- The code still uses the older types where necessary to keep compatibility to
the Java broker, as it hasn't fully adopted the proposed type system yet
(particularly the use of the LONG_STRING type.
> .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
> Attachments: 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.
