Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

JSDT/Debug/Rhino/Rhino Debug Wire Protocol

< JSDT‎ | Debug‎ | Rhino
Revision as of 13:32, 31 May 2010 by Michael Rennie.ca.ibm.com (Talk | contribs) (breakpoint)

JSDT Debug
Website
Download
Community
Mailing ListForumsIRCmattermost
Issues
OpenHelp WantedBug Day
Contribute
Browse SourceProject Set File

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:

  1. It can be more easily extended to add new events, requests or responses.
  2. It is easier to understand by consumers
  3. 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

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

breakpoints

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

clearbreakpoint

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

connect

The connect request is made from the client to the VM when an connection is desired.

If communication was successful a corresponding connect 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":{}
}

As long as the VM can be communicated with, a connect request will always result in a connect response packet being sent to the client.

context

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

continue

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

dispose

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

evaluate

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

frame

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

frames

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

lookup

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

script

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

scripts

The scripts 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 corresponding scripts 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

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

suspend

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

thread

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

threads

The request is sent from the client to the VM to .

If communication is successful a corresponding response is sent back from the VM.

The form of the packet is:

 
arguments
example

A real life example of the request is:

 

version

The version 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 corresponding version 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 the version 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 a breakpoint 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

clearbreakpoint

connect

The connect response is sent from the VM to the client only if a connect 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

dispose

evaluate

frame

frames

lookup

script

scripts

The scripts response is sent from the VM to the client and only if a scripts 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:

  1. 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

suspend

thread

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 a version 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:

  1. javascript.vm.version - the version of the VM running the interpreter
  2. javascript.vm.vendor - the vendor of the VM
  3. javascript.version - the version of the interpreter being used
  4. ecmascript.version - the ECMA version used in the VM
  5. 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"
         }
}

Back to the top