1<?xml version="1.0" encoding="UTF-8"?> 2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3<html xml:lang="en-US" lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> 4<head> 5 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 6 <meta http-equiv="Content-Style-Type" content="text/css" /> 7 <link rel="stylesheet" href="../../css/manpage.css" type="text/css" /> 8</head> 9<body> 10 11<h1>rdt - <CODE>ServerClient</CODE> Demo</h1> 12 13<h2>Description</h2> 14 15<div class="section"> 16 <p>This is a sample of the use of the RDT library for one-to-one communications.<br /> Two CTR systems (one UDS Master and one UDS Client) are required to run this demo.</p> 17</div> 18 19<h2>Required Environment</h2> 20 21<div class="section"> 22 <p>None.</p> 23</div> 24 25<h2>How to Use</h2> 26 27<div class="section"> 28 Before UDS Connection: 29 <table> 30 <thead> 31 <tr> 32 <th>Input</th> 33 <th>Operation</th> 34 </tr> 35 </thead> 36 <tr> 37 <td>A Button</td> 38 <td>Create a network as the UDS Master.</td> 39 </tr> 40 <tr> 41 <td>B Button</td> 42 <td>Connect as the UDS Client to the network created by the UDS Master.</td> 43 </tr> 44 </table> 45 46 After UDS Connection: 47 <table> 48 <thead> 49 <tr> 50 <th>Input</th> 51 <th>Operation</th> 52 </tr> 53 </thead> 54 <tr> 55 <td>A Button</td> 56 <td>Begin server process (the side sending data).</td> 57 </tr> 58 <tr> 59 <td>B Button</td> 60 <td>Begin client process (the side receiving data).</td> 61 </tr> 62 <tr> 63 <td>X Button</td> 64 <td>(During data transceiving) aborts data sending and receiving.</td> 65 </tr> 66 <tr> 67 <td>Y Button</td> 68 <td>Disconnects from the UDS network and ends the demo.</td> 69 </tr> 70 </table> 71</div> 72 73<h2>Notes</h2> 74 75<div class="section"> 76 <p>This demo does not display anything on the screen. Logs are all displayed in debug output.</p> 77</div> 78 79<h2>Execution Procedure</h2> 80 81<div class="section"> 82 83For this demo, the various roles of the CTR systems are defined as follows: 84 <table> 85 <tr><td>UDS Master</td><td> Constructs the UDS network using <CODE>nn::uds::CreateNetwork</CODE>.</td></tr> 86 <tr><td>UDS Client</td><td> Connects to the UDS network using <CODE>nn::uds::ConnectNetwork</CODE>.</td></tr> 87 </table> 88 After UDS connection, the CTR systems have these roles, regardless of whether the system is the UDS Master or the UDS Client. 89 <table> 90 <tr><td>Server</td><td>The side sending data.</td></tr> 91 <tr><td>Client</td><td>The side receiving data. (This differs in meaning from "UDS Client.")</td></tr> 92 </table> 93 <p>The following log is displayed when the demo is run.</p> 94 <pre class="code">START 95[RDT_DEMO] Select UDS (A: Master B: Client) 96</pre> 97 98 <h3>UDS Connection</h3> 99 100 <h4>The side acting as UDS Master</h4> 101 <p>Information is displayed in the log as follows if the A Button is used to select <B>Master</B>.</p> 102 <code>[RDT_DEMO] -> Select: UDS Master!</code> 103 <p>Once connected to the UDS Client, move to the data sending/receiving phase in the RDT library.</p> 104 105 <h4>The side acting as UDS Client</h4> 106 <p>Information is displayed in the log as follows if the B Button is used to select Client.</p> 107 <code>[RDT_DEMO] -> Select: UDS Client!</code> 108 <p>Once connected to the UDS Master, move to the data sending/receiving phase in the RDT library.</p> 109 110 <h3>Sending and Receiving Data</h3> 111A log similar to the following is displayed once the UDS connection is established. 112 <pre class="code"> 113[UDS] Connect! ID:2 114<MODE SELECT> Press A or B button. (A: Server B: Client Y: Exit)</pre> 115 <h4>The Server</h4> 116 <p>Press the A Button to select <B>Server</B>, and the system waits for a data request from the <B>Client</B>.<br> A log such as the following is displayed.</p> 117 <code>[RDT_DEMO] -> Select: Server! (X: Cancel)</code> 118 <p>The Server process advances as follows: Receives request from Client → Server sends data → Receives Ack from Client.<br></p> 119 <p>While data is being sent, a log like the following is displayed.</p> 120<pre class="code"> 121 [SERVER] ChangeState 0 --> 1 122 [Receiver]Receiver::Receive 128 bytes 128/128 123 [Receiver]Receive Finish! 128 bytes 124 [SERVER] ChangeState 1 --> 2 125 [Sender] Sender::Send 4096 bytes 4096/524288 126 [Sender] Sender::Send 4096 bytes 8192/524288 127 128 ... 129 130 [Sender] Sender::Send 4096 bytes 520192/524288 131 [Sender] Sender::Send 4096 bytes 524288/524288 132 [SERVER] ChangeState 2 --> 3 133 [Receiver]Receiver::Receive 128 bytes 128/128 134 [Receiver]Receive Finish! 128 bytes 135 [SERVER] ChangeState 3 --> 4 136[RDT_DEMO]RDT DEMO - SERVER - Send Data Success. 137</pre> 138 139 140 141 <h4>The Client</h4> 142 <p>Press the B Button to select <B>Client</B>, and the system sends a data request to the <B>Server</B>.</p> 143 <code>[RDT_DEMO] -> Select: Client! (X: Cancel)</code> 144 <p>The Client process advances as follows: Client sends request → Receives data from Server → Client sends Ack.<br></p> 145 <p>While data is being received, a log like the following is displayed.</p> 146<pre class="code"> 147 [CLIENT] ChangeState 0 --> 1 148 [Sender] Sender::Send 128 bytes 128/128 149 [CLIENT] ChangeState 1 --> 2 150 [Receiver]Receiver::Receive 4096 bytes 4096/524288 151 [Receiver]Receiver::Receive 4096 bytes 8192/524288 152 153 ... 154 155 [Receiver]Receiver::Receive 4320 bytes 520480/524288 156 [Receiver]Receiver::Receive 3808 bytes 524288/524288 157 [Receiver]Receive Finish! 524288 bytes 158 [CLIENT] ChangeState 2 --> 3 159 [Sender] Sender::Send 128 bytes 128/128 160 [CLIENT] ChangeState 3 --> 4 161[RDT_DEMO]RDT DEMO - CLIENT - Receive Data Success. 162</pre> 163 164 <h4>Exit</h4> 165Press the Y Button to drop the UDS connection and end the demo. 166<pre class="code">[RDT_DEMO] -> UDS: Disconnect! 167[RDT_DEMO]Exit Loop --> Finalize 168[RDT_DEMO]DEMO END</pre> 169 170</div> 171 172<h2>Notes Regarding RDT Implementation</h2> 173<div class="section"> 174 <p> 175 In a communication session between an RDT <B>Sender</B> and <B>Receiver</B>, there is no way for the <B>Sender</B> to know for certain that the <B>Receiver</B> got the sent data.<br> (Even though it seems that the <B>Sender</B> has completed sending, it is possible for the <B>Receiver</B> to cancel just before then.)<br> <br>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:<br>Client sends request → Server sends data → Client sends Ack<br> <br> If this series of steps is not successful, it means that communication has failed at some point.<br> 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.<br> In particular, when <B>Sender</B>/<B>Receiver</B> is <CODE>STATE_CLOSED</CODE>, the reset packet is not received when the communication partner aborts using the <CODE>Cancel</CODE> function so there is no way of knowing that the partner has stopped communication.<br> 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.<br> 176</p> 177</div> 178 179 180<h2>Revision History</h2> 181 182<div class="section"> 183 <dl class="history"> 184 <dt>2012/10/18</dt> 185 <dd>Initial version.</dd> 186 </dl> 187</div> 188 189 190<hr><p>CONFIDENTIAL</p></body> 191</html>