Hi antti,
ok - let me just clarify. My example did not involve sending aux field values across TRI or TCI. I only used it
locally in the decoder, i.e., _within_ the CD entity. I mean that I allocated the field in the beginning of my tciDecode operation .. and then dealloacted it before returning from it.
But now I see finally your point in how this aux field can be misleading.
Moikka,
stephan
>
Original Message
> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of ext Antti Hyrkkanen
> Sent: 22 August, 2005 12:07
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: FW: aux-field in the C-lang mapping of the standard
>
>
> Hi Stephan
>
> > Hi all,
>
> > regarding the use of the aux field.
> > If develoeprs use the aux field they have to deal with the
> > consequences of standard updates. It is as simple as that.
>
> I think it could be more clearly stated that the field is not
> reserved
> developers, so they know not to build their fortune on having a fancy
> solution relying on it :). I had to compare the C part of the
> standard with the Java part and do some reasoning before deciding
> not to use the aux field for own purposes.
>
> The following fancy solution depends a lot on the used
> tool:
>
> When the SA receives a message from the SUT, one can load information
> about the protocol with which the message was received. If it was
> receive from TCP port 80, I could say via the aux field that the
> message is most likely a PDU of HTTP, if I get it from port 21, it is
> PDU of FTP.
>
> If my SA sets aux to point to that protocol information, this
> protocol
> information possibly is present to my decoder also, and the decoder
> can use it with the addition of the decoding hypothesis to determine
> what the received data represents. This requires that the used tool
> does not change the aux field value, and that the aux field value in
> TriMessage in TriEnqueue*() operation ends up to the aux field of the
> TriMessage of TciDecode() operation. This also requres that the CD
> and SA are in the same address space since aux is a pointer.
>
> A safer approach would be to prefix the received message with the
> protocol information, if the decoders want to use it. Maybe it
> was useful, if there was an extra field that could be used
> to pass protocol information separately from the received data,
> and this field was of lets say type Binarystring, so its value
> could be copied, when the TriMessage is copied.
>
> Antti
>
> >
Original Message
> > From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> > [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of ext Stephan Schulz
> > Sent: 22. elokuuta 2005 10:56
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: FW: aux-field in the C-lang mapping of the standard
> >
> >
> > Hi all,
> >
> > regarding the use of the aux field.
> > If develoeprs use the aux field they have to deal with the
> > consequences of standard updates.
> > It is as simple as that.
> >
> > When I have been implementing codecs I found it very useful to have
> > an extra information element in the TriMessage type which
> stores the
> > current bit position that a message has successfully decoded up to.
> > So in my TRI data type handling I have handled allocation and
> > deallocation of that aux field and have found it very useful to
> > simplify information management in my decoder implementations.
> >
> > Technically my next step could be to file a CR asking for a new
> > field. But for the time being I am happy with the solution
> as is. Of
> > course I will have to change my TRI implementation should the type
> > definition be ever extended or changed. But I believe that this
> > overhead is easily managable.
> >
> > Sad to hear that the Java mappings do not allow access of such
> > fields. I have been however implementing in C.
> > Again I found it useful in this B) type case as well.
> >
> > Moikka,
> > stephan
>