qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Godfrey (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Resolved: (QPID-336) .NET client support for field table types requires extension (interop issue)
Date Wed, 12 Dec 2007 12:26:43 GMT

     [ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rob Godfrey resolved QPID-336.
------------------------------

       Resolution: Fixed
    Fix Version/s: M2

> .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
>            Assignee: Rob Godfrey
>             Fix For: M2
>
>         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.


Mime
View raw message