|
If you’re going to connect to a new
AC using the XML-format protocol you’re going to have to do it from a new
client. The workbench doesn’t “talk” the new protocol…
yet. Rather than make the workbench talk the
new protocol on the 4.2 timeframe, we chose to instead make the new AC talk the
old protocol… so that you’ll find that if you talk to the new AC on
port 10002, it can be talked to using the old protocol (via a backward
compatibility [BC] layer). It still is able to talk new protocol on 10006 at
the same time … but there are no clients other than the samples that “speak
that language” up until now. For 4.1 there *was* a “migrated” PerfmonAgent that talked the new
protocol via port 10006, but in the 4.1-to-4.2 timeframe, that migrated agent
stopped working as the implementation it depended on (primarily in the
workbench/client side) changed out from under it. And I might as well answer what I know to
be the obvious question… So why would we use our 4.2 resources to make
the new AC talk old protocol instead of make the workbench talk the new
protocol? Because it was believed that the bulk of the existing
client/infrastructure/consuming-products that talked the old protocol were of
greater importance to keep working with less effort via our AC/BC effort than
could be achieved by trying to get them all to “upgrade” …
particularly as the new AC didn’t (and still doesn’t) cover as many
platforms as the older RAC does. I’m sure no one would object to
someone contributing the changes necessary to get the workbench talking the new
protocol… presuming someone was so inclined. J However, I’m sure
it would need to be done in such a way as to be easily “switchable”
between the two protocols for the foreseeable future … there’s just
so much inertia brought into the picture by those consuming products. -- RDS From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nidumolu, Hari Hi, I want to run a new agent controller ( 4.2 version
ACServer) on a remote windows machine and connect to it. I want to see the
new agent controller communicate using protocol described in http://www.eclipse.org/tptp/platform/documents/newtechAC/C++API/TPTP%20Data%20Collection%20Subsytem%20External%20Spec.html. For example: <Cmd dest=”100”
src="" ctxt="10001"> My host is a Win XP machine and my target a Win2k machine
both of them have the agntctrl.win_ia32-TPTP-4.2.0.2.zip installed. My
serviceconfig.xml is default with one difference <Allow host="ALL" /> I have seen data, in this format, being exchanged between
a new agent controller (running remotely) and the sample clients in the
TPTP SDK. For example using the ConsoleTestClient. I could not setup any TPTP profile launch configuration that
sends XML based commands to a remote agent controller. What ever I do in
the profiling and logging perspective connecting to a remote agent controller,
I see data sent as per the non-xml based commands. For example: 1) I created a new profile launch configuration under
"Attach- Java Process". 2) In the Hosts tab, I added a new host
192.216.227.100 port 10006, I selected the newly added host. 3) In the Agents tab, I clicked on the "Refresh
Data" button. I expected the data to be sent in the format of "<Cmd src="" dest=\"%d\"
ctxt=\"%d\"><queryRunningAgents
iid=\"org.eclipse.tptp.agentManager\"><processID>lu</processID></queryRunningAgents></Cmd>"; But I saw the binary command RA_QUERY_PROCESS_LIST (0x11)
being sent. My questions: *) How do I set up my Workbench (Agent controller
preferences or Profile configuration) or my Windows environment to
communicate with a remote agent controller using the XML based
command protocol? Let me know if I am doing something wrong. Thank you, -Hari Nidumolu Wind River Systems, Inc. |
_______________________________________________ tptp-tracing-profiling-tools-dev mailing list tptp-tracing-profiling-tools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/tptp-tracing-profiling-tools-dev
