Home » Eclipse Projects » Eclipse Titan » ASN.1 messsage send/recv through UDP test port(ASN.1 recv problem)
|
| Re: ASN.1 messsage send/recv through UDP test port [message #1751483 is a reply to message #1751353] |
Tue, 10 January 2017 17:06   |
 Gyorgy Rethy
Messages: 31
Registered: April 2015 |
Member |
|
|
Hi Dae-young,
It doesn't seem to do with matching. Your modifications in the test port fails, the event handler doesn't seem to put the received message to the receiving port's queue. In the log file @19:05:19.182518 I can see the last log from the Event Handler is "The remote address: ...", but I cannot see "leaving UDPasp__PT::Event_Handler()" (line 231 in UDPasp_PT.cc).
The problem seems to be that you are sending a message without encoding it. In the original UDPasp_Types.ttcn you can see that the data field of ASP_UDP_message is octetstring. I.e. the test port originally expects an encoded message in the data field of the outgoing_send(const UDPasp__Types::ASP__UDP__message& send_par) test port function's parameter. This is not a must, you can encode the data field of your ASP_UDP_ASN1message type in the test port as well, e.g. by calling Titan's built-in BER codec. And in the Event Handler you need to decode the data field into the Types::Message type before putting it into the port queue. You can find more information about using built-in codecs in Titan's API guide (apiguide.pdf).
As a hint, you should also check using dual-faced ports for message encoding and decoding with automatic generation of encoder/decoder functions (see clause 4.22 of the Titan Ref. guide referenceguide.pdf); this feature has been developed exactly for this purpose: you can pass your ASP_UDP_ASN1message to a dual-faced port, it will call the identified function implicitly (which should encode the data field and leave the other fields untouched) and pass on the value returned by the function to the test port; in the receiving direction the opposite process shall be done, i.e. a function decoding the data field need to be identified. This way the original UDP test port, carrying an octetstring payload can be used without changing it. You can find useful examples in clauses 4.22.4.2 and in clause 4.22.9 (following the BNF syntax).
|
|
|
| Re: ASN.1 messsage send/recv through UDP test port [message #1751502 is a reply to message #1751483] |
Tue, 10 January 2017 20:19 |
|
Hi Dae-young,
as Gyorgy said, the problem is that your messages , as usual, should be encoded in binary form before they are fed to the port.
type octetstring PDU_UDP;
type record ASP_UDP_message{
PDU_UDP data,
AddressType remote_addr optional,
PortType remote_port optional,
integer id optional
}
the payload is of type PDU_UDP which is an octetstring, a representation for binary data.
You have tried to hack the above by adding your ASN.1 message:
type record ASP_UDP_ASN1message{
Message data,
AddressType remote_addr optional,
PortType remote_port optional,
integer id optional
}
but this is not permitted; the test port itself is still expecting an octetstring, hence the problems you have seen.
Before sending it to the UDP port , you need to encode it into binary, e.g. with a BER encoder autogenerated by Titan.
Attached you can see a working example, together with the generated logs.
The messages are enc/decoded with the below functions:
external function encMessage(in Message pdu) return octetstring
with { extension "prototype(convert) encode(BER:BER_ENCODE_DER)" };
external function decMessage(in octetstring stream) return Message
with { extension "prototype(convert) decode(BER:BER_ACCEPT_ALL)" };
Best regards
Elemer
[Updated on: Tue, 10 January 2017 20:23] Report message to a moderator |
|
| | | | | |
| Re: ASN.1 messsage send/recv through UDP test port [message #1751554 is a reply to message #1751547] |
Wed, 11 January 2017 12:15 |
|
Hi Dae-young,
You did not attach the log file;
I'm guessing you did not change in the config file
from
*.pt.mode := "advanced"
*.pt.debugging := "no"
to
*.pt2.mode := "advanced"
*.pt2.debugging := "no"
which means pt2 was started with default , which is "basic" mode;
I have attached the working example; only client side uses the dual-faced port;
Best regards
Elemer
|
|
| | |
| Re: ASN.1 messsage send/recv through UDP test port [message #1751646 is a reply to message #1751629] |
Thu, 12 January 2017 08:34 |
|
Hi Dae-young,
sorry , I have created the confusion myself; what I intended to write was:
type component UDPDeviceTesterInterface
{
port UDPasp_PT ServUDPPort;
port Dual_faced_internal_pt DevUDPPort;
}
to express that client side uses dual-faced, while server side the simple UDP port.
Truth is, the system declaration does not affect the functionality (at least in Titan implementation ) and as such, is optional. It works equally well without it, or if it's messed up, like I did.
The reason I personally prefer to have it is that it offers a quick overview
of the SUT ports used (well, if it's done correctly). It may not matter much
for two ports, but when you have a complex set-up, with many components and ports/port arrays, it can get confusing.
The components in this case have two ports declared, but only one is used.
So mapping is like: client(pt2) ------dual faced port upper part ---dual faced port lower part ----server (pt1)
I hope this will clear the confusion
Best regards
Elemer
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 16:09:16 GMT 2024
Powered by FUDForum. Page generated in 0.02379 seconds |
] 
Search
Help
Register
Login
Home
Thank you for the answer.