Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "JSDT/Debug/Rhino/Rhino Debug Wire Protocol"
(→connect) |
(→context) |
||
Line 204: | Line 204: | ||
'''arguments''' | '''arguments''' | ||
+ | |||
'''example''' | '''example''' | ||
+ | |||
A real life example of the <code>context</code> request is: <source lang="smalltalk"> | A real life example of the <code>context</code> request is: <source lang="smalltalk"> | ||
</source> | </source> | ||
− | </blockquote> | + | </blockquote> |
==== continue ==== | ==== continue ==== |
Revision as of 14:41, 31 May 2010
JSDT Debug | |
Website | |
Download | |
Community | |
Mailing List • Forums • IRC • mattermost | |
Issues | |
Open • Help Wanted • Bug Day | |
Contribute | |
Browse Source • Project Set File |
Contents
Overview
The Rhino Debug Wire Protocol (RDWP) is an adapted version of the v8 protocol using JSON to communicate with the remote Rhino debugger.
The RDWP was chosen to be JSON-based for a few reasons:
- It can be more easily extended to add new events, requests or responses.
- It is easier to understand by consumers
- It follows the de-facto JSON standard, which could allow it to communicate with other JSON-based efforts.
Packets
The RDWP performs all communication with the remote debugger using packets over a socket. The payload of each packet is the JSON string describing the event, request or response with a preamble containing the content length and a line terminator.
For example all packets follow the general form:
<content_length> \r\n\ { "type":<packet_type>, "seq":<packet_sequence>, "body":{} }
Event
Event packets are sent to the client from the VM only when the client as created an event request for a given event. Event packets are not broadcast to all clients, only those that have requested them.
All event packets have the general form:
<content_length> \r\n { "type":"event", "seq":<packet_sequence>, "event":<event_type>, "body":{} }
The complete list of events that can be used in <event_type>
are available in the Events section below
Request
A request packet is used to ask the VM to perform some operation. The compete listing of requests that can be made is available in the Request section below.
All request packets have the general form:
<content_length> \r\n { "command"=<command>, "type"="request", "seq"=<packet_sequence>, "arguments"={<argument_list>} }
A complete listing of requests that can be used in <command>
are available in the Requests section below.
Response
A response packet is sent by the VM an corresponds directly to a request packet that has been sent. Response packets are never sent if a request has not been made.
All response packets are of the form:
<content_length> \r\n { "command":<command>, "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }
A complete listing of responses that can be used in <command>
are available in the Responses section below.
Events
break
exception
script
thread
vmdeath
Requests
breakpoint
Thebreakpoint
request is sent from the client to the VM to ask for a specific breakpoint. If communication is successful a correspondingbreakpoint
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"breakpoint", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments
example
A real life example of thebreakpoint
request is:
breakpoints
Thebreakpoints
request is sent from the client to the VM to ask for all set breakpoints in a given context. If communication is successful a correspondingbreakpoints
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"breakpoints", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments
example
A real life example of thebreakpoints
request is:
clearbreakpoint
Theclearbreakpoint
request is sent from the client to the VM to remove a specific breakpoint. If communication is successful a correspondingclearbreakpoint
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"clearbreakpoint", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments
example
A real life example of theclearbreakpoint
request is:
connect
Theconnect
request is made from the client to the VM when an connection is desired. If communication was successful a correspondingconnect
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"connect", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments
This request takes no arguments, and any set arguments will be ignored by the VM.
example
A real life example of the
connect
request is:62 \r\n { "command":"connect", "type":"request", "seq":27, "arguments":{} }
context
Thecontext
request is sent from the client to the VM to ask for a specific context. If communication is successful a correspondingcontext
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"context", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments
example
A real life example of thecontext
request is:
continue
Thecontinue
request is sent from the client to the VM to indicate that the VM should continue execution. This request has no effect if the VM is not currently in a suspended state. If communication is successful a correspondingcontinue
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"continue", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments This request takes no arguments and any set arguments will be ignored by the VM.
example
A real life example of thecontinue
request is:63 \r\n { "command":"continue", "seq":32, "type":"request", "arguments":{} }
dispose
Thedispose
request is sent from the client to the VM to shut down the VM. If communication is successful a correspondingdispose
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"dispose", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of thedispose
request is:
evaluate
Theevaluate
request is sent from the client to the VM to evaluate a given script snippet. If communication is successful a correspondingevaluate
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"evaluate", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of theevaluate
request is:
frame
Theframe
request is sent from the client to the VM to ask for a specific stack frame. If communication is successful a correspondingframe
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"frame", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of theframe
request is:
frames
Theframes
request is sent from the client to the VM to ask for a list of stack frames. If communication is successful a correspondingframes
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"frames", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of theframes
request is:
lookup
Thelookup
request is sent from the client to the VM to look up a given id - which could be any valid element id (frame id, script id, etc). If communication is successful a correspondinglookup
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"lookup", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of thelookup
request is:
script
Thescript
request is sent from the client to the VM to look up a script with a given id. If communication is successful a correspondingscript
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"script", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of thescript
request is:
scripts
Thescripts
request is sent from the client to the VM and, if successful, will return the complete listing of scripts loaded in the VM. If communication was successful a correspondingscripts
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"scripts", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments This request takes no arguments, and any set arguments will be ignored by the VM.
example A real life example of the
scripts
request:62 \r\n { "command":"scripts", "type":"request", "seq":28, "arguments":{} }
setbreakpoint
Thesetbreakpoint
request is sent from the client to the VM to set a breakpoint at a given location. If communication is successful a correspondingsetbreakpoint
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"setbreakpoint", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of thesetbreakpoint
request is:
suspend
Thesuspend
request is sent from the client to the VM to suspend execution of the given thread (or the entire VM). The request has no effect if the thread (or VM) is not in a running state. If communication is successful a correspondingsuspend
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"suspend", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of thesuspend
request is:
thread
Thethread
request is sent from the client to the VM to look up a thread with a given id. If communication is successful a correspondingthread
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"thread", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of thethread
request is:
threads
Thethreads
request is sent from the client to the VM to ask for all threads that currently exist in the VM. If communication is successful a correspondingthreads
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"threads", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments example
A real life example of thethreads
request is:
version
Theversion
request is sent from the client to the VM to ask what version of the Rhino debugger you are communicating with. If communication was successful a correspondingversion
response is sent back from the VM. The form of the packet is:<content_length> \r\n { "command":"version", "type":"request", "seq":<packet_sequence>, "arguments":{} }arguments
This request takes no arguments, and any set arguments will be ignored by the VM.
example
A real life example of theversion
request is:62 \r\n { "command":"version", "seq":29, "type":"request", "arguments":{} }
Responses
breakpoint
The
breakpoint
response is sent from the VM to the client only if abreakpoint
request has been made.The form of the packet is:
<content_length> \r\n { "command":"breakpoint", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
breakpoint
response is:
breakpoints
The
breakpoints
response is sent from the VM to the client only if abreakpoints
request has been made.The form of the packet is:
<content_length> \r\n { "command":"breakpoints", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
breakpoints
response is:
clearbreakpoint
The
clearbreakpoint
response is sent from the VM to the client only if aclearbreakpoint
request has been made.The form of the packet is:
<content_length> \r\n { "command":"clearbreakpoint", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
clearbreakpoint
response is:
connect
The
connect
response is sent from the VM to the client only if aconnect
request has been made.The form of the packet is:
<content_length> \r\n { "command":"connect", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
The body of the response is empty.
example
A real life example of a
connect
response is:105 \r\n { "command":"connect", "type":"response", "request_seq":27, "seq":37, "running":true, "success":true, "body":{} }
continue
The
continue
response is sent from the VM to the client only if acontinue
request has been made.The form of the packet is:
<content_length> \r\n { "command":"continue", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
continue
response is:
dispose
The
dispose
response is sent from the VM to the client only if adispose
request has been made.The form of the packet is:
<content_length> \r\n { "command":"dispose", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
dispose
response is:
evaluate
The
evaluate
response is sent from the VM to the client only if aevaluate
request has been made.The form of the packet is:
<content_length> \r\n { "command":"evaluate", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
evaluate
response is:
frame
The
frame
response is sent from the VM to the client only if aframe
request has been made.The form of the packet is:
<content_length> \r\n { "command":"frame", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
frame
response is:
frames
The
frames
response is sent from the VM to the client only if aframes
request has been made.The form of the packet is:
<content_length> \r\n { "command":"frames", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
frames
response is:
lookup
The
lookup
response is sent from the VM to the client only if alookup
request has been made.The form of the packet is:
<content_length> \r\n { "command":"lookup", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
lookup
response is:
script
The
script
response is sent from the VM to the client only if ascript
request has been made.The form of the packet is:
<content_length> \r\n { "command":"script", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
script
response is:
scripts
The
scripts
response is sent from the VM to the client and only if ascripts
request has been made.The form of the packet is:
<content_length> \r\n { "command":"scripts", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{"scripts":<script_id_list>}}body
If the request is successful, the response body will contain a single element:
- scripts
- the complete listing of the ids of all of the scripts loaded in the VM.
These ids are unique for each script that is loaded in the VM and can be used to subsequently look up a script in the VM. A script id is guaranteed to be unique during the lifecycle of the VM - if the VM is restarted any held script ids cannot be guaranteed to be unique.
example
A real life example of the
scripts
response is:120 \r\n { "command":"scripts", "type":"response", "request_seq":28, "seq":38, "running":true, "success":true, "body":{"scripts":[1,0]}}
setbreakpoint
The
setbreakpoint
response is sent from the VM to the client only if asetbreakpoint
request has been made.The form of the packet is:
<content_length> \r\n { "command":"setbreakpoint", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
setbreakpoint
response is:
suspend
The
suspend
response is sent from the VM to the client only if asuspend
request has been made.The form of the packet is:
<content_length> \r\n { "command":"suspend", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
suspend
response is:
thread
The
thread
response is sent from the VM to the client only if athread
request has been made.The form of the packet is:
<content_length> \r\n { "command":"thread", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":<is_running>, "success":<success_status>, "body":{} }body
example
A real life example of a
thread
response is:
threads
118 \r\n {"command":"threads","type":"response","request_seq":31,"seq":41,"running":true,"success":true,"body":{"threads":[1]}}118 \r\n {"command":"threads","type":"response","request_seq":31,"seq":41,"running":true,"success":true,"body":{"threads":[1]}}
version
The
version
response is sent from the VM to the client and only if aversion
request has been made.The packet form is:
<content_length> \r\n { "command":"version", "type":"response", "request_seq":<request_sequence>, "seq":<packet_sequence>, "running":true, "success":true, "body":{<version_elements>}}body
If the request is successful, the body of the response will contain five elements with version information:
- javascript.vm.version
- the version of the VM running the interpreter
- javascript.vm.vendor
- the vendor of the VM
- javascript.version
- the version of the interpreter being used
- ecmascript.version
- the ECMA version used in the VM
- javascript.vm.name
- the human-readable name of the VM
example
A real life example of the
version
response is:248 \r\n { "command":"version", "type":"response", "request_seq":29, "seq":39, "running":true, "success":true, "body":{ "javascript.vm.version":"1.6", "javascript.vm.vendor":"Mozilla", "javascript.version":"1.6", "ecmascript.version":"3", "javascript.vm.name":"Rhino" } }