|
1 | | -qdb |
2 | | -=== |
| 1 | +# qdb # |
3 | 2 |
|
4 | 3 | Quantopian Remote Debugger for Python |
| 4 | + |
| 5 | + |
| 6 | +### Overview ### |
| 7 | + |
| 8 | +qdb is a debugger for python that allows users to debug code executing |
| 9 | +on remote machine. qdb is split into three main components that may all be |
| 10 | +running on seperate hardware: |
| 11 | + |
| 12 | +- The client |
| 13 | +- The tracer |
| 14 | +- The server |
| 15 | + |
| 16 | +The client is the user's interface to the debugger. All communication here is |
| 17 | +through a websocket connected to the server. This client could be any type |
| 18 | +of application. qdb provides a terminal client and emacs mode for this. |
| 19 | + |
| 20 | + |
| 21 | +The tracer is the main debugging process. This is the actual code that the user |
| 22 | +wishes to debug. Communication here is through a socket sending pickle'd |
| 23 | +dictionaries representing only the valid json messages sent to the server from |
| 24 | +the client. A single tracer may have multiple clients connected to it. |
| 25 | + |
| 26 | + |
| 27 | +The server is the main routing station for messages between the clients and the |
| 28 | +tracer. The server is responsible for validating that the messages from the |
| 29 | +clients are well formed and routing them to the tracer. A single server may |
| 30 | +manage multiple tracers, so it is responsible for making sure that connections |
| 31 | +are routed to the proper place. The server can clean up tracer processes whos |
| 32 | +clients have become inactive if the server manager decides. |
| 33 | + |
| 34 | + |
| 35 | + |
| 36 | +### json protocol ### |
| 37 | + |
| 38 | +All communication to the server is through a structured protocol of the form: |
| 39 | + |
| 40 | + { |
| 41 | + "e": event, |
| 42 | + "p": payload |
| 43 | + } |
| 44 | + |
| 45 | +The event is the type of the message, and the payload is any parameter or data |
| 46 | +that is associated with this packet. Not all messages require a payload. |
| 47 | +For example, the client can send the command: |
| 48 | + |
| 49 | + { |
| 50 | + "e": "step" |
| 51 | + } |
| 52 | + |
| 53 | +Which steps into the next expression on the tracer. The client may also send: |
| 54 | + |
| 55 | + { |
| 56 | + "e": "eval" |
| 57 | + "p": "a + b" |
| 58 | + } |
| 59 | + |
| 60 | +This command is equivelent to evaluating the code `a + b` in the current stack |
| 61 | +frame. |
| 62 | + |
| 63 | +The server will always send back data that is formatted in this way. |
| 64 | + |
| 65 | + |
| 66 | +### Modularity ### |
| 67 | + |
| 68 | +qdb is designed with modularity in mind. For this reason, many components of the |
| 69 | +qdb system may be swapped out with user defined alternatives to help blend qdb |
| 70 | +into larger projects. For example, the qdb server can have the websocket server |
| 71 | +swapped out to make it work as a route point in a larger flask project. |
| 72 | + |
| 73 | +While qdb provides a minimal client, the beauty in the websocket / json |
| 74 | +combination is that it allows users to plug in their own client, so long as |
| 75 | +it can make the connection and interpret the commands. |
| 76 | + |
| 77 | + |
| 78 | + |
| 79 | +### Security ### |
| 80 | + |
| 81 | +qdb provides multiple features that are security oriented. Because it is a |
| 82 | +remote debugger, the owner of the hardware running the tracer or server may |
| 83 | +not want the user to do things. For example, the the server may define an |
| 84 | +authentication function that reads the authentication message out of the |
| 85 | +start command and either accepts or denies that websocket. Also, the tracer |
| 86 | +may define their own eval function to use when evaluating repl code or the |
| 87 | +condition of conditional breakpoints. This lets the tracer deny potentially |
| 88 | +dangerous code if it so wishes. |
0 commit comments