OpenTTCN/Training/TTCN-3 Basics/Exercises/2.2
From OpenTTCN
Exercise 2.2: Defining TTCN-3 message types
Goal: In this exercise we are learning how to define messages as TTCN-3 user-defined types to be used for message-based based communication.
Step 1: Defining messages used for message-based communication
Message-based communication of TTCN-3 can use any TTCN-3 types (pre-defined TTCN-3 types or user-defined TTCN-3 types) for as messages sent and received. Usually structured user defined types are used as messages. To be more specific, messages are normally user-defined "record" types that have mandatory or optional fields. These fields may have their own sub-structured. The "record of" or "set of" types are used to specify repeated elements of messages.
When messages of so called "bit protocols" (such as DNS protocol as an example) are modeled using TTCN-3 types, frequently the leaf types used are limited to "bitstring", "hexstring", "octetstring", and "charstring" to facilitate the use of so called "direct encoding" where the encoding simply concatenates each field after they are translated to a single type (bitstring) and after concatenation the result is translated back to type used for send operation.
Example of simple message type definition using user-defined "record" type:
type record TYPE_X_Message
{
bitstring typeCode,
octestring data
}
Step 2: Defining draft DNS message
Using the information taken from the DNS RFC 1035 we are starting to understand how DNS protocol messages are formatted. Based information about DNS message format and header format:
...
4. MESSAGES
4.1. Format
All communications inside of the domain protocol are carried in a single
format called a message. The top level format of message is divided
into 5 sections (some of which are empty in certain cases) shown below:
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+
The header section is always present. The header includes fields that
specify which of the remaining sections are present, and also specify
whether the message is a query or a response, a standard query or some
other opcode, etc.
...
Above is a quotation from RFC 1035.
...
4.1.1. Header section format
The header contains the following fields:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
...
Above is a quotation from RFC 1035.
We conclude the in this testing we would be more interested in "Header" and "Question" sections, and "Name" field of "Answer" section. This gives us the first draft for DNS message.
type record TYPE_DNS_Message
{
integer id,
bitstring qr,
bitstring opcode,
bitstring aa,
bitstring tc,
bitstring rd,
bitstring ra,
bitstring z,
bitstring rcode,
integer qdcount,
integer ancount,
integer nscount,
integer arcount,
chartring qname,
integer qtype,
integer qclass,
chartring answer
}
Step 3: Copy draft DNS message to your TTCN-3 module
Instructions: Copy and paste the above draft DNS message to your "DNSMainModule" TTCN-3 module. Save your TTCN-3 file after the above modifications and load the changed file using "importer3 load" command to check for possible errors. For now on, at least during this course, please make each modification (basically each Step) separately and load the changed TTCN-3 file to check for possible errors without separate reqeust automatically.
Step 4: Modify original DNS message to add Header and Question sections
Modify the original "TYPE_DNS_Message" so that the DNS Header part is defined as a separate "record" type called "TYPE_DNS_Header". Use "header" as the name of the new field in the DNS message
or
modify the original "TYPE_DNS_Message" so that the DNS Question part is defined as a separate "record" type called "TYPE_DNS_Question". Use "question" as the name of the new field in the DNS message.
Now we have added more structure to the DNS message definition. More structure allows definition of templates (values) in more modular manner than the original defintion.
Step 5: Modify original DNS message to specify limits of fields
The original DNS message uses "integer", "bitstring", and "charstring" types that does not tell anything about the allowed values or lengths of these fields.
Use information given in the extract of RFC 1035 in the beginning of this page and specify a set of sub-types and use them as the types of DNS message fields (in DNS message itself, in header, and in question).
Specify at least the following types:
* UInt16 - as unsigned 16 bit integer * Bit1 - as bitstring of length 1 * Bit3 - as bitstring of length 3 * Bit4 - as bitstring of length 4
Summary
Great! You have just completed your second TTCN-3 exercise. During this exercise you learned how to define TTCN-3 messages to be used for message-based communication. You are now ready to proceed to the next exercise to learn how to send and receive messages.
