You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -42,6 +44,22 @@ Similar to FLAG1, this field is reserved for future use to describe additional a
42
44
43
45
The content of an information packet is plain text containing informational data.
44
46
47
+
The server sends an `info` packet to the client in two specific situations:
48
+
49
+
-**On Connection**: When a client successfully connects to the server, the server sends a welcome `info` packet:
50
+
51
+
```
52
+
Welcome to the CSM TCP Router Server
53
+
API: "list", "list api", "list states", "help"
54
+
type "bye" to close connection from Server side.
55
+
```
56
+
57
+
-**On Disconnection**: When the connection is closed from the server side, the server sends a goodbye `info` packet:
58
+
59
+
```
60
+
Good bye.
61
+
```
62
+
45
63
### Error Packet (`error`)
46
64
47
65
The content of an error packet is plain text describing an error, formatted as per the CSM Error format.
@@ -89,6 +107,20 @@ The content of a command packet is a command in the CSM local command format. It
89
107
>
90
108
> When module `A` sends a `Status`, the client will automatically receive a `status` packet.
91
109
110
+
### Command Response Packet (`cmd-resp`)
111
+
112
+
Except for synchronous messages (`-@`), all other command packets (`cmd`) receive a handshake response after being received and processed by the server:
113
+
114
+
-**Normal case**: A `cmd-resp` packet is returned, indicating the command has been accepted and triggered for execution.
115
+
-**Error case**: An `error` packet is returned, indicating the command was not accepted or an error occurred during execution (e.g., the target module does not exist, execution failed, etc.).
116
+
117
+
> [!NOTE]
118
+
> `cmd-resp` is a handshake acknowledgment of the command, indicating that the command has been accepted and execution has started. It does not contain business response data.
119
+
> Business response data is returned via `resp` or `async-resp` packets.
120
+
>
121
+
> Synchronous messages (`-@`) do not have a `cmd-resp` handshake; upon completion, they directly return `resp` or `error`.
122
+
>
123
+
92
124
### Synchronous Response Packet (`resp`)
93
125
94
126
After executing a synchronous command, the TCP router sends a response packet back to the client.
@@ -102,3 +134,94 @@ After executing an asynchronous command, the TCP router sends a response packet
102
134
When a client subscribes to the status of a CSM module, it will automatically receive this packet whenever the status changes.
103
135
104
136
The packet format is: `Status Name >> Status Data <- Sending Module`.
137
+
138
+
## Communication Flow
139
+
140
+
### Synchronous Message Flow (`-@`)
141
+
142
+
After the client sends a synchronous command, it **must wait** for the server to return a response: either a `resp` (synchronous response data) or an `error` (error message). Synchronous messages do not have a `cmd-resp` handshake packet.
143
+
144
+
```mermaid
145
+
sequenceDiagram
146
+
participant C as Client
147
+
participant S as TCP-Router Server
148
+
149
+
C->>S: cmd (synchronous message -@)
150
+
alt Command executed successfully
151
+
S-->>C: resp (synchronous response data)
152
+
else Command execution failed
153
+
S-->>C: error (error message)
154
+
end
155
+
```
156
+
157
+
### Asynchronous Message Flow (`->`)
158
+
159
+
After the client sends an asynchronous command, the server first returns a confirmation packet: either `cmd-resp` (command accepted) or `error` (command not accepted or execution error). Upon receiving `cmd-resp`, the client **does not need to wait** for the business response and can continue sending other commands; after asynchronous processing is complete, the server returns an `async-resp` packet.
160
+
161
+
```mermaid
162
+
sequenceDiagram
163
+
participant C as Client
164
+
participant S as TCP-Router Server
165
+
166
+
C->>S: cmd (asynchronous message ->)
167
+
alt Command accepted
168
+
S-->>C: cmd-resp (command accepted)
169
+
Note over S: Processing asynchronously...
170
+
S-->>C: async-resp (asynchronous response data)
171
+
else Not accepted or execution error
172
+
S-->>C: error (error message)
173
+
end
174
+
```
175
+
176
+
### Asynchronous Without Return Flow (`->|`)
177
+
178
+
After the client sends an asynchronous without return command, the server first returns a confirmation packet: either `cmd-resp` (command accepted) or `error` (command not accepted or execution error). Once the command is accepted, **no** business response packet will be returned after processing is complete.
After the client sends a subscribe or unsubscribe command, the server returns a `cmd-resp` handshake confirmation. Once subscribed, whenever the subscribed module emits a status, the client continuously receives `status` packets (normal broadcast) or `interrupt` packets (interrupt broadcast), until unsubscribed.
196
+
197
+
> [!NOTE]
198
+
> Both `status` and `interrupt` subscription broadcast types are supported:
199
+
> -`status` (`0x06`): Normal broadcast, subscribes to regular status changes of the module
200
+
> -`interrupt` (`0x07`): Interrupt broadcast, subscribes to interrupt events triggered by the module
doc = "Measurement Module.%0AAPI: %0A1. Sweep %3E%3E Start%3BStop%3BStep%3BInterval %2F%2F sweep current with specified parameters.%0A2. Measure %2F%2F Return voltage and current at the same time."
0 commit comments