rdt - ServerClient Demo

Description

This is a sample of the use of the RDT library for one-to-one communications.
Two CTR systems (one UDS Master and one UDS Client) are required to run this demo.

Required Environment

None.

How to Use

Before UDS Connection:
Input Operation
A Button Create a network as the UDS Master.
B Button Connect as the UDS Client to the network created by the UDS Master.
After UDS Connection:
Input Operation
A Button Begin server process (the side sending data).
B Button Begin client process (the side receiving data).
X Button (During data transceiving) aborts data sending and receiving.
Y Button Disconnects from the UDS network and ends the demo.

Notes

This demo does not display anything on the screen. Logs are all displayed in debug output.

Execution Procedure

For this demo, the various roles of the CTR systems are defined as follows:
UDS Master Constructs the UDS network using nn::uds::CreateNetwork.
UDS Client Connects to the UDS network using nn::uds::ConnectNetwork.
After UDS connection, the CTR systems have these roles, regardless of whether the system is the UDS Master or the UDS Client.
ServerThe side sending data.
ClientThe side receiving data. (This differs in meaning from "UDS Client.")

The following log is displayed when the demo is run.

START
[RDT_DEMO] Select UDS (A: Master  B: Client)

UDS Connection

The side acting as UDS Master

Information is displayed in the log as follows if the A Button is used to select Master.

[RDT_DEMO] -> Select: UDS Master!

Once connected to the UDS Client, move to the data sending/receiving phase in the RDT library.

The side acting as UDS Client

Information is displayed in the log as follows if the B Button is used to select Client.

[RDT_DEMO] -> Select: UDS Client!

Once connected to the UDS Master, move to the data sending/receiving phase in the RDT library.

Sending and Receiving Data

A log similar to the following is displayed once the UDS connection is established.
[UDS] Connect! ID:2
<MODE SELECT>  Press A or B button. (A: Server  B: Client  Y: Exit)

The Server

Press the A Button to select Server, and the system waits for a data request from the Client.
A log such as the following is displayed.

[RDT_DEMO] -> Select: Server! (X: Cancel)

The Server process advances as follows: Receives request from Client → Server sends data → Receives Ack from Client.

While data is being sent, a log like the following is displayed.

  [SERVER]  ChangeState 0 --> 1
    [Receiver]Receiver::Receive 128 bytes 128/128
    [Receiver]Receive Finish! 128 bytes
  [SERVER]  ChangeState 1 --> 2
    [Sender]  Sender::Send 4096 bytes 4096/524288
    [Sender]  Sender::Send 4096 bytes 8192/524288

   ...

    [Sender]  Sender::Send 4096 bytes 520192/524288
    [Sender]  Sender::Send 4096 bytes 524288/524288
  [SERVER]  ChangeState 2 --> 3
    [Receiver]Receiver::Receive 128 bytes 128/128
    [Receiver]Receive Finish! 128 bytes
  [SERVER]  ChangeState 3 --> 4
[RDT_DEMO]RDT DEMO - SERVER - Send Data Success.

The Client

Press the B Button to select Client, and the system sends a data request to the Server.

[RDT_DEMO] -> Select: Client! (X: Cancel)

The Client process advances as follows: Client sends request → Receives data from Server → Client sends Ack.

While data is being received, a log like the following is displayed.

  [CLIENT] ChangeState 0 --> 1
    [Sender]  Sender::Send  128 bytes 128/128
  [CLIENT] ChangeState 1 --> 2
    [Receiver]Receiver::Receive 4096 bytes 4096/524288
    [Receiver]Receiver::Receive 4096 bytes 8192/524288

   ...

    [Receiver]Receiver::Receive 4320 bytes 520480/524288
    [Receiver]Receiver::Receive 3808 bytes 524288/524288
    [Receiver]Receive Finish! 524288 bytes
  [CLIENT] ChangeState 2 --> 3
    [Sender]  Sender::Send  128 bytes 128/128
  [CLIENT] ChangeState 3 --> 4
[RDT_DEMO]RDT DEMO - CLIENT - Receive Data Success.

Exit

Press the Y Button to drop the UDS connection and end the demo.
[RDT_DEMO]  -> UDS: Disconnect!
[RDT_DEMO]Exit Loop --> Finalize
[RDT_DEMO]DEMO END

Notes Regarding RDT Implementation

In a communication session between an RDT Sender and Receiver, there is no way for the Sender to know for certain that the Receiver got the sent data.
(Even though it seems that the Sender has completed sending, it is possible for the Receiver to cancel just before then.)

In this demo, ports have been prepared for the sending and receiving of data, and for the sending and receiving of commands. So the sending side can learn whether data has been sent successfully by following a procedure with these steps:
Client sends request → Server sends data → Client sends Ack

If this series of steps is not successful, it means that communication has failed at some point.
It is also possible for communications to bog down due to a misalignment of the Server/Client sequence, caused by such factors as lost and canceled packets.
In particular, when Sender/Receiver is STATE_CLOSED, the reset packet is not received when the communication partner aborts using the Cancel function so there is no way of knowing that the partner has stopped communication.
A timeout has been set in this demo, so if the series of steps does not complete within that time you know that communication has failed.

Revision History

2012/10/18
Initial version.

CONFIDENTIAL