Home » Archived » Test and Performance Tools Platform (TPTP) » TPTP framework question
| |
| Re: TPTP framework question [message #67808 is a reply to message #67557] |
Mon, 24 April 2006 13:15   |
 strus
Messages: 113
Registered: July 2009 |
Senior Member |
|
|
Andy Kaylor wrote:
>>1) Defining our library as an agent for TPTP to retrieve our data from a
>>target host and display the result in our own perspective ?
>
>
> Yes, you should be able to use TPTP to do this very easily.
>
> I would suggest that you use the new Agent Controller as it has a nice
> framework for agent development that should be able to get you up and
> running quickly. We have some example client and agent code that does basic
> data transfer to help you get started.
>
>
>>2) Is it possible to use the 'Host' preferences to retrieve information on
>>a machine to be able to remotely run system commands on this machine, and
>>transfer result file from the target machine to the localhost ?
>
>
> I'm not sure I understand all the implications of this quesion. Using TPTP,
> you can start a remote process and get console output redirected to a local
> object for processing. You can also transfer remote files to the local
> system if you know their location.
This is exactly what I want.
>
>
>>3) Is the 'Host' clearly identify (OS, OS-VERSION, ...) or TPTP doesn't
>>need these informations ?
>
>
> Currently TPTP does not provide this information. We have an open feature
> request to develop an agent to return information about the remote system,
> but there are no concrete plans for when that will be developed.
>
So, which kind of connection is established between the remote client and
eclipse TPTP ?
>
>>4) Is it possible to extends the existing TPTP menus to add our own
>>actions ?
>
>
> Yes. A lot of the TPTP code is below the UI level, and the framework code
> is designed to be independent of the user interface. But if there are parts
> of the TPTP user interface that you would like to include in your RCP
> application, you will be able to customize them.
>
>
>>5) Is it possible to put the TPTP framework or just some part of it into
>>an stand-alone RCP application design only for performances analysis ?
>
>
> Yes. The TPTP runtime is broken down into several plugins. You should be
> able to choose the plugins you need and include them in your RCP app.
>
> -Andy
>
Thank you
Matthieu
>
|
|
|
| Re: TPTP framework question [message #67890 is a reply to message #67808] |
Mon, 24 April 2006 18:05 |
Randy D. Smith
Messages: 394
Registered: July 2009 |
Senior Member |
|
|
strus_fr wrote:
> Andy Kaylor wrote:
>>> 3) Is the 'Host' clearly identify (OS, OS-VERSION, ...) or TPTP
>>> doesn't need these informations ?
>>
>> Currently TPTP does not provide this information. We have an open
>> feature request to develop an agent to return information about the
>> remote system, but there are no concrete plans for when that will be
>> developed.
>
> So, which kind of connection is established between the remote client
> and eclipse TPTP ?
I'm getting confused here... reminds me of the early days of X11 when
"client" and "server" often seemed turned on their heads. The problem is
that I think most TPTP terminology turns on the client being the local
side of things (it's often the Eclipse workbench, but doesn't have to
be) and the "agent" being the remote thing that receives commands from
the client and returns data to the client (with either side of things,
sending commands or receiving data, being optional behavior).
So let me see if I can be clear on terminology while drawing you a
verbal picture, and then you can tell me how to translate betweeen our
terminologies.
On some local machine, as I said, you have a client. This wants to have
work done and receive data as a result. This side communicates to the
agent controller (AC, running on a remote system potentially, though it
also can run locally) through a normal socket (to port 10006 by default
for the "new technology AC"), which acts on its behalf. The AC can
launch processes (console processes, agents, etc.), and provides the
communication channel between the two (client and agent). The
communication channel is actually (potentially) many channels... a
command channel for issuing commands, and one or more data channels for
data communication between the two. E.g., for a "normal" (console)
process, you need three data channels... for stdin, stdout, and stderr.
The connection between AC and Agent is "wrapped up" in the API... you
really don't have to (and probably don't want to) know the details of
Socket/NamedPipe/SharedMemory usage...
(Note that whether these command and data channels are each physically
separate or physically the same but logically separate is just an
implementation issue, and potentially a configurable one.)
It sounds like you're looking at things more from the agents
perspective... if so, then try looking at it from this perspective... if
you have some kind of process that receives commands (in some form) and
generates data, you'll want to modify that process to become an agent in
the following way:
(1) when the process starts up, registerAgent with the AC to let it know
you exist, can accept connections, and do your work on some clients behalf,
(2) implement a processCommand that "receives commands" indirectly from
the client through the AC instead of directly from the client, ... more
or less just a "packaging" of your command handling, and
(3) implement sendData that provides the resulting information back to
the client.
I'm assuming in all this you're willing to use the new technology AC
framework, that your agent will extend an agent framework (like
BaseCollector), and thus you get a lot of the necessary scaffolding that
lets it be as simple as the 1..2..3.. above. Your agent will inherit a
multithreaded approach with at least the processCommands getting invoked
from one thread, and hopefully you driving the sendData from another,
with perhaps a third thread sitting in waitForTermination.
That's sort of the verbal picture... you can get a little bit of
concreteness around this by downloading the "new technology Agent
Controller SDK" and looking at the Samples included in it...
specifically ConsoleTestClient, SimpleAppl, SampleClient, and
TimeCollector. They might clear up any confusion the above creates in
your mind.
I also might recommend you look at the PerfmonAgent in the Samples... it
used to be an agent with the old AC (called the "RAC"... actually, it
still is an agent in its original form with the RAC distribution), and
it was modified to behave in just the 1..2..3.. form I describe above.
HTH,
--
RDS
Randy D. Smith randy (dot) d (dot) smith (at) intel (dot) com
Eclipse TPTP Committer, Platform Proj (data collection/agent controller)
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 13:51:17 GMT 2024
Powered by FUDForum. Page generated in 0.02244 seconds |
] 
Search
Help
Register
Login
Home
