Changes between Version 5 and Version 6 of Old/OTG/ArchitectureDesign
- Timestamp:
- Oct 6, 2005, 5:43:21 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Old/OTG/ArchitectureDesign
v5 v6 28 28 The OTG and OTR program are implemented in the user space. To support point-to-multipoint communication, each port in OTG could associate more than one stream object. Based on different source and destinations, packets are classified to several streams. A port in OTG could deliver several streams to different OTR program through a common UDP or TCP port. Also, the OTR could receive several streams from different OTG program. 29 29 To let the receiver software OTR have the capability to extract PHY measurements from the driver, we need a custom driver which is compatible with LibMac library. 30 The above mentioned architecture allows us to extend the OTG-OTR application to support multiple sending streams and multiple receiving applications. However, the baseline requirement for the OTG/OTR design is the very simple one-sender-one-receive point-to-point communication. Therefore, the baseline application will only include a communication path and components in the shaded region. And this case will also satisfy the test and measurement demands of most users.30 The above mentioned architecture allows us to extend the OTG-OTR application to support multiple sending streams and multiple receiving applications. However, the baseline requirement for the OTG/OTR design is the very simple one-sender-one-receive point-to-point communication. Therefore, the baseline application will only include a communication path and components in the shaded region. And this case will also satisfy the test and measurement demands of most users. 31 31 32 32 '''Note that in OTG and OTR, "Stream" and "Gate" are master components respectively. They control the sending and receiving thread respectively.There also exists an OMLObject pointer in Gate and Stream to enable control of OML measurements reporting.''' … … 43 43 === Design of OTR === 44 44 45 The OTR is a multi-thread application too. The main thread is to handle user input. And for each Gate object, a separate thread is going to create to receive packets from this gate. Each Gate object is the master object to control other objects in the OTR program Whenever an OTR application is started, at least one Gate has to be started as default. However, a gate is not limited to receiving homogen ous packets from the same source. If multiple sources or connections are communicating with one socket port, the Gate will de-multiplex the traffic and give each packet a flow identifier to show its source address. However, all packets are still passed to the same Sink object.45 The OTR is a multi-thread application too. The main thread is to handle user input. And for each Gate object, a separate thread is going to create to receive packets from this gate. Each Gate object is the master object to control other objects in the OTR program Whenever an OTR application is started, at least one Gate has to be started as default. However, a gate is not limited to receiving homogeneous packets from the same source. If multiple sources or connections are communicating with one socket port, the Gate will demultiplex the traffic and give each packet a flow identifier to show its source address. However, all packets are still passed to the same Sink object. 46 46 When an OTR application is started, a default gate will be created. A default sink object is also created to bind to this gate. In the case of UDP, whenever a packet from a new address, it will generate a new flow for all packets from this address. In the case of TCP, whenever accept a new connection; a new flow is created to accommodate the packets in this direction. 47 47 Note that this architecture design allows one OTG Application having multiple Gates. ''But in practice, the user is now limited to start only one Gate with one OTR application.'' … … 72 72 The demultiplex part of UDP Gate and TCP Gate is slightly different: 73 73 * UDP Socket create a new flow based on the received packet's source address if necessary. therefore, we use simple consecutive numerical numbers as flow id. 74 * TCP Socket would create a new flow when acceptNewConnnection() func iton is called. This occured before a single TCP packet is receivd. We use socket file descriptor as flow id.74 * TCP Socket would create a new flow when acceptNewConnnection() function is called. This occurred before a single TCP packet is received. We use socket file descriptor as flow id. 75 75 [[BR]] 76 76 ''Note: We did not support demultiplexing for raw sockets now'' … … 79 79 Each gate holds a flow table to record the demultiplex information. It says which packet is from which source IP and port. 80 80 Unlike previous design, the packet is no longer passed to the flow object, but from gate to sink directly. 81 Flow table is just an index table to checking the packet's srouce information and set the "flow id" measurement for th eis packet.81 Flow table is just an index table to checking the packet's srouce information and set the "flow id" measurement for this packet. 82 82 The information in the table should include: 83 83 * flow identifier 84 84 * sender IP address 85 85 * sender port (if applicable) 86 * s neder MAC address (if applicable)86 * sender MAC address (if applicable) 87 87 === Sink === 88 88 Sink is dummy. Just dump every received packets to nowhere. … … 96 96 === Command-line Input to start the program === 97 97 98 The basic format for user to specify an option is “--option [arg]” format. Because we have multiple kind of protocols and generators to support, the commands to configure the OTG program and OTR program need to first figure out those type information. After that, further comma d-line optons about that specific generator and protocol-port could be parsed further. However, the user only need to give all options in one command line. The program will automatically parse them in this 2-tier manner.98 The basic format for user to specify an option is “--option [arg]” format. Because we have multiple kind of protocols and generators to support, the commands to configure the OTG program and OTR program need to first figure out those type information. After that, further command-line options about that specific generator and protocol-port could be parsed further. However, the user only need to give all options in one command line. The program will automatically parse them in this 2-tier manner. 99 99 100 100 ==== Select Protocol and Generator Type ==== 101 The “parseOptionsPhase1” funct on in the main program (otg.cpp & otr.cpp) is in charge of parsing the necessary protocol and generator types. After parsing that, a specific generator and port will be created.101 The “parseOptionsPhase1” function in the main program (otg.cpp & otr.cpp) is in charge of parsing the necessary protocol and generator types. After parsing that, a specific generator and port will be created. 102 102 ==== Get 2nd Tier Option ==== 103 The “parseOptionsPhase2” funct on in the main program (otg.cpp & otr.cpp) is in charge of getting and parsing the protocol and generator optons.103 The “parseOptionsPhase2” function in the main program (otg.cpp & otr.cpp) is in charge of getting and parsing the protocol and generator options. 104 104 105 105 === Run-time Commands === 106 106 ==== Program Termination ==== 107 The OTG and OTR program is not controlled by pre-defined test duration. Instead, it has to be terminated by the “exit” command. As long as the command is not given, the OTG will keep pumping traffic and OTR program will keep receiv eing incoming packets.107 The OTG and OTR program is not controlled by pre-defined test duration. Instead, it has to be terminated by the “exit” command. As long as the command is not given, the OTG will keep pumping traffic and OTR program will keep receiving incoming packets. 108 108 109 109 ==== Pause & Resume ==== … … 114 114 115 115 == Measurements == 116 Measurement are generated within the OTG and OTR software and reported to a library server in ORBIT testbed throughput the “OML” architecture. In brief, the measurements are collected by each OML client in every running node and sent to a collection server. If an application wants to use OML, the application has to first call a “init_oml” function. Then add different measurement-points in the application where a measurement is triggered, anther OML function has to be called. Finally, those measurem ts will appear as records in an OML databases.116 Measurement are generated within the OTG and OTR software and reported to a library server in ORBIT testbed throughput the “OML” architecture. In brief, the measurements are collected by each OML client in every running node and sent to a collection server. If an application wants to use OML, the application has to first call a “init_oml” function. Then add different measurement-points in the application where a measurement is triggered, anther OML function has to be called. Finally, those measurements will appear as records in an OML databases. 117 117 118 118 === Per-Packet Measurement === … … 125 125 126 126 === Per-Stream Measurement === 127 For each stream generated by OTG, a stream id and pkt number is stamped in the payload of the packet. And those information could be retrieved by OTR. Also, the OTR could demult oplex all receiving pakets and put them in different flows. So, there are 4 measurements corresponding to this:127 For each stream generated by OTG, a stream id and pkt number is stamped in the payload of the packet. And those information could be retrieved by OTR. Also, the OTR could demultiplex all receiving packets and put them in different flows. So, there are 4 measurements corresponding to this: 128 128 * packet sequence number from sender side 129 129 * Flow id from receiver side … … 131 131 === Physical layer measurements === 132 132 With the help of LibMAC, two physical layer parameters could be extracted from a custom driver: 133 * '''RSSI''': Received Si ngal Streangth Index133 * '''RSSI''': Received Signal Strength Index 134 134 * TxRate: Xmit rate indicated in the Signal Field of PLCP header of received packet. for example 55 indicates 5.5Mbps, 540 indicates 54Mbps. 135 135 === Measurement Reporting Triggers === … … 139 139 * gen_timestamp 140 140 * tx_timestamp 141 In OTR, measurements will report by the Gate object whenever a packet is processed. Six measurem ts are triggered:141 In OTR, measurements will report by the Gate object whenever a packet is processed. Six measurements are triggered: 142 142 * pkt_seqno (stamped in sender side) 143 143 * flow_no:id of the flow … … 153 153 == Fault Management and Exception Handling == 154 154 155 Basically, information of every critical exception is put into ''stdout'' if the program is going to abort. The information is output edby an "throw" operation. and the main program will eventually output it in STDOUT. However, it seems only the function in the first-tier of main program could throw it correctly and the main program will output it into STDOUT, for those functions referred deeper, we see155 Basically, information of every critical exception is put into ''stdout'' if the program is going to abort. The information is output by an "throw" operation. and the main program will eventually output it in STDOUT. However, it seems only the function in the first-tier of main program could throw it correctly and the main program will output it into STDOUT, for those functions referred deeper, we see 156 156 {{{ 157 157 terminate called after throwing an instance of 'char const*'
