ServerClient
DemoThis 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.
None.
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. |
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. |
This demo does not display anything on the screen. Logs are all displayed in debug output.
UDS Master | Constructs the UDS network using nn::uds::CreateNetwork . |
UDS Client | Connects to the UDS network using nn::uds::ConnectNetwork . |
Server | The side sending data. |
Client | The 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)
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.
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.
[UDS] Connect! ID:2 <MODE SELECT> Press A or B button. (A: Server B: Client Y: Exit)
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.
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.
[RDT_DEMO] -> UDS: Disconnect! [RDT_DEMO]Exit Loop --> Finalize [RDT_DEMO]DEMO END
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.
CONFIDENTIAL