MAIN DEBUG MODEINITIALIZATION
When the debugger accepts a connection, the first task is to initialize the debug session. Both sides communicate their application name and which ScriptEase debug version they expect. If the application is password-protected, the debugger provides the password. Either side, the debugger or the application, has opportunities to terminate the connection for a number of reasons.
The application begins by identifying itself:
SCRIPTEASE DEBUG version application-identifier
For instance:
SCRIPTEASE DEBUG 1.0 Sewse
The version cannot have spaces in it. Whatever text is provided is split by the first whitespace character into the version and the application identifier. Also note that TCP-IP provides the IP address of the connecting application. The application already knows the IP address of the debugger else it would not have been able to establish the connection in the first place. IP addresses are important as they allow both sides to know if a remote debugging session is taking place. The debugger should generally allow all local debugging sessions to take place but will probably want to query its user if a remote debugging session should be allowed.
In the case of a local debugging session, filenames sent by the application will be the same filenames the debugger should display. However, for remote applications the filenames will not match. In a remote debugging session, it is erronous to display files of the given names even if they exist with the given name on the local machine: the contents of those files may be different on the remote machine. For each new filename, the debugger should use the SEND FILE command (described below) to get the contents of the file and make a local copy of that file. The local copy will be stored in a temporary location to be deleted when the session is complete. The debugger will translate filename references to the local copies. In the case of local files that the debugger cannot locate, the same mechanism should still be applied.
The debugger's response to the application is a line of the same format as the application's, with the debugger's identifier string in place of the application's. The version must match exactly, to verify the debugger understands the version. However, if the debugger does not accept the debug session, it instead denies the debug session with the following command:
DENIED text message indicating reason for denial
Some examples include:
DENIED Too many active debug sessions currently.
DENIED Version 1.0 is not understood.
DENIED 200.0.1.6 is a known hacker site.
DENIED This debugger is JoeBob's Super App-specific.
DENIED User denied this request.
The application has three possible responses to an accepted connection by the server. It can deny the connection itself in the same way the server can. It can accept the connection by:
DEBUG BEGUN
In this case, the debug connection goes into the main debug mode described below. Finally, the application can ask the server for a password:
SEND PASSWORD
The debugger responds with:
PASSWORD password
The application can respond with another PASSWORD message if the password was incorrect. If the password is missed three times, the application will give a DENIED. Once the password is accepted, the application uses DEBUG BEGUN to enter the main debug mode.