|
70
|
1 |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
|
2 |
<html>
|
|
|
3 |
<head>
|
|
|
4 |
<title>Target Communication Framework Specification</title>
|
|
|
5 |
</head>
|
|
|
6 |
<body lang='EN-US'>
|
|
|
7 |
|
|
|
8 |
<h1>Target Communication Framework Specification</h1>
|
|
|
9 |
|
|
|
10 |
<p>Copyright (c) 2007, 2008 Wind River Systems, Inc. Made available under the EPL v1.0
|
|
|
11 |
<p>Direct comments, questions to the <a href="mailto:dsdp-tcf-dev@eclipse.org">dsdp-tcf-dev@eclipse.org</a> mailing list
|
|
|
12 |
|
|
|
13 |
<h1>Table of Contents</h1>
|
|
|
14 |
|
|
|
15 |
<ul>
|
|
|
16 |
<li><a href='#VersionHistory'>Version History</a>
|
|
|
17 |
<li><a href='#Overview'>Overview</a>
|
|
|
18 |
<ul>
|
|
|
19 |
<li><a href='#Goals'>Goals</a>
|
|
|
20 |
<li><a href='#Definitions'>Definitions</a>
|
|
|
21 |
<li><a href='#Requirements'>Requirements</a>
|
|
|
22 |
<li><a href='#Syntax'>Syntax Rules Notation</a>
|
|
|
23 |
</ul>
|
|
|
24 |
<li><a href='#Design'>Framework Software Design Considerations</a>
|
|
|
25 |
<ul>
|
|
|
26 |
<li><a href='#Concurrency'>Concurrency</a>
|
|
|
27 |
<li><a href='#Reflection'>Reflection</a>
|
|
|
28 |
<li><a href='#Ordering'>Message ordering</a>
|
|
|
29 |
</ul>
|
|
|
30 |
<li><a href='#Transport'>Transport Layer</a>
|
|
|
31 |
<li><a href='#Protocol'>Communication Protocol</a>
|
|
|
32 |
<ul>
|
|
|
33 |
<li><a href='#ProtocolCommands'>Commands</a>
|
|
|
34 |
<li><a href='#ProtocolResults'>Results</a>
|
|
|
35 |
<li><a href='#ProtocolEvents'>Events</a>
|
|
|
36 |
<li><a href='#ProtocolFlowControl'>Flow Control</a>
|
|
|
37 |
<li><a href='#ProtocolExamples'>Examples</a>
|
|
|
38 |
</ul>
|
|
|
39 |
<li><a href='#API'>API</a>
|
|
|
40 |
<li><a href='#JSON'>JSON - Preferred Marshaling</a>
|
|
|
41 |
<ul>
|
|
|
42 |
<li><a href='#JSONExamples'>JSON - Examples</a>
|
|
|
43 |
</ul>
|
|
|
44 |
<li><a href='#Locator'>Locator Service</a>
|
|
|
45 |
<ul>
|
|
|
46 |
<li><a href='#LocatorPeer'>Peer Attributes</a>
|
|
|
47 |
<li><a href='#LocatorCommands'>Locator Service Commands</a>
|
|
|
48 |
<li><a href='#LocatorEvents'>Locator Service Events</a>
|
|
|
49 |
<li><a href='#LocatorAPI'>Locator Service API</a>
|
|
|
50 |
</ul>
|
|
|
51 |
</ul>
|
|
|
52 |
|
|
|
53 |
<h2><a name='VersionHistory'>Version History</a></h2>
|
|
|
54 |
|
|
|
55 |
<table border=1 cellpadding=8>
|
|
|
56 |
<tr>
|
|
|
57 |
<th>Version
|
|
|
58 |
<th>Date
|
|
|
59 |
<th>Change
|
|
|
60 |
<tr>
|
|
|
61 |
<td>0.1
|
|
|
62 |
<td>2008-01-10
|
|
|
63 |
<td>Initial contribution
|
|
|
64 |
<tr>
|
|
|
65 |
<td>1.0
|
|
|
66 |
<td>2008-05-06
|
|
|
67 |
<td>Approved
|
|
|
68 |
<tr>
|
|
|
69 |
<td>1.1
|
|
|
70 |
<td>2009-03-04
|
|
|
71 |
<td>Added N message
|
|
|
72 |
</table>
|
|
|
73 |
|
|
|
74 |
<h1><a name='Overview'>Overview</a></h1>
|
|
|
75 |
|
|
|
76 |
<p>Today almost every device software development tool on the market has its own method
|
|
|
77 |
of communication with target system. Communication methods often require individual setup,
|
|
|
78 |
configuration and maintenance, impose unnecessary limitations.
|
|
|
79 |
Target Communication Framework goal is to establish common ground in
|
|
|
80 |
the area of communication protocols between development tools and embedded devices.</p>
|
|
|
81 |
|
|
|
82 |
<p>The goal is a single protocol used to communicate between all tools and targets:</p>
|
|
|
83 |
<p><img src='TCF Specification Image1.png'></p>
|
|
|
84 |
|
|
|
85 |
<h2><a name='Goals'>Goals</a></h2>
|
|
|
86 |
|
|
|
87 |
<ul type='disc'>
|
|
|
88 |
<li>Universal, simple, lightweight, vendor agnostic framework for tools and targets
|
|
|
89 |
to communicate for purpose of debugging, profiling, code patching and other device
|
|
|
90 |
software development needs.
|
|
|
91 |
|
|
|
92 |
<li>Single configuration per target (not per tool per target as today in most cases),
|
|
|
93 |
or no configuration when possible.
|
|
|
94 |
|
|
|
95 |
<li>Minimal overhead and footprint on target side.
|
|
|
96 |
</ul>
|
|
|
97 |
|
|
|
98 |
<h2><a name='Definitions'>Definitions</a></h2>
|
|
|
99 |
|
|
|
100 |
<dl>
|
|
|
101 |
<dt><b>Peer:</b> <dd>communication endpoint. Both hosts and targets are called peers. A
|
|
|
102 |
peer can act as a client or a server depending on services it implements.
|
|
|
103 |
|
|
|
104 |
<dt><b>Service:</b> <dd>group of related commands, events and semantic define a service.
|
|
|
105 |
A service can be discovered, added or removed as a group at communication endpoint.
|
|
|
106 |
|
|
|
107 |
<dt><b>Message:</b> <dd>a packet of data, formatted according to framework specification
|
|
|
108 |
and transmitted over communication channel.
|
|
|
109 |
|
|
|
110 |
<dt><b>Channel:</b> <dd>communication link connecting two endpoints (peers). A single
|
|
|
111 |
channel may be used to communicate with multiple services. Multiple channels may
|
|
|
112 |
be used to connect the same peers, however no command or event ordering is guaranteed
|
|
|
113 |
across channels.
|
|
|
114 |
|
|
|
115 |
<dt><b>Command:</b> <dd>command is a message sent to remote peer in order to request some
|
|
|
116 |
predefined action there.
|
|
|
117 |
|
|
|
118 |
<dt><b>Result:</b> <dd>result is a message sent as a response to a command.
|
|
|
119 |
|
|
|
120 |
<dt><b>Event:</b> <dd>event is a message sent to all interested parties in order to notify
|
|
|
121 |
them about state changes.
|
|
|
122 |
</dl>
|
|
|
123 |
|
|
|
124 |
<h2><a name='Requirements'>Requirements</a></h2>
|
|
|
125 |
|
|
|
126 |
<ul type='disc'>
|
|
|
127 |
<li>Simple and extensible protocol.
|
|
|
128 |
|
|
|
129 |
<li>Small footprint on the target.
|
|
|
130 |
|
|
|
131 |
<li>Fully asynchronous, message based communication.
|
|
|
132 |
|
|
|
133 |
<li>Two ways of message routing:
|
|
|
134 |
|
|
|
135 |
<ul>
|
|
|
136 |
<li>Point to point request/response (command/result) communication.
|
|
|
137 |
|
|
|
138 |
<li>Subscription based broadcast of notifications (events).
|
|
|
139 |
</ul>
|
|
|
140 |
|
|
|
141 |
<li>Full duplex, symmetric communication: both host and target should be able to send
|
|
|
142 |
commands and events at same time, though ability to establish communication channel
|
|
|
143 |
can be limited to host only.
|
|
|
144 |
|
|
|
145 |
<li>For each communication channel between two peers, the framework should preserve
|
|
|
146 |
order of commands, results and events.
|
|
|
147 |
|
|
|
148 |
<li>Support for slow and high latency connections.
|
|
|
149 |
|
|
|
150 |
<li>Transport protocol agnostic. The framework should work well, at least, on top
|
|
|
151 |
of: TCP/IP, UDP, USB, RS232 and JTAG.
|
|
|
152 |
|
|
|
153 |
<li>The framework should support multiplexing, that is, single target device shared
|
|
|
154 |
between multiple tools at same time. To reduce footprint on the target, multiplexing
|
|
|
155 |
can be implemented on host if needed.
|
|
|
156 |
|
|
|
157 |
<li>Dynamic discovery of participating targets and hosts. No configuration when possible.
|
|
|
158 |
|
|
|
159 |
<li>Dynamic discovery of available services (high level protocols, command sets).
|
|
|
160 |
Clients can query for available services.
|
|
|
161 |
|
|
|
162 |
<li>Services can be added and removed dynamically.
|
|
|
163 |
|
|
|
164 |
<li>Framework should define a set of common high level interfaces (services). For
|
|
|
165 |
example: flow control, memory access, registers access, up-load mechanism, kernel
|
|
|
166 |
awareness, run control, target file system, console, flash programming. Implementation
|
|
|
167 |
of these interfaces is optional, but if provided it will support much wider compatibility
|
|
|
168 |
with various tools.
|
|
|
169 |
|
|
|
170 |
<li>Framework should be layered in such a way so it is possible to use different transport
|
|
|
171 |
medias (e.g. TCP/IP, RS232, USB, etc) without any changes to individual services.
|
|
|
172 |
In other words, transport implementation should be services agnostic, and services
|
|
|
173 |
implementation should be transport agnostic.
|
|
|
174 |
|
|
|
175 |
<li>Each service defines how marshalling is done for command, result and event arguments.
|
|
|
176 |
This allows existing target agents to remain unchanged.
|
|
|
177 |
|
|
|
178 |
<li>Framework should define a preferred marshalling mechanism that new services can
|
|
|
179 |
use.
|
|
|
180 |
|
|
|
181 |
<li>The definition of services (groups of related commands and events) is separate
|
|
|
182 |
from the definition of the framework itself. The framework provides unified communication
|
|
|
183 |
mechanism, while services use it to communicate with its clients.
|
|
|
184 |
|
|
|
185 |
<li>Anybody (including 3rd parties) can add services without having to modify communication
|
|
|
186 |
protocol or framework software.
|
|
|
187 |
|
|
|
188 |
<li>The framework should support tunneling through a proxy. Proxy may be used, for
|
|
|
189 |
example:
|
|
|
190 |
|
|
|
191 |
<ul type='circle'>
|
|
|
192 |
<li>to bridge different transport protocols, like TCP and RS232;
|
|
|
193 |
|
|
|
194 |
<li>to make a RS232 or USB target connection accessible from multiple hosts;
|
|
|
195 |
|
|
|
196 |
<li>to access targets behind firewalls or otherwise not directly accessible
|
|
|
197 |
</ul>
|
|
|
198 |
|
|
|
199 |
<li>A proxy should be able to provide services in addition to those implemented by
|
|
|
200 |
a target. Such distribution of services allows target services to be implemented on
|
|
|
201 |
a host, thereby reducing the footprint on the target. For example, debug information,
|
|
|
202 |
stack back trace or OS awareness can be implemented by a proxy on a host. To provide
|
|
|
203 |
this functionality, proxy services would typically use low-level target services,
|
|
|
204 |
like memory access.
|
|
|
205 |
|
|
|
206 |
<li>Supports of concurrent requests. Maximum number of concurrent requests (window
|
|
|
207 |
size) can be limited on target side. Simple agents only have to support window size
|
|
|
208 |
of 1. Framework should maintain a queue of additional requests, so tools don't need
|
|
|
209 |
to know the window size. This may only be relevant for certain transport protocols
|
|
|
210 |
e.g. UDP.
|
|
|
211 |
|
|
|
212 |
<li>Events can be broadcasted at any time, i.e. no polling should be required.
|
|
|
213 |
|
|
|
214 |
<li>Protocol should support a standard mechanism of sending data larger than MTU.
|
|
|
215 |
</ul>
|
|
|
216 |
|
|
|
217 |
<h2><a name='Syntax'>Syntax Rules Notation</a></h2>
|
|
|
218 |
|
|
|
219 |
<p>Format of the protocol messages is defined by syntax rules. Syntax is described
|
|
|
220 |
using a simple variant of Backus-Naur Form. In particular:</p>
|
|
|
221 |
|
|
|
222 |
<ul type='disc'>
|
|
|
223 |
<li>Italic lower case words in a courier font, enclosed into angular brackets, are
|
|
|
224 |
used to denote syntactic categories, for example: <b><i><font face="Courier New" size=2 color=#333399><token>.
|
|
|
225 |
</font></i></b>Category name can be followed by colon and a text, which explains semantics
|
|
|
226 |
of the category, for example: <b><i><font face="Courier New" size=2 color=#333399><int:
|
|
|
227 |
error code></font></i></b> has same meaning as <b><i><font face="Courier New" size=2 color=#333399><int></font></i></b>,
|
|
|
228 |
but denotes that the integer number used to indicate an “error code”.
|
|
|
229 |
|
|
|
230 |
<li>A syntax rule consists of a category designation followed by one or more syntax
|
|
|
231 |
definitions for the category. The category name and each definition are placed on
|
|
|
232 |
separate lines, bullets are used to denote definitions, for example:
|
|
|
233 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
234 |
<i><chars></i>
|
|
|
235 |
⇒ <i><char></i>
|
|
|
236 |
⇒ <i><chars> <char></i>
|
|
|
237 |
</font></b></pre>
|
|
|
238 |
|
|
|
239 |
<li>Spaces are added for readability only and they are not part of the syntax.
|
|
|
240 |
|
|
|
241 |
<li>All text in the category definition, other then categories and spaces, is UTF-8
|
|
|
242 |
based representation of a message bytes.
|
|
|
243 |
|
|
|
244 |
<li>The symbol ‘•’ designates a zero byte.
|
|
|
245 |
</ul>
|
|
|
246 |
|
|
|
247 |
<h1><a name='Design'>Framework Software Design Considerations</a></h1>
|
|
|
248 |
|
|
|
249 |
<p>The framework will be packaged, distributed and installed on a host as separate
|
|
|
250 |
product. It should be installed as system service and require no configuration for
|
|
|
251 |
most common case – target connected over TCP or UDP on a local network. For more complicated
|
|
|
252 |
setup, framework should have easily accessible and user friendly GUI with all relevant
|
|
|
253 |
configuration options.</p>
|
|
|
254 |
|
|
|
255 |
<p>Framework should use a dynamic discovery protocol to locate targets and other hosts
|
|
|
256 |
running instances of the framework when possible, and maintain a dynamic list of available
|
|
|
257 |
communication endpoints, as well as lists of services available at each endpoint.
|
|
|
258 |
Host discovery is needed to locate hosts able to proxy communications for targets,
|
|
|
259 |
which are not accessible otherwise - for example, targets connected with RS232 or
|
|
|
260 |
JTAG to a remote host. It should also be possible to add target configuration manually.
|
|
|
261 |
Development tools will access this data through the Locator Service API and use it,
|
|
|
262 |
for example, to present a user a list of available targets that have capabilities
|
|
|
263 |
needed by a particular tool.</p>
|
|
|
264 |
|
|
|
265 |
<p>Framework should provide software libraries to be used by tools and target agents
|
|
|
266 |
developers. The libraries should be available at least for ANSI C and Java. On host
|
|
|
267 |
side, at least Windows, Solaris and Linux must be supported. Libraries will provide
|
|
|
268 |
APIs for low-level communication protocol, Locator Service, preferred marshaling and
|
|
|
269 |
predefined common services.</p>
|
|
|
270 |
|
|
|
271 |
<p>The proposed target communication protocol is text-based. It allows extensions,
|
|
|
272 |
which define messages with blocks of binary data, but it is not a recommended data
|
|
|
273 |
formatting, and its usage is supposed to be limited. Text-based protocols have both
|
|
|
274 |
advantages and disadvantages in compare with binary protocols.</p>
|
|
|
275 |
|
|
|
276 |
<p>Advantages:</p>
|
|
|
277 |
|
|
|
278 |
<ul type='disc'>
|
|
|
279 |
<li>The software for text-based protocols is easier to develop and debug since they
|
|
|
280 |
use a relatively human-friendly communication.
|
|
|
281 |
|
|
|
282 |
<li>It is possible to use huge selection of existing tools and library routines to
|
|
|
283 |
view, edit, validate, and transform text-based data.
|
|
|
284 |
|
|
|
285 |
<li>Text based definition is in line with current trend in Internet protocols: most
|
|
|
286 |
popular protocols such as SMTP and HTTP are text-based.
|
|
|
287 |
</ul>
|
|
|
288 |
|
|
|
289 |
<p>Disadvantages:</p>
|
|
|
290 |
|
|
|
291 |
<ul type='disc'>
|
|
|
292 |
<li>Text-based protocols usually need more bytes to store numerical data than binary
|
|
|
293 |
protocols do.
|
|
|
294 |
|
|
|
295 |
<li>Parsing of text-based data is not efficient compared to parsing of binary data
|
|
|
296 |
since text-based data is usually not stored in a way similar to how it is stored in
|
|
|
297 |
computer memory.
|
|
|
298 |
|
|
|
299 |
<li>It is seldom possible to read only part of a text-based message since the exact
|
|
|
300 |
byte offset to a data item is generally not known.
|
|
|
301 |
</ul>
|
|
|
302 |
|
|
|
303 |
<p>A possible alternative to consider is binary, variable length encoding like BaseStream.</p>
|
|
|
304 |
|
|
|
305 |
<h2><a name='Concurrency'>Concurrency</a></h2>
|
|
|
306 |
|
|
|
307 |
<p>Concurrent asynchronous communication is much faster then synchronous, because
|
|
|
308 |
it alleviates communication channel latency and allows better bandwidth utilization.
|
|
|
309 |
But it also requires proper design of framework software. Concurrency, in general,
|
|
|
310 |
implies multithreading. However, systems developed with global multithreading, are
|
|
|
311 |
often unreliable and prone to different kinds of thread synchronization problems,
|
|
|
312 |
which are often very difficult to locate and resolve. We therefore strongly recommend
|
|
|
313 |
that the software is designed to follow the compartment threading model, which simplifies
|
|
|
314 |
thread synchronization and promotes reliable software design. In this model each thread
|
|
|
315 |
execution path is strictly contained in predefined subset of code (compartment), and
|
|
|
316 |
no code, except for reentrant libraries, is executed by multiple threads. Each compartment
|
|
|
317 |
has a message queue and other threads communicate with the compartment thread by posting
|
|
|
318 |
messages to the queue.</p>
|
|
|
319 |
|
|
|
320 |
<p>Framework APIs are designed to be compatible with the compartment threading model.
|
|
|
321 |
Hence the API functions do not contain any thread synchronization primitives to protect
|
|
|
322 |
against multiple threads using the functions. All framework APIs belong to a single
|
|
|
323 |
compartment and should be used by a single thread. The same thread is used to dispatch
|
|
|
324 |
events and command results. Concurrency is achieved by declaring API functions to
|
|
|
325 |
be asynchronous. Asynchronous functions do not have any return value, and returns
|
|
|
326 |
immediately, most of the time before the intended job is done. They take additional
|
|
|
327 |
arguments to specify a callback function and callback data. In object-oriented languages
|
|
|
328 |
such as Java, this is typically done by a single callback object argument containing
|
|
|
329 |
both the data and the function. The result listener is called asynchronously when
|
|
|
330 |
the job is done. This approach is commonly known as asynchronous<b>, </b>event-driven<b>
|
|
|
331 |
</b>or<b> </b>callback-based<b> </b>programming<b>.</b></p>
|
|
|
332 |
|
|
|
333 |
<p>One important characteristic of an asynchronous code is that the methods defined
|
|
|
334 |
by the user will often be called from within the framework itself, rather than from
|
|
|
335 |
the user's application code. The framework often plays the role of the main program
|
|
|
336 |
in coordinating and sequencing application activity. This phenomenon is called Inversion
|
|
|
337 |
of Control (also known as the Hollywood Principle - "Don't call us, we'll call you").</p>
|
|
|
338 |
|
|
|
339 |
<h2><a name='Reflection'>Reflection</a></h2>
|
|
|
340 |
|
|
|
341 |
<p>Communication between development tools and embedded devices must allow a host
|
|
|
342 |
to collect target side data and build a reflection of target state. Reflection is
|
|
|
343 |
usually incomplete – a subset of all remote data. Reflection is always delayed – it
|
|
|
344 |
represents a remote peer state in the past. Reflection can be updated by polling for
|
|
|
345 |
data changes or by listening to events (event is communication message that is sent
|
|
|
346 |
asynchronously by a peer to notify others about state change). Reflection is correct
|
|
|
347 |
if it represents a state that actually did happen on remote peer.</p>
|
|
|
348 |
|
|
|
349 |
<p>Reflection is coherent if it is exactly equal to subset of peer state at a single
|
|
|
350 |
moment of time and that moment of time is not too far in the past. Non-coherent reflection
|
|
|
351 |
can have parts of data representing peer state at different moments of time. Coherent
|
|
|
352 |
reflection is more valuable for a user, because non-coherent reflection can have logically
|
|
|
353 |
conflicting data if that data was collected at different time.</p>
|
|
|
354 |
|
|
|
355 |
<p>Traditionally, debuggers would ensure coherence of state reflection by collecting
|
|
|
356 |
data only while target is suspended, and flushing all (or most) reflection data (reducing
|
|
|
357 |
observed subset to zero) when target is resumed. This approach does not work well
|
|
|
358 |
for multithreaded, multicore or real time targets. Maintaining correctness and coherence
|
|
|
359 |
of a non-empty reflection while target is running requires additional support from
|
|
|
360 |
target agent, communication software and debugger itself.</p>
|
|
|
361 |
|
|
|
362 |
<p>Since remote peer state is changing over time, coherent reflection can be built
|
|
|
363 |
only if:</p>
|
|
|
364 |
|
|
|
365 |
<ul type='disc'>
|
|
|
366 |
<li>Observed subset of state is properly selected and dynamically re-selected. Observing
|
|
|
367 |
too much can overflow communication channel. Observing too little has little value
|
|
|
368 |
for a user.
|
|
|
369 |
|
|
|
370 |
<li>Observer is listening to all relevant events.
|
|
|
371 |
|
|
|
372 |
<li>Events are coming in exactly same order as corresponding changes happen.
|
|
|
373 |
|
|
|
374 |
<li>Events are properly ordered relative to other messages that carry state data.
|
|
|
375 |
|
|
|
376 |
<li>All changes in observed subset of peer state are reported by events.
|
|
|
377 |
|
|
|
378 |
<li>All event messages must either contain a complete description of a change or they
|
|
|
379 |
all should not contain any state data at all. If client is getting some data from
|
|
|
380 |
events and required to retrieve new values of other changed data by using other means
|
|
|
381 |
(commands), the reflection will not be coherent at least until such retrieval is complete.
|
|
|
382 |
And if such periods of data retrieval overlap, the reflection will never be coherent.
|
|
|
383 |
Sending deltas with events is usually more efficient then using data retrieval commands
|
|
|
384 |
to update reflection.
|
|
|
385 |
</ul>
|
|
|
386 |
|
|
|
387 |
<h2><a name='Ordering'>Message ordering</a></h2>
|
|
|
388 |
|
|
|
389 |
<p>The transmission order of commands, results and events is important, it coveys
|
|
|
390 |
valuable information about target state transitions and it should be preserved when
|
|
|
391 |
possible. Consider an example:</p>
|
|
|
392 |
|
|
|
393 |
<p>Client transmits: </p>
|
|
|
394 |
|
|
|
395 |
<pre>
|
|
|
396 |
Command X=2
|
|
|
397 |
</pre>
|
|
|
398 |
|
|
|
399 |
<p>Then, as result of some activity of another client or the target itself, X is assigned
|
|
|
400 |
value 3.</p>
|
|
|
401 |
|
|
|
402 |
<p>Target transmits:</p>
|
|
|
403 |
|
|
|
404 |
<pre>
|
|
|
405 |
Event X=3
|
|
|
406 |
Result X=2
|
|
|
407 |
</pre>
|
|
|
408 |
|
|
|
409 |
<p>Now client has to show value of X to a user. If the order of messages is preserved,
|
|
|
410 |
the client will know that command was executed <i>after</i> X was assigned 3, the
|
|
|
411 |
last message contains last known value of X and 2 is the correct value to show. If
|
|
|
412 |
the target is allowed to transmit events and results in arbitrary order, the client
|
|
|
413 |
will have no clue what to show – 2 or 3. In fact, the client will have to make a tough
|
|
|
414 |
decision about each message it receives: either trust message data as correct last
|
|
|
415 |
known target state, or assume the message came in out-of-order and ignore it, or re-request
|
|
|
416 |
the information from the target.</p>
|
|
|
417 |
|
|
|
418 |
<p>Note that re-requesting data from the target, in general, does not solve the problem
|
|
|
419 |
of interpretation of messages when order is not preserved. For example, after sending
|
|
|
420 |
a request to read value of X, X could change at about the same time, and client could
|
|
|
421 |
receive:</p>
|
|
|
422 |
|
|
|
423 |
<pre>
|
|
|
424 |
Event X=2
|
|
|
425 |
Result X=3
|
|
|
426 |
Event X=4
|
|
|
427 |
</pre>
|
|
|
428 |
|
|
|
429 |
<p>If order is not preserved, it is still impossible to tell which value of X is the
|
|
|
430 |
last one. A client could assume value of X unknown every time it receives a notification
|
|
|
431 |
of X change, and then re-request the data again. But this is expensive and, if events
|
|
|
432 |
coming in frequently, client can end up in infinite loop re-requesting the data again
|
|
|
433 |
and again, and it will never have trustworthy data about current target state.</p>
|
|
|
434 |
|
|
|
435 |
<p>Developers should be careful when using multithreading or multiple queues in software
|
|
|
436 |
design – it can easily cause message reordering.</p>
|
|
|
437 |
|
|
|
438 |
<p>The framework itself is required to preserve message order. However, if for whatever
|
|
|
439 |
reason a target agent cannot preserve message order, the result will be that clients
|
|
|
440 |
of the service can receive messages in the wrong order. When this is the case it should
|
|
|
441 |
be well documented, so tools developers are aware and can make the best of the situation.
|
|
|
442 |
In most cases it will not cause any trouble, but there is no perfect way to restore
|
|
|
443 |
actual sequence of events and maintain data coherency after ordering was lost, and
|
|
|
444 |
in some cases it can severely impact tool functionality and user experience.</p>
|
|
|
445 |
|
|
|
446 |
<h1><a name='Transport'>Transport Layer</a></h1>
|
|
|
447 |
|
|
|
448 |
|
|
|
449 |
<p>Tools are required to be transport protocol agnostic, so most of the layer functionality
|
|
|
450 |
is used internally by framework and is not exposed to clients. This layer maintains
|
|
|
451 |
a collection of transport protocol handlers. Each handler is designed to provide:</p>
|
|
|
452 |
|
|
|
453 |
<ul type='disc'>
|
|
|
454 |
<li>Enumeration of available peers, including both automatically discovered and manually
|
|
|
455 |
configured peers. Handler fires notification events when peers are added or removed.
|
|
|
456 |
Enumeration can be implemented by scanning JTAG chain, by broadcasting special UDP
|
|
|
457 |
packet and waiting for responses, by communicating with ICE hardware, or by any other
|
|
|
458 |
suitable means.
|
|
|
459 |
|
|
|
460 |
<li>Bidirectional point-to-point communication of data packets. Packets are arrays
|
|
|
461 |
of bytes of arbitrary size.
|
|
|
462 |
Transport handler and underlying protocol are responsible for adding all necessary
|
|
|
463 |
control data, headers, error checking bits, addresses, fragmentation/defragmentation,
|
|
|
464 |
flow control, transmission retries and whatever necessary to ensure lossless, order-preserving
|
|
|
465 |
delivery of packets.
|
|
|
466 |
|
|
|
467 |
<li>Configuration UI should allow user to inspect and modify properties of both manually
|
|
|
468 |
configured and automatically discovered peers, setup new peers, view connections status
|
|
|
469 |
and statistics.
|
|
|
470 |
</ul>
|
|
|
471 |
|
|
|
472 |
<p>Existing service discovery protocols can be used together with the framework, for
|
|
|
473 |
example:</p>
|
|
|
474 |
|
|
|
475 |
<ul type='disc'>
|
|
|
476 |
<li>Zero Configuration Networking (Zeroconf), see <a href='http://www.zeroconf.org/'>http://www.zeroconf.org</a>;
|
|
|
477 |
|
|
|
478 |
<li>Service Location Protocol (SLP), developed by the IETF;
|
|
|
479 |
|
|
|
480 |
<li>Jini, which is Sun's Java-base approach to service discovery, see <a href='http://www.sun.com/jini'>http://www.sun.com/jini</a>;
|
|
|
481 |
|
|
|
482 |
<li>Salutation, developed by an open industry consortium, called the Salutation Consortium;
|
|
|
483 |
|
|
|
484 |
<li>Microsoft's Universal Plug and Play (UPnP), see <a href='http://www.upnp.org/'>http://www.upnp.org</a>;
|
|
|
485 |
|
|
|
486 |
<li>Bluetooth Service Discovery Protocol (SDP).
|
|
|
487 |
</ul>
|
|
|
488 |
|
|
|
489 |
<p>Service discovery protocols, as well as transport protocols will be supported by
|
|
|
490 |
framework plug-ins, they are not part of framework code itself, and they can be developed
|
|
|
491 |
by 3rd parties. Note that existing discovery protocols define term “service” differently
|
|
|
492 |
- as an independent communication endpoint (usually a TCP/IP port). In this document
|
|
|
493 |
it is called “peer” (host, target, communication endpoint), and a peer can provide
|
|
|
494 |
multiple services over single communication channel.</p>
|
|
|
495 |
|
|
|
496 |
<p>Using of standard discovery protocols should be optional, because it can potentially
|
|
|
497 |
cause conflict or interference between development tools and application being developed
|
|
|
498 |
over a use of same standard protocol – devices software often includes implementation
|
|
|
499 |
of service discovery protocols as part of application code to support their main functions.
|
|
|
500 |
</p>
|
|
|
501 |
|
|
|
502 |
<h1><a name='Protocol'>Communication Protocol</a></h1>
|
|
|
503 |
|
|
|
504 |
<p>The communication protocol defines data packets properties and roles common for
|
|
|
505 |
all services. The communication protocol API provides functions for opening and /closing
|
|
|
506 |
of the communication channel for a particular peer, and for sending and receiving
|
|
|
507 |
data packets. The protocol define contents of a part of a packet, the rest of the
|
|
|
508 |
packet is treated as array of bytes at this level. The communication protocol implementation
|
|
|
509 |
also provides:</p>
|
|
|
510 |
|
|
|
511 |
<ul type='disc'>
|
|
|
512 |
<li>Multiplexing – opening multiple channels per peer.
|
|
|
513 |
|
|
|
514 |
<li>Proxy – packet forwarding in behalf of other hosts.
|
|
|
515 |
</ul>
|
|
|
516 |
|
|
|
517 |
<p>Protocol defines three packet types: commands (requests), results (responses),
|
|
|
518 |
and events. Each packet consists of several protocol defined control fields followed
|
|
|
519 |
by byte array of data. Binary representation of control fields is a sequence of zero
|
|
|
520 |
terminated ASCII strings. Format of data array depends on a service. We recommend
|
|
|
521 |
using framework preferred marshaling for data formatting.</p>
|
|
|
522 |
|
|
|
523 |
<p>Syntax:</p>
|
|
|
524 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
525 |
<i><message></i>
|
|
|
526 |
⇒ <i><command></i>
|
|
|
527 |
⇒ <i><result></i>
|
|
|
528 |
⇒ <i><event></i>
|
|
|
529 |
⇒ <i><flow control message></i>
|
|
|
530 |
</font></b></pre>
|
|
|
531 |
|
|
|
532 |
<h2><a name='ProtocolCommands'>Commands</a></h2>
|
|
|
533 |
|
|
|
534 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
535 |
<i><command></i>
|
|
|
536 |
⇒ C • <i><token> </i>• <i><service name> </i>• <i><command name> </i>• <i><byte array: arguments></i>
|
|
|
537 |
</font></b></pre>
|
|
|
538 |
|
|
|
539 |
<p>Command packets start with string “C”.</p>
|
|
|
540 |
|
|
|
541 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
542 |
<i><token></i>
|
|
|
543 |
⇒ <i><chars></i>
|
|
|
544 |
</font></b></pre>
|
|
|
545 |
|
|
|
546 |
<p>Token is unique string generated by framework for each command. It is used to match
|
|
|
547 |
results to commands.</p>
|
|
|
548 |
|
|
|
549 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
550 |
<i><service name></i>
|
|
|
551 |
⇒ <i><chars></i>
|
|
|
552 |
</font></b></pre>
|
|
|
553 |
|
|
|
554 |
<p>Service name is used to identify a service that handles the command, it is same
|
|
|
555 |
string as returned by Service.getName().</p>
|
|
|
556 |
|
|
|
557 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
558 |
<i><command name></i>
|
|
|
559 |
⇒ <i><chars></i>
|
|
|
560 |
</font></b></pre>
|
|
|
561 |
|
|
|
562 |
<p>Command name interpretation depends on a service.</p>
|
|
|
563 |
|
|
|
564 |
<p>A command should always be answered with result packed. Result does not have to
|
|
|
565 |
be positive – it can include an error code, or it can be special "N" result that indicates that command was not recognized,
|
|
|
566 |
but there always must be one. Since client
|
|
|
567 |
cannot detect that a response is missing, if for some reasons peer is not able to
|
|
|
568 |
answer a command, it should consider such situation a fatal communication error and
|
|
|
569 |
it must shutdown the communication channel. It is not necessary to wait for result
|
|
|
570 |
before sending next command. In fact, sending multiple commands in a burst can greatly
|
|
|
571 |
improve performance, especially when connection has high latency. At the same time,
|
|
|
572 |
clients should be carefully designed to avoid flooding the communication channel with
|
|
|
573 |
unlimited number of requests, since this will use resources in forms of memory to
|
|
|
574 |
store the requests and time to process them.</p>
|
|
|
575 |
|
|
|
576 |
<h2><a name='ProtocolResults'>Results</a></h2>
|
|
|
577 |
|
|
|
578 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
579 |
<i><result></i>
|
|
|
580 |
⇒ N • <i><token></i> •
|
|
|
581 |
⇒ R • <i><token></i> • <i><byte array: result data></i>
|
|
|
582 |
⇒ P • <i><token></i> • <i><byte array: progress data></i>
|
|
|
583 |
</font></b></pre>
|
|
|
584 |
|
|
|
585 |
<p>Result packets start with string “P” for intermediate result, “R” for final
|
|
|
586 |
result, and “N” if command is not recognized. Receiving of “R” or “N” result concludes execution of corresponding command.
|
|
|
587 |
There should be exactly one “R” or “N” result for each command. In addition, command execution can produce any number of
|
|
|
588 |
intermediate “P” results. “P” results can be sent before “R”, and it can serve, for
|
|
|
589 |
example, as command execution progress report when execution takes long time.</p>
|
|
|
590 |
|
|
|
591 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
592 |
<i><token></i>
|
|
|
593 |
⇒ <i><chars></i>
|
|
|
594 |
</font></b></pre>
|
|
|
595 |
|
|
|
596 |
<p>Token should match token field of one of the pending commands that produced the result.</p>
|
|
|
597 |
|
|
|
598 |
<h2><a name='ProtocolEvents'>Events</a></h2>
|
|
|
599 |
|
|
|
600 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
601 |
<i><event></i>
|
|
|
602 |
⇒ E • <i><service name></i> • <i><event name></i> • <i><byte array: event data></i>
|
|
|
603 |
</font></b></pre>
|
|
|
604 |
|
|
|
605 |
<p>Event packets start with string “E”.</p>
|
|
|
606 |
|
|
|
607 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
608 |
<i><service name></i>
|
|
|
609 |
⇒ <i><chars></i>
|
|
|
610 |
</font></b></pre>
|
|
|
611 |
|
|
|
612 |
<p>Service name identifies a service that fired event, same string as returned by
|
|
|
613 |
Service.getName().</p>
|
|
|
614 |
|
|
|
615 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
616 |
<i><event name></i>
|
|
|
617 |
⇒ <i><chars></i>
|
|
|
618 |
</font></b></pre>
|
|
|
619 |
|
|
|
620 |
<p>Event name meaning depends on a service.</p>
|
|
|
621 |
|
|
|
622 |
<p>Events are used to notify clients about changes in peer state. Services should
|
|
|
623 |
provide sufficient variety of events for clients to track remote peer state without
|
|
|
624 |
too much of polling. Clients, interested in a particular aspect of the target state,
|
|
|
625 |
should have a “reflection” (or “model”) of that state and update the reflection by
|
|
|
626 |
listening for relevant events. If a service implements a command that changes a particular
|
|
|
627 |
aspect of peers state, then, normally, it should also generate notifications event
|
|
|
628 |
when that same part of the state changes and it should provide a command to retrieve
|
|
|
629 |
current value of the state – to be used by clients to initialize the reflection. Service
|
|
|
630 |
events are defined statically, together with commands. The framework does not do any
|
|
|
631 |
event processing besides delivering them to clients, however a service can define
|
|
|
632 |
additional event related functionality if necessary, for example, commands for event
|
|
|
633 |
filtering, enabling, disabling, registration, etc. Care should be taken when designing
|
|
|
634 |
events for a service - if events are sent too frequently, they will cause flooding
|
|
|
635 |
of the communication channels and degrade performance. However, too few events will
|
|
|
636 |
force clients to poll for changes and can also degrade performance. A balanced approach
|
|
|
637 |
is the best.</p>
|
|
|
638 |
|
|
|
639 |
<h2><a name='ProtocolFlowControl'>Flow Control</a> </h2>
|
|
|
640 |
|
|
|
641 |
<p>It often happens that one side of communication channel produces messages faster
|
|
|
642 |
then they can be transmitted over the channel or can be consumed by another side.
|
|
|
643 |
This will cause channel traffic congestion (flooding). Framework will deal with the
|
|
|
644 |
problem and slow down transmitting side by blocking execution inside sendEvent(),
|
|
|
645 |
sendCommand() and sendResult() functions when message buffers are full. However, in
|
|
|
646 |
many cases, it is not the best way to handle congestion. For example, it can make
|
|
|
647 |
a tool UI appear locked for prolonged time or it can break target software if it is
|
|
|
648 |
designed to work in real time. Clients can use flow control events to implement advanced
|
|
|
649 |
techniques to handle traffic congestion, for example, message coalescing, switching
|
|
|
650 |
to less detailed messages, etc.</p>
|
|
|
651 |
|
|
|
652 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
653 |
<i><flow control message></i>
|
|
|
654 |
⇒ F • <i><int: traffic congestion level></i> •
|
|
|
655 |
</font></b></pre>
|
|
|
656 |
|
|
|
657 |
<p>Traffic congestion level value is in range –100..100, where –100 means no pending
|
|
|
658 |
messages (no traffic), 0 means optimal load, and positive numbers
|
|
|
659 |
indicate level of congestion. When a peer receives flow control message with congestion level > 0
|
|
|
660 |
it should try to reduce its transmition speed.</p>
|
|
|
661 |
|
|
|
662 |
<h2><a name='ProtocolExamples'>Message Examples</a></h2>
|
|
|
663 |
|
|
|
664 |
<p>Examples use simplified command arguments and result data. See service description
|
|
|
665 |
for actual data formats.</p>
|
|
|
666 |
|
|
|
667 |
<p>Executing <b><i>suspend</i></b> command from <b><i>RunControl</i></b> service:</p>
|
|
|
668 |
|
|
|
669 |
<p> </p>
|
|
|
670 |
|
|
|
671 |
<pre>
|
|
|
672 |
Send : C 1 RunControl suspend “Thread1”
|
|
|
673 |
Receive: E RunControl suspended “Thread1”
|
|
|
674 |
Receive: R 1 “Success”
|
|
|
675 |
</pre>
|
|
|
676 |
|
|
|
677 |
<p>Same command, but target was already suspended:</p>
|
|
|
678 |
|
|
|
679 |
<pre>
|
|
|
680 |
Receive: E RunControl suspended “Thread1”
|
|
|
681 |
…
|
|
|
682 |
Send : C 2 RunControl suspend “Thread1”
|
|
|
683 |
Receive: R 2 “Already suspended”
|
|
|
684 |
</pre>
|
|
|
685 |
|
|
|
686 |
<p>Same command, but target was suspended (by another client) after sending the command,
|
|
|
687 |
but before command was executed: </p>
|
|
|
688 |
|
|
|
689 |
<pre>
|
|
|
690 |
Receive: E RunControl running “Thread1”
|
|
|
691 |
…
|
|
|
692 |
Send : C 3 RunControl suspend “Thread1”
|
|
|
693 |
Receive: E RunControl suspended “Thread1”
|
|
|
694 |
Receive: R 3 “Already suspended”
|
|
|
695 |
</pre>
|
|
|
696 |
|
|
|
697 |
<h2><a name='API'>Framework API</a></h2>
|
|
|
698 |
|
|
|
699 |
<pre>
|
|
|
700 |
<font color=#3F5FBF>/**
|
|
|
701 |
*
|
|
|
702 |
* Class Protocol provides static methods to access Target Communication Framework root objects:
|
|
|
703 |
* 1. the framework event queue and dispatch thread;
|
|
|
704 |
* 2. local instance of Locator service, which maintains a list of available targets;
|
|
|
705 |
* 3. list of open communication channels.
|
|
|
706 |
*/</font>
|
|
|
707 |
<font color=#7F0055>public class</font> Protocol {
|
|
|
708 |
|
|
|
709 |
<font color=#7F0055>private static</font> IEventQueue <i>event_queue</i>;
|
|
|
710 |
|
|
|
711 |
<font color=#3F5FBF>/**
|
|
|
712 |
* Before TCF can be used it should be given an object implementing IEventQueue interface.
|
|
|
713 |
* The implementation maintains a queue of objects implementing Runnable interface and
|
|
|
714 |
* executes <code>run</code> methods of that objects in a sequence by a single thread.
|
|
|
715 |
* The thread in referred as TCF event dispatch thread. Objects in the queue are called TCF events.
|
|
|
716 |
* Executing <code>run</code> method of an event is also called dispatching of event.
|
|
|
717 |
*
|
|
|
718 |
* Only few methods in TCF APIs are thread safe - can be invoked from any thread.
|
|
|
719 |
* If a method description does not say "can be invoked from any thread" explicitly -
|
|
|
720 |
* the method must be invoked from TCF event dispatch thread. All TCF listeners are
|
|
|
721 |
* invoked from the dispatch thread.
|
|
|
722 |
*
|
|
|
723 |
* <font color=#7F9FBF>@param</font> event_queue - IEventQueue implementation.
|
|
|
724 |
*/</font>
|
|
|
725 |
<font color=#7F0055>public static void</font> setEventQueue(IEventQueue event_queue);
|
|
|
726 |
|
|
|
727 |
<font color=#3F5FBF>/**
|
|
|
728 |
* <font color=#7F9FBF>@return</font> instance of IEventQueue that should be used for TCF events.
|
|
|
729 |
*/</font>
|
|
|
730 |
<font color=#7F0055>public static</font> IEventQueue getEventQueue();
|
|
|
731 |
|
|
|
732 |
<font color=#3F5FBF>/**
|
|
|
733 |
* Returns true if the calling thread is TCF dispatch thread.
|
|
|
734 |
* Use this call to ensure that a given task is being executed (or not being)
|
|
|
735 |
* on dispatch thread.
|
|
|
736 |
* This method is thread-safe.
|
|
|
737 |
*
|
|
|
738 |
* <font color=#7F9FBF>@return</font> true if running on the dispatch thread.
|
|
|
739 |
*/</font>
|
|
|
740 |
<font color=#7F0055>public static boolean</font> isDispatchThread();
|
|
|
741 |
|
|
|
742 |
<font color=#3F5FBF>/**
|
|
|
743 |
* Causes runnable to have its run
|
|
|
744 |
* method called in the dispatch thread of the framework.
|
|
|
745 |
* Runnables are dispatched in same order as queued.
|
|
|
746 |
* If invokeLater is called from the dispatching thread
|
|
|
747 |
* the <i>runnable.run()</i> will still be deferred until
|
|
|
748 |
* all pending events have been processed.
|
|
|
749 |
*
|
|
|
750 |
* This method can be invoked from any thread.
|
|
|
751 |
*
|
|
|
752 |
* <font color=#7F9FBF>@param runnable</font> the Runnable whose run
|
|
|
753 |
* method should be executed asynchronously.</font>
|
|
|
754 |
*/</font>
|
|
|
755 |
<font color=#7F0055>public static void</font> invokeLater(Runnable runnable);
|
|
|
756 |
|
|
|
757 |
<font color=#3F5FBF>/**
|
|
|
758 |
* Causes runnable to have its run
|
|
|
759 |
* method called in the dispatch thread of the framework.
|
|
|
760 |
* Calling thread is suspended util the method is executed.
|
|
|
761 |
* This method is thread-safe.
|
|
|
762 |
*
|
|
|
763 |
* <font color=#7F9FBF>@param runnable</font> the Runnable whose run
|
|
|
764 |
* method should be executed on dispatch thread.
|
|
|
765 |
*/</font>
|
|
|
766 |
<font color=#7F0055>public static void</font> invokeAndWait(Runnable runnable)
|
|
|
767 |
<font color=#7F0055>throws</font> InterruptedException;
|
|
|
768 |
|
|
|
769 |
<font color=#3F5FBF>/**
|
|
|
770 |
* Get instance of the framework locator service.
|
|
|
771 |
* The service can be used to discover available remote peers.
|
|
|
772 |
*
|
|
|
773 |
* @return instance of ILocator.
|
|
|
774 |
*/</font>
|
|
|
775 |
<font color=#7F0055>public static</font> ILocator getLocator();
|
|
|
776 |
|
|
|
777 |
<font color=#3F5FBF>/**
|
|
|
778 |
* Return an array of all open channels.
|
|
|
779 |
* @return an array of IChannel
|
|
|
780 |
*/</font>
|
|
|
781 |
<font color=#7F0055>public static</font> IChannel[] getOpenChannels();
|
|
|
782 |
|
|
|
783 |
<font color=#3F5FBF>/**
|
|
|
784 |
* Interface to be implemented by clients willing to be notified when
|
|
|
785 |
* new TCF communication channel is opened.
|
|
|
786 |
*/</font>
|
|
|
787 |
<font color=#7F0055>public interface</font> ChannelOpenListener {
|
|
|
788 |
<font color=#7F0055>public void</font> onChannelOpen(IChannel channel);
|
|
|
789 |
}
|
|
|
790 |
|
|
|
791 |
<font color=#3F5FBF>/**
|
|
|
792 |
* Add a listener that will be notified when new channel is opened.
|
|
|
793 |
* @param listener
|
|
|
794 |
*/</font>
|
|
|
795 |
<font color=#7F0055>public static void</font> addChannelOpenListener(ChannelOpenListener listener);
|
|
|
796 |
|
|
|
797 |
<font color=#3F5FBF>/**
|
|
|
798 |
* Remove channel opening listener.
|
|
|
799 |
* @param listener
|
|
|
800 |
*/</font>
|
|
|
801 |
<font color=#7F0055>public static void</font> removeChannelOpenListener(ChannelOpenListener listener);
|
|
|
802 |
|
|
|
803 |
<font color=#3F5FBF>/**
|
|
|
804 |
* Transmit TCF event message.
|
|
|
805 |
* The message is sent to all open communication channels – broadcasted.
|
|
|
806 |
*/</font>
|
|
|
807 |
<font color=#7F0055>public static void</font> sendEvent(String service, String name, byte[] data);
|
|
|
808 |
|
|
|
809 |
<font color=#3F5FBF>/**
|
|
|
810 |
* Call back after TCF messages sent by this host up to this moment are delivered
|
|
|
811 |
* to their intended target. This method is intended for synchronization of messages
|
|
|
812 |
* across multiple channels.
|
|
|
813 |
*
|
|
|
814 |
* Note: Cross channel synchronization can reduce performance and throughput.
|
|
|
815 |
* Most clients don't need cross channel synchronization and should not call this method.
|
|
|
816 |
*
|
|
|
817 |
* @param done will be executed by dispatch thread after communication
|
|
|
818 |
* messages are delivered to corresponding targets.
|
|
|
819 |
*/</font>
|
|
|
820 |
<font color=#7F0055>public static void</font> sync(Runnable done);
|
|
|
821 |
}
|
|
|
822 |
|
|
|
823 |
<font color=#3F5FBF>/**
|
|
|
824 |
* IChannel represents communication link connecting two endpoints (peers).
|
|
|
825 |
* The channel asynchroniously transmits messages: commands, results and events.
|
|
|
826 |
* A single channel may be used to communicate with multiple services.
|
|
|
827 |
* Multiple channels may be used to connect the same peers, however no command or event
|
|
|
828 |
* ordering is guaranteed across channels.
|
|
|
829 |
*/</font>
|
|
|
830 |
<font color=#7F0055>public interface</font> IChannel {
|
|
|
831 |
|
|
|
832 |
<font color=#3F5FBF>/**
|
|
|
833 |
* Channel state IDs
|
|
|
834 |
*/</font>
|
|
|
835 |
<font color=#7F0055>static final</font> int
|
|
|
836 |
<i><font color=#0000C0>STATE_OPENNING</font></i> = 0,
|
|
|
837 |
<i><font color=#0000C0>STATE_OPEN</font></i> = 1,
|
|
|
838 |
<i><font color=#0000C0>STATE_CLOSED</font></i> = 2;
|
|
|
839 |
|
|
|
840 |
<font color=#3F5FBF>/**
|
|
|
841 |
* <font color=#7F9FBF>@return</font> channel current state, see STATE_*
|
|
|
842 |
*/</font>
|
|
|
843 |
int getState();
|
|
|
844 |
|
|
|
845 |
<font color=#3F5FBF>/**
|
|
|
846 |
* Send command message to remote peer for execution. Commands can be queued
|
|
|
847 |
* locally before transmission. Sending commands too fast can fill up
|
|
|
848 |
* communication channel buffers. Calling thread will be blocked until
|
|
|
849 |
* enough buffer space is freed up by transmitting pending messages.
|
|
|
850 |
* <font color=#7F9FBF>@param</font> service - a remote service that will be sent the command
|
|
|
851 |
* <font color=#7F9FBF>@param</font> name - command name
|
|
|
852 |
* <font color=#7F9FBF>@param</font> args - command arguments encoded into array of bytes
|
|
|
853 |
* <font color=#7F9FBF>@param</font> done - call back object
|
|
|
854 |
* <font color=#7F9FBF>@return</font> pending command handle
|
|
|
855 |
*/</font>
|
|
|
856 |
IToken sendCommand(IService service, String name, <font color=#7F0055>byte</font>[] args,
|
|
|
857 |
ICommandListener done);
|
|
|
858 |
|
|
|
859 |
<font color=#3F5FBF>/**
|
|
|
860 |
* Command listener interface. Clients implement this interface
|
|
|
861 |
* to receive command results.
|
|
|
862 |
*/</font>
|
|
|
863 |
<font color=#7F0055>interface</font> ICommandListener {
|
|
|
864 |
|
|
|
865 |
<font color=#3F5FBF>/**
|
|
|
866 |
* Called when progress message (intermediate result) is received
|
|
|
867 |
* from remote peer.
|
|
|
868 |
* <font color=#7F9FBF>@param</font> token - command handle
|
|
|
869 |
* <font color=#7F9FBF>@param</font> data - progress message arguments encoded into array of bytes
|
|
|
870 |
*/</font>
|
|
|
871 |
<font color=#7F0055>void</font> progress(<font color=#7F0055>byte</font>[] data);
|
|
|
872 |
|
|
|
873 |
<font color=#3F5FBF>/**
|
|
|
874 |
* Called when command result received from remote peer.
|
|
|
875 |
* <font color=#7F9FBF>@param</font> token - command handle
|
|
|
876 |
* <font color=#7F9FBF>@param</font> data - command result message arguments encoded into array of bytes
|
|
|
877 |
*/</font>
|
|
|
878 |
<font color=#7F0055>void</font> result(<font color=#7F0055>byte</font>[] data);
|
|
|
879 |
|
|
|
880 |
<font color=#3F5FBF>/**
|
|
|
881 |
* Called when communication channel was closed while command was waiting for result.
|
|
|
882 |
* <font color=#7F9FBF>@param</font> token - command handle
|
|
|
883 |
* <font color=#7F9FBF>@param</font> error - exception that forced the channel to close
|
|
|
884 |
*/</font>
|
|
|
885 |
<font color=#7F0055>void</font> terminated(IToken token, Exception error);
|
|
|
886 |
}
|
|
|
887 |
|
|
|
888 |
<font color=#3F5FBF>/**
|
|
|
889 |
* Send result message to remote peer. Messages can be queued locally before
|
|
|
890 |
* transmission. Sending messages too fast can fill up communication channel
|
|
|
891 |
* buffers. Calling thread will be blocked until enough buffer space is
|
|
|
892 |
* freed up by transmitting pending messages.
|
|
|
893 |
* <font color=#7F9FBF>@param</font> token - command handle
|
|
|
894 |
* <font color=#7F9FBF>@param</font> results - result message arguments encoded into array of bytes
|
|
|
895 |
*/</font>
|
|
|
896 |
<font color=#7F0055>void</font> sendResult(IToken token, <font color=#7F0055>byte</font>[] results);
|
|
|
897 |
|
|
|
898 |
<font color=#3F5FBF>/**
|
|
|
899 |
* Get current level of outbound traffic congestion.
|
|
|
900 |
*
|
|
|
901 |
* <font color=#7F9FBF>@return</font> integer value in range –100..100, where –100 means no pending
|
|
|
902 |
* messages (no traffic), 0 means optimal load, and positive numbers
|
|
|
903 |
* indicate level of congestion.
|
|
|
904 |
*
|
|
|
905 |
* Note: in-bound traffic congestion is detected by framework and reported to
|
|
|
906 |
* remote peer without client needed to be involved. Clients willing to provide
|
|
|
907 |
* additional data about local congestion should register itself using
|
|
|
908 |
* Protocol.addCongestionMonitor().
|
|
|
909 |
*/</font>
|
|
|
910 |
int getCongestion();
|
|
|
911 |
|
|
|
912 |
<font color=#3F5FBF>/**
|
|
|
913 |
* Channel listener interface.
|
|
|
914 |
*/</font>
|
|
|
915 |
<font color=#7F0055>interface</font> IChannelListener {
|
|
|
916 |
|
|
|
917 |
<font color=#3F5FBF>/**
|
|
|
918 |
* Called when a channel is opened.
|
|
|
919 |
*/</font>
|
|
|
920 |
<font color=#7F0055>void</font> onChannelOpened();
|
|
|
921 |
|
|
|
922 |
<font color=#3F5FBF>/**
|
|
|
923 |
* Called when channel closed. If it is closed because of an error,
|
|
|
924 |
* ‘error’ parameter will describe the error. ‘error’ is null if channel
|
|
|
925 |
* is closed normally by calling Channel.close().
|
|
|
926 |
* <font color=#7F9FBF>@param</font> error - channel exception or null
|
|
|
927 |
*/</font>
|
|
|
928 |
<font color=#7F0055>void</font> onChannelClosed(Throwable error);
|
|
|
929 |
|
|
|
930 |
<font color=#3F5FBF>/**
|
|
|
931 |
* Notifies listeners about congestion level changes. When level > 0
|
|
|
932 |
* client should delay sending more messages.
|
|
|
933 |
* <font color=#7F9FBF>@param</font> level - current congestion level
|
|
|
934 |
*/</font>
|
|
|
935 |
<font color=#7F0055>void</font> congestionLevel(int level);
|
|
|
936 |
}
|
|
|
937 |
|
|
|
938 |
<font color=#3F5FBF>/**
|
|
|
939 |
* Subscribe a channel listener. The listener will be notified about changes of
|
|
|
940 |
* outbound traffic congestion level.
|
|
|
941 |
* <font color=#7F9FBF>@param</font> listener - channel listener implementation
|
|
|
942 |
*/</font>
|
|
|
943 |
<font color=#7F0055>void</font> addChannelListener(IChannelListener listener);
|
|
|
944 |
|
|
|
945 |
<font color=#3F5FBF>/**
|
|
|
946 |
* Remove a channel listener.
|
|
|
947 |
* <font color=#7F9FBF>@param</font> listener - channel listener implementation
|
|
|
948 |
*/</font>
|
|
|
949 |
<font color=#7F0055>void</font> removeChannelListener(IChannelListener listener);
|
|
|
950 |
|
|
|
951 |
<font color=#3F5FBF>/**
|
|
|
952 |
* Command server interface.
|
|
|
953 |
* This interface is to be implemented by service providers.
|
|
|
954 |
*/</font>
|
|
|
955 |
<font color=#7F0055>interface</font> ICommandServer {
|
|
|
956 |
|
|
|
957 |
<font color=#3F5FBF>/**
|
|
|
958 |
* Called every time a command is received from remote peer.
|
|
|
959 |
* <font color=#7F9FBF>@param</font> token - command handle
|
|
|
960 |
* <font color=#7F9FBF>@param</font> name - command name
|
|
|
961 |
* <font color=#7F9FBF>@param</font> data - command arguments encoded into array of bytes
|
|
|
962 |
*/</font>
|
|
|
963 |
<font color=#7F0055>void</font> command(IToken token, String name, <font color=#7F0055>byte</font>[] data);
|
|
|
964 |
}
|
|
|
965 |
|
|
|
966 |
<font color=#3F5FBF>/**
|
|
|
967 |
* Subscribe a command server. The server will be notified about command
|
|
|
968 |
* messages received through this channel for given service.
|
|
|
969 |
* <font color=#7F9FBF>@param</font> service - local service implementation
|
|
|
970 |
* <font color=#7F9FBF>@param</font> server - implementation of service commands listener
|
|
|
971 |
*/</font>
|
|
|
972 |
<font color=#7F0055>void</font> addCommandServer(IService service, ICommandServer listener);
|
|
|
973 |
|
|
|
974 |
<font color=#3F5FBF>/**
|
|
|
975 |
* Remove a command server.
|
|
|
976 |
* <font color=#7F9FBF>@param</font> service - local service implementation
|
|
|
977 |
* <font color=#7F9FBF>@param</font> server - implementation of service commands listener
|
|
|
978 |
*/</font>
|
|
|
979 |
<font color=#7F0055>void</font> removeCommandServer(IService service, ICommandServer listener);
|
|
|
980 |
|
|
|
981 |
<font color=#3F5FBF>/**
|
|
|
982 |
* A generic interface for service event listener.
|
|
|
983 |
* Services usually define a service specific event listener interface,
|
|
|
984 |
* which is implemented using this generic listener.
|
|
|
985 |
* Service clients should use service specific listener interface,
|
|
|
986 |
* unless no such interface is defined.
|
|
|
987 |
*/</font>
|
|
|
988 |
<font color=#7F0055>interface</font> IEventListener {
|
|
|
989 |
<font color=#3F5FBF>/**
|
|
|
990 |
* Called when service event message is received
|
|
|
991 |
* <font color=#7F9FBF>@param</font> name - event name
|
|
|
992 |
* <font color=#7F9FBF>@param</font> data - event arguments encode as array of bytes
|
|
|
993 |
*/</font>
|
|
|
994 |
<font color=#7F0055>void</font> event(String name, <font color=#7F0055>byte</font>[] data);
|
|
|
995 |
}
|
|
|
996 |
|
|
|
997 |
<font color=#3F5FBF>/**
|
|
|
998 |
* Subscribe an event message listener for given service.
|
|
|
999 |
* <font color=#7F9FBF>@param</font> service - remote service proxy
|
|
|
1000 |
* <font color=#7F9FBF>@param</font> server - implementation of service event listener
|
|
|
1001 |
*/</font>
|
|
|
1002 |
<font color=#7F0055>void</font> addEventListener(IService service, IEventListener listener);
|
|
|
1003 |
|
|
|
1004 |
<font color=#3F5FBF>/**
|
|
|
1005 |
* Unsubscribe an event message listener for given service.
|
|
|
1006 |
* <font color=#7F9FBF>@param</font> service - remote service proxy
|
|
|
1007 |
* <font color=#7F9FBF>@param</font> server - implementation of service event listener
|
|
|
1008 |
*/</font>
|
|
|
1009 |
<font color=#7F0055>void</font> removeEventListener(IService service, IEventListener listener);
|
|
|
1010 |
|
|
|
1011 |
<font color=#3F5FBF>/**
|
|
|
1012 |
* <font color=#7F9FBF>@return</font> IPeer object representing local endpoint of communication channel.
|
|
|
1013 |
*/</font>
|
|
|
1014 |
IPeer getLocalPeer();
|
|
|
1015 |
|
|
|
1016 |
<font color=#3F5FBF>/**
|
|
|
1017 |
* <font color=#7F9FBF>@return</font> IPeer object representing remote endpoint of communication channel.
|
|
|
1018 |
*/</font>
|
|
|
1019 |
IPeer getRemotePeer();
|
|
|
1020 |
|
|
|
1021 |
<font color=#3F5FBF>/**
|
|
|
1022 |
* <font color=#7F9FBF>@return</font> collection of services available on local peer.
|
|
|
1023 |
*/</font>
|
|
|
1024 |
Collection<String> getLocalServices();
|
|
|
1025 |
|
|
|
1026 |
<font color=#3F5FBF>/**
|
|
|
1027 |
* <font color=#7F9FBF>@return</font> an object representing a service from local peer.
|
|
|
1028 |
* Return null if the service is not available.
|
|
|
1029 |
*/</font>
|
|
|
1030 |
IService getLocalService(String service_name);
|
|
|
1031 |
|
|
|
1032 |
<font color=#3F5FBF>/**
|
|
|
1033 |
* <font color=#7F9FBF>@return</font> an object representing a service from local peer.
|
|
|
1034 |
* Service object should implement given interface.
|
|
|
1035 |
* Return null if implementation of the interface is not available.
|
|
|
1036 |
*/</font>
|
|
|
1037 |
<V <font color=#7F0055>extends</font> IService> V getLocalService(Class<V> service_interface);
|
|
|
1038 |
|
|
|
1039 |
<font color=#3F5FBF>/**
|
|
|
1040 |
* <font color=#7F9FBF>@return</font> collection of services available on remote peer.
|
|
|
1041 |
*/</font>
|
|
|
1042 |
Collection<String> getRemoteServices();
|
|
|
1043 |
|
|
|
1044 |
<font color=#3F5FBF>/**
|
|
|
1045 |
* <font color=#7F9FBF>@return</font> an object (proxy) representing a service from remote peer.
|
|
|
1046 |
* Return null if the service is not available.
|
|
|
1047 |
* Return an instance of GenericProxy if 'service_name' is not a standard TCF service.
|
|
|
1048 |
*/</font>
|
|
|
1049 |
IService getRemoteService(String service_name);
|
|
|
1050 |
|
|
|
1051 |
<font color=#3F5FBF>/**
|
|
|
1052 |
* <font color=#7F9FBF>@return</font> an object (proxy) representing a service from remote peer,
|
|
|
1053 |
* which implements given interface.
|
|
|
1054 |
* Return null if implementation of the interface is not available.
|
|
|
1055 |
*/</font>
|
|
|
1056 |
<V <font color=#7F0055>extends</font> IService> V getRemoteService(Class<V> service_interface);
|
|
|
1057 |
|
|
|
1058 |
<font color=#3F5FBF>/**
|
|
|
1059 |
* Install a service proxy object on this channel.
|
|
|
1060 |
* This method can be called only from channel open call-back.
|
|
|
1061 |
* It allows a client to extends TCF by adding proxy objects for non-standard services.
|
|
|
1062 |
* Client, wishing to become service proxy provider, should register itself
|
|
|
1063 |
* using either Protocol.addChannelOpenListener() or IChannel.addChannelListener().
|
|
|
1064 |
* It is not allowed to register more then one proxy for a given service interface.
|
|
|
1065 |
*/</font>
|
|
|
1066 |
<V <font color=#7F0055>extends</font> IService> <font color=#7F0055>void</font> setServiceProxy(Class<V> service_interface, IService service_proxy);
|
|
|
1067 |
|
|
|
1068 |
<font color=#3F5FBF>/**
|
|
|
1069 |
* Close communication channel.
|
|
|
1070 |
*/</font>
|
|
|
1071 |
<font color=#7F0055>void</font> close();
|
|
|
1072 |
|
|
|
1073 |
<font color=#3F5FBF>/**
|
|
|
1074 |
* Close channel in case of communication error.
|
|
|
1075 |
* <font color=#7F9FBF>@param error</font> - cause of channel termination
|
|
|
1076 |
*/</font>
|
|
|
1077 |
<font color=#7F0055>void</font> terminate(Throwable error);
|
|
|
1078 |
|
|
|
1079 |
<font color=#3F5FBF>/**
|
|
|
1080 |
* Redirect this channel to given peer using this channel remote peer locator service as a proxy.
|
|
|
1081 |
* <font color=#7F9FBF>@param peer_</font> - peer that will become new remote communication endpoint of this channel
|
|
|
1082 |
*/</font>
|
|
|
1083 |
<font color=#7F0055>void</font> redirect(IPeer peer);
|
|
|
1084 |
}
|
|
|
1085 |
|
|
|
1086 |
|
|
|
1087 |
<font color=#3F5FBF>/**
|
|
|
1088 |
* Object implemeting IToken interface is created by framework for every
|
|
|
1089 |
* command sent over communication channel. It is used to match command to its
|
|
|
1090 |
* results, and also can be used to cancel commands.
|
|
|
1091 |
*/</font>
|
|
|
1092 |
<font color=#7F0055>public</font> interface IToken {
|
|
|
1093 |
|
|
|
1094 |
<font color=#3F5FBF>/**
|
|
|
1095 |
* Try to cancel a command associated with given token. A command can be
|
|
|
1096 |
* canceled by this method only if it was not transmitted yet to remote peer
|
|
|
1097 |
* for execution. Successfully canceled command does not produce any result
|
|
|
1098 |
* messages.
|
|
|
1099 |
*
|
|
|
1100 |
* <font color=#7F9FBF>@return</font> true if successful.
|
|
|
1101 |
*/</font>
|
|
|
1102 |
<font color=#7F0055>boolean</font> cancel();
|
|
|
1103 |
}
|
|
|
1104 |
|
|
|
1105 |
</pre>
|
|
|
1106 |
|
|
|
1107 |
<h1><a name='JSON'>Preferred Marshaling</a></h1>
|
|
|
1108 |
|
|
|
1109 |
<p>TCF messages data format is service specific. Since services specifications are
|
|
|
1110 |
separate from protocol specification, a service designer can choose any data format that
|
|
|
1111 |
suits the service requirements best. However, to promote better compatibility and to
|
|
|
1112 |
simplify service design and implementation, we recommend to use <b>JSON</b> for data formatting.</p>
|
|
|
1113 |
|
|
|
1114 |
<p><b>JSON</b> (pronounced like the
|
|
|
1115 |
English given name <i>Jason</i>), which stands for "<b>J</b>ava<b>S</b>cript <b>O</b>bject
|
|
|
1116 |
<b>N</b>otation", is a lightweight, text-based, language-independent computer data
|
|
|
1117 |
interchange format. <b>JSON</b> is a subset of the object literal notation of JavaScript
|
|
|
1118 |
but its use does not require JavaScript.</p>
|
|
|
1119 |
|
|
|
1120 |
<p><b>JSON</b> represents data with the same basic types that programming languages
|
|
|
1121 |
use. <b>JSON</b>'s basic types are:</p>
|
|
|
1122 |
|
|
|
1123 |
<ul type='disc'>
|
|
|
1124 |
<li>Number (integer, real, or floating-point)
|
|
|
1125 |
|
|
|
1126 |
<li>String (double-quoted with backslash escapement)
|
|
|
1127 |
|
|
|
1128 |
<li>Boolean (<code>true</code> and <code>false</code>)
|
|
|
1129 |
|
|
|
1130 |
<li>Array (an ordered sequence of values)
|
|
|
1131 |
|
|
|
1132 |
<li>Object (collection of key/value pairs)
|
|
|
1133 |
|
|
|
1134 |
<li><code>null</code>
|
|
|
1135 |
</ul>
|
|
|
1136 |
|
|
|
1137 |
<p>The structures used in most programming languages easily map directly onto JSON's
|
|
|
1138 |
structures, and back again.</p>
|
|
|
1139 |
|
|
|
1140 |
<p>JSON maps data onto Unicode string. Then the string is mapped onto array of bytes
|
|
|
1141 |
using UTF-8 encoding.</p>
|
|
|
1142 |
|
|
|
1143 |
<p>JSON specification:</p>
|
|
|
1144 |
|
|
|
1145 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
1146 |
<i><object></i>
|
|
|
1147 |
⇒ {}
|
|
|
1148 |
⇒ { <i><members></i> }
|
|
|
1149 |
|
|
|
1150 |
<i><members></i>
|
|
|
1151 |
⇒ <i><string></i> : <i><value></i>
|
|
|
1152 |
⇒ <i><members></i> , <i><string></i> : <i><value></i>
|
|
|
1153 |
|
|
|
1154 |
<i><array></i>
|
|
|
1155 |
⇒ []
|
|
|
1156 |
⇒ [ <i><elements></i> ]
|
|
|
1157 |
|
|
|
1158 |
<i><elements></i>
|
|
|
1159 |
⇒ <i><value></i>
|
|
|
1160 |
⇒ <i><elements</i>> , <i><value></i>
|
|
|
1161 |
|
|
|
1162 |
<i><value></i>
|
|
|
1163 |
⇒ <i><string></i>
|
|
|
1164 |
⇒ <i><number></i>
|
|
|
1165 |
⇒ <i><object></i>
|
|
|
1166 |
⇒ <i><array></i>
|
|
|
1167 |
⇒ <i><boolean></i>
|
|
|
1168 |
⇒ null
|
|
|
1169 |
|
|
|
1170 |
<i><boolean></i>
|
|
|
1171 |
⇒ true
|
|
|
1172 |
⇒ false
|
|
|
1173 |
|
|
|
1174 |
<i><string></i>
|
|
|
1175 |
⇒ ""
|
|
|
1176 |
⇒ " <i><chars></i> "
|
|
|
1177 |
|
|
|
1178 |
<i><chars></i>
|
|
|
1179 |
⇒ <i><char></i>
|
|
|
1180 |
⇒ <i><chars> <char></i>
|
|
|
1181 |
|
|
|
1182 |
<i><char</i>>
|
|
|
1183 |
⇒ <i><any Unicode except " or \ or control></i>
|
|
|
1184 |
⇒ \"<i></i>
|
|
|
1185 |
⇒ \\<i></i>
|
|
|
1186 |
⇒ \/<i></i>
|
|
|
1187 |
⇒ \b<i></i>
|
|
|
1188 |
⇒ \f<i></i>
|
|
|
1189 |
⇒ \n<i></i>
|
|
|
1190 |
⇒ \r<i></i>
|
|
|
1191 |
⇒ \t<i></i>
|
|
|
1192 |
⇒ \u <i><four-hex-digits></i>
|
|
|
1193 |
|
|
|
1194 |
<i><number</i>>
|
|
|
1195 |
⇒ <i><int></i>
|
|
|
1196 |
⇒ <<i>int> <fraction></i>
|
|
|
1197 |
⇒ <<i>int> <exponent></i>
|
|
|
1198 |
⇒ <<i>int> <fraction> <exponent></i>
|
|
|
1199 |
|
|
|
1200 |
<i><int></i>
|
|
|
1201 |
⇒ <i><digit></i>
|
|
|
1202 |
⇒ <<i>digit 1-9> <digits></i>
|
|
|
1203 |
⇒ - <<i>digit></i>
|
|
|
1204 |
⇒ - <<i>digit 1-9> <digits</i>>
|
|
|
1205 |
|
|
|
1206 |
<i><fraction></i>
|
|
|
1207 |
⇒ . <i><digits></i>
|
|
|
1208 |
|
|
|
1209 |
<i><exponent></i>
|
|
|
1210 |
⇒ <i><e></i> <i><digits></i>
|
|
|
1211 |
|
|
|
1212 |
<i><digits></i>
|
|
|
1213 |
⇒ <i><digit></i>
|
|
|
1214 |
⇒ <<i>digits></i> <<i>digit></i>
|
|
|
1215 |
|
|
|
1216 |
<i><e></i>
|
|
|
1217 |
⇒ e
|
|
|
1218 |
⇒ e+
|
|
|
1219 |
⇒ e-
|
|
|
1220 |
⇒ E
|
|
|
1221 |
⇒ E+
|
|
|
1222 |
⇒ E-
|
|
|
1223 |
|
|
|
1224 |
</font></b></pre>
|
|
|
1225 |
|
|
|
1226 |
<p>See <a href='http://www.json.org/'>www.json.org</a> for more details.</p>
|
|
|
1227 |
|
|
|
1228 |
<h2><a name='JSONExamples'>Examples</a></h2>
|
|
|
1229 |
|
|
|
1230 |
<p>This is a JSON array containing two objects:</p>
|
|
|
1231 |
|
|
|
1232 |
<pre>
|
|
|
1233 |
[
|
|
|
1234 |
{
|
|
|
1235 |
"Precision": "zip",
|
|
|
1236 |
"Latitude": 37.7668,
|
|
|
1237 |
"Longitude": -122.3959,
|
|
|
1238 |
"City": "SAN FRANCISCO",
|
|
|
1239 |
"State": "CA",
|
|
|
1240 |
"Zip": "94107",
|
|
|
1241 |
"Country": "US"
|
|
|
1242 |
},
|
|
|
1243 |
{
|
|
|
1244 |
"Precision": "zip",
|
|
|
1245 |
"Latitude": 37.371991,
|
|
|
1246 |
"Longitude": -122.026020,
|
|
|
1247 |
"City": "SUNNYVALE",
|
|
|
1248 |
"State": "CA",
|
|
|
1249 |
"Zip": "94085",
|
|
|
1250 |
"Country": "US"
|
|
|
1251 |
}
|
|
|
1252 |
]
|
|
|
1253 |
</pre>
|
|
|
1254 |
|
|
|
1255 |
<h1><a name='Locator'>Locator Service</a></h1>
|
|
|
1256 |
|
|
|
1257 |
<p>Locator Service uses transport layer to search for peers and to collect data about
|
|
|
1258 |
peer's attributes and capabilities (services). Discovery mechanism depends on transport
|
|
|
1259 |
protocol and is part of that protocol handler. Targets, known by other hosts, are
|
|
|
1260 |
added to local list of peers. <font color=red>Security? </font>Automatically discovered
|
|
|
1261 |
targets require no further configuration. Additional targets can be configured manually.</p>
|
|
|
1262 |
|
|
|
1263 |
<p>All TCF peers must implement Locator service. The implementation is part of the framework itself.
|
|
|
1264 |
It is the only required service, all other services are optional and, formally, not part of the framework.</p>
|
|
|
1265 |
|
|
|
1266 |
<h2><a name='LocatorPeer'>Peer Atributes</a></h2>
|
|
|
1267 |
|
|
|
1268 |
<p><i><object: peer data></i> is collection of peer attributes. It should, at least, contain member
|
|
|
1269 |
<b><font face="Courier New" size=2 color=#333399>"ID" : <i><string></i></font></b>.
|
|
|
1270 |
It can also contain a number of components describing peer properties and capabilities.
|
|
|
1271 |
Predefined attributes are:</p>
|
|
|
1272 |
|
|
|
1273 |
<ul>
|
|
|
1274 |
<li><code><b><font face="Courier New" size=2 color=#333399>"ID" : <i><string></i></font></b></code>
|
|
|
1275 |
- ID of the peer.
|
|
|
1276 |
|
|
|
1277 |
<li><code><b><font face="Courier New" size=2 color=#333399>"Name" : <i><string></i></font></b></code>
|
|
|
1278 |
- human readable peer name.
|
|
|
1279 |
|
|
|
1280 |
<li><code><b><font face="Courier New" size=2 color=#333399>"OSName" : <i><string></i></font></b></code>
|
|
|
1281 |
- peer OS name, if applicable.
|
|
|
1282 |
|
|
|
1283 |
<li><code><b><font face="Courier New" size=2 color=#333399>"TransportName" : <i><string></i></font></b></code>
|
|
|
1284 |
- name of a trasport protocol to use to connect to this peer, for example: TCP.
|
|
|
1285 |
|
|
|
1286 |
<li><code><b><font face="Courier New" size=2 color=#333399>"Host" : <i><string></i></font></b></code>
|
|
|
1287 |
- peer host name, if transport is TCP or UDP.
|
|
|
1288 |
|
|
|
1289 |
<li><code><b><font face="Courier New" size=2 color=#333399>"Aliases" : <i><string></i></font></b></code>
|
|
|
1290 |
- peer host name aliases, if transport is TCP or UDP.
|
|
|
1291 |
|
|
|
1292 |
<li><code><b><font face="Courier New" size=2 color=#333399>"Addresses" : <i><string></i></font></b></code>
|
|
|
1293 |
- peer IP addresses, if transport is TCP or UDP.
|
|
|
1294 |
|
|
|
1295 |
<li><code><b><font face="Courier New" size=2 color=#333399>"Port" : <i><string></i></font></b></code>
|
|
|
1296 |
- peer port number, if transport is TCP or UDP.
|
|
|
1297 |
</ul>
|
|
|
1298 |
|
|
|
1299 |
<p>Most clients dont need to know peer attributes other then ID and Name. Clients are expected to call IPeer.openChannel()
|
|
|
1300 |
method and let the framework to check peers attributes and create appropriate communication cahnnel that is best suited for
|
|
|
1301 |
communication with the peer. After a channel is established, a client can learn peer capabilities by looking
|
|
|
1302 |
at services it implements (use IChannel.getRemoteServices() method to get a map of services).</p>
|
|
|
1303 |
|
|
|
1304 |
<h2><a name='LocatorCommands'>Locator Service Commands</a></h2>
|
|
|
1305 |
|
|
|
1306 |
<h3><a name='LocatorCommandRedirect'>redirect</a></h3>
|
|
|
1307 |
|
|
|
1308 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
1309 |
C • <i><token></i> • Locator • redirect • <i><string: peer ID></i> •
|
|
|
1310 |
</font></b></pre>
|
|
|
1311 |
|
|
|
1312 |
<p>The command redirects the channel to become connected to given peer.
|
|
|
1313 |
Locator service starts acting as a proxy.</p>
|
|
|
1314 |
|
|
|
1315 |
<p>Reply:</p>
|
|
|
1316 |
|
|
|
1317 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
1318 |
R • <i><token></i> • <i><error report></i> •
|
|
|
1319 |
</font></b></pre>
|
|
|
1320 |
|
|
|
1321 |
<h3><a name='LocatorCommandSync'>sync</a></h3>
|
|
|
1322 |
|
|
|
1323 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
1324 |
C • <i><token></i> • Locator • sync •
|
|
|
1325 |
</font></b></pre>
|
|
|
1326 |
|
|
|
1327 |
<p>Sync command does nothing and simply returns back an empty result. The command is used for
|
|
|
1328 |
cross channel synchronization. Since commands are executed in order they were issued, by waiting
|
|
|
1329 |
for sync result a client makes sure that all commands, that were issued before sync, are fully processed.</p>
|
|
|
1330 |
|
|
|
1331 |
<p>Reply:</p>
|
|
|
1332 |
|
|
|
1333 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
1334 |
R • <i><token></i> •
|
|
|
1335 |
</font></b></pre>
|
|
|
1336 |
|
|
|
1337 |
<h2><a name='LocatorEvents'>Locator Service Events</a></h2>
|
|
|
1338 |
|
|
|
1339 |
<pre><b><font face="Courier New" size=2 color=#333399>
|
|
|
1340 |
E • Locator • Hello • <i><array: service names></i> •
|
|
|
1341 |
E • Locator • peerAdded • <i><object: peer data></i> •
|
|
|
1342 |
E • Locator • peerChanged • <i><object: peer data></i> •
|
|
|
1343 |
E • Locator • peerRemoved • <i><string: peer ID></i> •
|
|
|
1344 |
</font></b></pre>
|
|
|
1345 |
|
|
|
1346 |
<dl>
|
|
|
1347 |
<dt><b>Hello</b>
|
|
|
1348 |
<dd>is the first message sent by the framework after establishing a communication channel.
|
|
|
1349 |
The message lets other side of the channel to know capabilities of this peer.
|
|
|
1350 |
Message data consists of an array of service names that are provided by the peer.
|
|
|
1351 |
Service names list is a complete and unambiguous declaration of peer's capabilities.
|
|
|
1352 |
To avoid ambiguity, different services (even slightly different, like versions of same service)
|
|
|
1353 |
must have different names. Framework delays all other communications between peers until exchange
|
|
|
1354 |
of Hello messages is complete.
|
|
|
1355 |
<dt><b>peerAdded</b>
|
|
|
1356 |
<dd>is sent when the service discovers a new peer.
|
|
|
1357 |
<dt><b>peerChanged</b>
|
|
|
1358 |
<dd>is sent when peer attributes change.
|
|
|
1359 |
<dt><b>peerRemoved</b>
|
|
|
1360 |
<dd>is sent when the service deletes information about a peer.
|
|
|
1361 |
</dl>
|
|
|
1362 |
|
|
|
1363 |
<h2><a name='LocatorAPI'>Locator Service API</a></h2>
|
|
|
1364 |
|
|
|
1365 |
<pre>
|
|
|
1366 |
<font color=#3F5FBF>/**
|
|
|
1367 |
* Base interface for all service interfaces. A client can get list of available services
|
|
|
1368 |
* by calling IChannel.getLocalServices() and IChannel.getRemoteServices().
|
|
|
1369 |
*
|
|
|
1370 |
* Remote services are represented by a proxy objects that implement service interfaces by
|
|
|
1371 |
* translating method calls to TCF messages and sending them to a remote peer.
|
|
|
1372 |
* When communication channel is open, TCF automatically creates proxies for standard services.
|
|
|
1373 |
* TCF clients can provides addition proxies for non-standard services by calling IChannel.setServiceProxy().
|
|
|
1374 |
*/</font>
|
|
|
1375 |
<font color=#7F0055>public</font> interface IService {
|
|
|
1376 |
|
|
|
1377 |
<font color=#3F5FBF>/**
|
|
|
1378 |
* Get unique name of this service.
|
|
|
1379 |
*/</font>
|
|
|
1380 |
String getName();
|
|
|
1381 |
}
|
|
|
1382 |
|
|
|
1383 |
<font color=#3F5FBF>/**
|
|
|
1384 |
* Both hosts and targets are represented by objects
|
|
|
1385 |
* implementing IPeer interface. A peer can act as host or
|
|
|
1386 |
* target depending on services it implements.
|
|
|
1387 |
* List of currently known peers can be retrieved by
|
|
|
1388 |
* calling ILocator.getPeers
|
|
|
1389 |
*/</font>
|
|
|
1390 |
<font color=#7F0055>public interface</font> IPeer {
|
|
|
1391 |
|
|
|
1392 |
<font color=#7F0055>static final</font> String
|
|
|
1393 |
<i><font color=#0000C0>ATTR_ID</font></i> = <font color=#2A00FF>"ID"</font>,
|
|
|
1394 |
<i><font color=#0000C0>ATTR_NAME</font></i> = <font color=#2A00FF>"Name"</font>,
|
|
|
1395 |
<i><font color=#0000C0>ATTR_OS_NAME</font></i> = <font color=#2A00FF>"OSName"</font>,
|
|
|
1396 |
<i><font color=#0000C0>ATTR_TRANSPORT_NAME</font></i> = <font color=#2A00FF>"TransportName"</font>,
|
|
|
1397 |
<i><font color=#0000C0>ATTR_IP_HOST</font></i> = <font color=#2A00FF>"Host"</font>,
|
|
|
1398 |
<i><font color=#0000C0>ATTR_IP_ALIASES</font></i> = <font color=#2A00FF>"Aliases"</font>,
|
|
|
1399 |
<i><font color=#0000C0>ATTR_IP_ADDRESSES</font></i> = <font color=#2A00FF>"Addresses"</font>,
|
|
|
1400 |
<i><font color=#0000C0>ATTR_IP_PORT</font></i> = <font color=#2A00FF>"Port"</font>;
|
|
|
1401 |
|
|
|
1402 |
|
|
|
1403 |
<font color=#3F5FBF>/**
|
|
|
1404 |
* <font color=#7F9FBF>@return</font> map of peer attributes
|
|
|
1405 |
*/</font>
|
|
|
1406 |
Map<String, String> getAttributes();
|
|
|
1407 |
|
|
|
1408 |
<font color=#3F5FBF>/**
|
|
|
1409 |
* <font color=#7F9FBF>@return</font> peer unique ID, same as getAttributes().get(ATTR_ID)
|
|
|
1410 |
*/</font>
|
|
|
1411 |
String getID();
|
|
|
1412 |
|
|
|
1413 |
<font color=#3F5FBF>/**
|
|
|
1414 |
* <font color=#7F9FBF>@return</font> peer name, same as getAttributes().get(ATTR_NAME)
|
|
|
1415 |
*/</font>
|
|
|
1416 |
String getName();
|
|
|
1417 |
|
|
|
1418 |
<font color=#3F5FBF>/**
|
|
|
1419 |
* Same as getAttributes().get(ATTR_OS_NAME)
|
|
|
1420 |
*/</font>
|
|
|
1421 |
String getOSName();
|
|
|
1422 |
|
|
|
1423 |
<font color=#3F5FBF>/**
|
|
|
1424 |
* Same as getAttributes().get(ATTR_TRANSPORT_NAME)
|
|
|
1425 |
*/</font>
|
|
|
1426 |
String getTransportName();
|
|
|
1427 |
|
|
|
1428 |
<font color=#3F5FBF>/**
|
|
|
1429 |
* Open channel to communicate with this peer.
|
|
|
1430 |
* Note: the channel is not fully open yet when this method returns.
|
|
|
1431 |
* It's state is IChannel.STATE_OPENNING.
|
|
|
1432 |
* Protocol.Listener will be called when the channel will be opened or closed.
|
|
|
1433 |
*/</font>
|
|
|
1434 |
IChannel openChannel() <font color=#7F0055>throws</font> IOException;
|
|
|
1435 |
}
|
|
|
1436 |
|
|
|
1437 |
<font color=#3F5FBF>/**
|
|
|
1438 |
* ILocator service uses transport layer to search for peers and to collect data about
|
|
|
1439 |
* peer's attributes and capabilities (services). Discovery mechanism depends on
|
|
|
1440 |
* transport protocol and is part of that protocol handler. Targets, known by other
|
|
|
1441 |
* hosts, are added to local list of peers.
|
|
|
1442 |
* Automatically discovered targets require no further configuration. Additional targets
|
|
|
1443 |
* can be configured manually.
|
|
|
1444 |
*
|
|
|
1445 |
* Clients should use Protocol.getLocator() to obtain local instance of ILocator,
|
|
|
1446 |
* then ILocator.getPeers() can be used to get of available peers (hosts and targets).
|
|
|
1447 |
*/</font>
|
|
|
1448 |
<font color=#7F0055>public interface</font> ILocator <font color=#7F0055>extends</font> IService {
|
|
|
1449 |
|
|
|
1450 |
<font color=#7F0055>static final</font> String <i><font color=#0000C0>NAME</font></i> = <font color=#2A00FF>"Locator"</font>;
|
|
|
1451 |
|
|
|
1452 |
<font color=#3F5FBF>/**
|
|
|
1453 |
* Auto-configuration command and response codes.
|
|
|
1454 |
*/</font>
|
|
|
1455 |
<font color=#7F0055>static final int</font>
|
|
|
1456 |
<i><font color=#0000C0>CONF_REQ_INFO</font></i> = 1,
|
|
|
1457 |
<i><font color=#0000C0>CONF_PEER_INFO</font></i> = 2;
|
|
|
1458 |
|
|
|
1459 |
<font color=#3F5FBF>/**
|
|
|
1460 |
* <font color=#7F9FBF>@return</font> Locator service name: "Locator"
|
|
|
1461 |
*/</font>
|
|
|
1462 |
String getName();
|
|
|
1463 |
|
|
|
1464 |
<font color=#3F5FBF>/**
|
|
|
1465 |
* Get map (ID -> IPeer) of available peers (hosts and targets).
|
|
|
1466 |
* The method return cached (currently known to the framework) list of peers.
|
|
|
1467 |
* The list is updated according to event received from transport layer
|
|
|
1468 |
*/</font>
|
|
|
1469 |
Map<String,IPeer> getPeers();
|
|
|
1470 |
|
|
|
1471 |
<font color=#3F5FBF>/**
|
|
|
1472 |
* Redirect this service channel to given peer using this service as a proxy.
|
|
|
1473 |
*/</font>
|
|
|
1474 |
IToken redirect(String peer_id, DoneRedirect done);
|
|
|
1475 |
|
|
|
1476 |
<font color=#7F0055>interface</font> DoneRedirect {
|
|
|
1477 |
<font color=#7F0055>void</font> doneRedirect(IToken token, Exception error);
|
|
|
1478 |
}
|
|
|
1479 |
|
|
|
1480 |
<font color=#3F5FBF>/**
|
|
|
1481 |
* Call back after TCF messages sent to this target up to this moment are delivered.
|
|
|
1482 |
* This method is intended for synchronization of messages
|
|
|
1483 |
* across multiple channels.
|
|
|
1484 |
*
|
|
|
1485 |
* Note: Cross channel synchronization can reduce performance and throughput.
|
|
|
1486 |
* Most clients don't need channel synchronization and should not call this method.
|
|
|
1487 |
*
|
|
|
1488 |
* @param done will be executed by dispatch thread after communication
|
|
|
1489 |
* messages are delivered to corresponding targets.
|
|
|
1490 |
*
|
|
|
1491 |
* This is internal API, TCF clients should use {@code org.eclipse.tm.tcf.protocol.Protocol}.
|
|
|
1492 |
*/</font>
|
|
|
1493 |
IToken sync(DoneSync done);
|
|
|
1494 |
|
|
|
1495 |
<font color=#7F0055>interface</font> DoneSync {
|
|
|
1496 |
<font color=#7F0055>void</font> doneSync(IToken token);
|
|
|
1497 |
}
|
|
|
1498 |
|
|
|
1499 |
<font color=#3F5FBF>/**
|
|
|
1500 |
* Add a listener for locator service events.
|
|
|
1501 |
*/</font>
|
|
|
1502 |
<font color=#7F0055>void</font> addListener(Listener listener);
|
|
|
1503 |
|
|
|
1504 |
<font color=#3F5FBF>/**
|
|
|
1505 |
* Remove a listener for locator service events.
|
|
|
1506 |
*/</font>
|
|
|
1507 |
<font color=#7F0055>void</font> removeListener(Listener listener);
|
|
|
1508 |
|
|
|
1509 |
<font color=#7F0055>interface</font> Listener {
|
|
|
1510 |
<font color=#7F0055>void</font> peerAdded(IPeer peer);
|
|
|
1511 |
|
|
|
1512 |
<font color=#7F0055>void</font> peerRemoved(IPeer peer);
|
|
|
1513 |
|
|
|
1514 |
<font color=#7F0055>void</font> peerChanged(IPeer peer);
|
|
|
1515 |
}
|
|
|
1516 |
}
|
|
|
1517 |
</pre>
|
|
|
1518 |
|
|
|
1519 |
</body>
|
|
|
1520 |
</html>
|
|
|
1521 |
|