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 14:09, 31 May 2010 by Michael Rennie.ca.ibm.com (Talk | contribs) (→‎setbreakpoint)

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:

  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 breakpoint request is sent from the client to the VM to ask for a specific breakpoint.

If communication is successful a corresponding breakpoint 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 the breakpoint request is: 

 

breakpoints

The breakpoints request is sent from the client to the VM to ask for all set breakpoints in a given context.

If communication is successful a corresponding breakpoints 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 the breakpoints request is: 

 

clearbreakpoint

The clearbreakpoint request is sent from the client to the VM to remove a specific breakpoint.

If communication is successful a corresponding clearbreakpoint 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 the clearbreakpoint 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":{}
}

context

The context request is sent from the client to the VM to ask for a specific context.

If communication is successful a corresponding context 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 the context request is: 

 

continue

The continue 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 corresponding continue 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 the continue request is: 

63
\r\n
{
  "command":"continue",
  "seq":32,
  "type":"request",
  "arguments":{}
}

dispose

The dispose request is sent from the client to the VM to shut down the VM.

If communication is successful a corresponding dispose 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 the dispose request is: 

 

evaluate

The evaluate request is sent from the client to the VM to evaluate a given script snippet.

If communication is successful a corresponding evaluate 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 the evaluate request is: 

 

frame

The frame request is sent from the client to the VM to ask for a specific stack frame.

If communication is successful a corresponding frame 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 the frame request is: 

 

frames

The frames request is sent from the client to the VM to ask for a list of stack frames.

If communication is successful a corresponding frames 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 the frames request is: 

 

lookup

The lookup 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 corresponding lookup 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 the lookup request is: 

 

script

The script request is sent from the client to the VM to look up a script with a given id.

If communication is successful a corresponding script 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 the script 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 setbreakpoint request is sent from the client to the VM to set a breakpoint at a given location.

If communication is successful a corresponding setbreakpoint 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 the setbreakpoint request is: 

 

suspend

The suspend 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 corresponding suspend 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 the suspend request is: 

 

thread

The thread request is sent from the client to the VM to look up a thread with a given id.

If communication is successful a corresponding thread 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 the thread request is: 

 

threads

The threads 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 corresponding threads 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 the threads 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

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

The continue response is sent from the VM to the client only if a continue 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 a dispose 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 a evaluate 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 a frame 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 a frames 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 a lookup 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 a script 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 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

The setbreakpoint response is sent from the VM to the client only if a setbreakpoint 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 a suspend 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 a thread 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 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"
         }
}
Retrieved from "https://wiki.eclipse.org/index.php?title=JSDT/Debug/Rhino/Rhino_Debug_Wire_Protocol&oldid=203353"

Back to the top