GNTicker Trace Protocol

GNTicker Trace Protocol (GNTP) is designed to allow two-way communication between the GNTicker server (TS) and its clients. The main tasks which can be accomplished using GNTP are:
 * Sending a generalized net definition to the TS
 * Receiving events for token movement, entrance, leaving or merging from the TS
 * Performing a number of steps of the GN execution
 * Executing the GN until a specific event occurs, with an upper bound of the number of steps
 * Providing client-initiated (active) input in the form of a token, which can be placed in a fixed input place of the GN
 * Providing server-initiated (passive) input in the form of a string or double value with a query string
 * Client or server initiated halting of the execution
 * Error reporting from the TS on all requests

General principles
GNTP uses the design of the Hypertext Transfer Protocol for the presentation layer and XML for the application layer. GNTP messages are requests (issued by the client) and responses (issued by the server). Each message consists of the message preamble (protocol version and method name or response code), optional message headers and message body. The message body, if non-empty, is usually an XML document. The namespace used by the XML documents is the GN definitions namespace:  http://www.clbme.bas.bg/GN , which is defined in the following XML schema.

A request to the TS should be formed according to the following template:  ::=	GNTP/\r\n  \r\n ( \r\n)* \r\n 

 ::=	.

 ::=	 | 

 ::=	 |  



The GNTP headers will be presented in Headers. The method syntax will be presented in Methods. A response from the TS should be formed according to the following template:

<GNTP-response> ::= GNTP/<protocol-version>\r\n <response-code> <response-details>\r\n ( \r\n)* \r\n <response-body>

<response-code> ::= <response-class><response-type>

<response-class> ::=	<decimal-digit>

<response-type> ::=	<decimal-digit><decimal-digit>

<response-details> ::=	<ANSI-string>

The response codes and details will be presented in Response codes.

Content-Length

 * Syntax


 * Description
 * Specifies the size of the message body in bytes. This header SHOULD be used in requests and responses every time, when the message body is nonempty.


 * Example

Content-Type

 * Syntax


 * Description
 * Specifies the media type (MIME type) of the message body. This header is optional, if not specified "text/xml" type is presumed by default.
 * Note: only XML messages are supported up to now.


 * Example

INIT
INIT
 * Syntax


 * Description
 * The <tt>INIT</tt> method should be the first method, which a client should use. A client should use the <tt>INIT</tt> method to send a GN definition to the server. Only one <tt>INIT</tt> method should be sent to the server by the client. Each new GN execution requires a new connection to the server. The message body is an XML definition of a generalized net starting with a <tt><gn></tt> element and conforming to GNschema.xsd.


 * Example


 * Comment
 * A minimal GN is loaded in the server.

HALT
HALT
 * Syntax


 * Description
 * Clients should use the <tt>HALT</tt> method to initiate halt of the GN execution. The client has to wait for the server to respond and close the connection. The <tt>HALT</tt> method should be used only after an <tt>INIT</tt> method. The <tt>HALT</tt> method does not require a message body.


 * Example


 * Comment
 * The current GN execution is halted and the memory for the GN is freed.

STEP
STEP [<number-of-steps>] <number-of-steps> ::=	<decimal-number>
 * Syntax


 * Description
 * Clients should use <tt>STEP</tt> in order to execute a number of GN steps of a previously loaded GN. If the parameter is omitted, a default value of 1 is presumed by default. If all the steps are executed correctly, the server responds with an XML document, describing all events in the GN during these steps. The <tt>STEP</tt> method does not require a message body.


 * Example


 * Comment
 * The loaded GN is executed for ten steps and events are returned in response.

STEPUNTIL
STEPUNTIL <event-name> <number-of-steps> [<token-ids>]
 * Syntax

<event-name> ::=	ENTRANCE|MOVEMENT|EXIT|MERGE

<number-of-steps> ::=	<decimal-number>

<token-ids> ::=		<token-id>|<token-id> <token-ids>

<token-id> ::=


 * Description
 * Executes a GN until a step, where a specific token event occurs. Events are correspondingly entrance of a token, movement of a token, exit of a token or merging of a token. Note that the whole last step is performed, i.e. execution is not stopped immediately when the event occurs but only after the step is completed. The <tt><number-of-steps></tt> specifies the maximum number steps which are performed, while waiting for the event. It is a required argument to avoid infinite cycles. If a list of token IDs is specified, then only the token with IDs in the list are monitored for the selected event. The <tt>STEPUNTIL</tt> method has to be executed after an INIT method. The <tt>STEPUNTIL</tt> method does not require a message body.


 * Example


 * Comment
 * The GN is executed until at least one of the tokens <tt>MessageToken</tt> or <tt>ErrorToken</tt> leaves the GN, or until 100 steps are completed.

TOKENS
TOKENS
 * Syntax


 * Description
 * Clients should use the <tt>TOKENS</tt> method to insert tokens in the GN in the time of execution. Therefore, the <tt>TOKENS</tt> method should be used for active input in the GN. This method requires an XML message body with a element, as described in GNschema.xsd. The <tt>TOKENS</tt> method can be executed only after the <tt>INIT</tt> method.


 * Example


 * Comment
 * In this example the client requests to insert a token with ID "PriceToken" into the place with ID "L1". The token has two characteristics - a string characteristic "Product" with value "PS/2 mouse" and a double characteristic "Price" with value 3.50.

INPUT
INPUT [<number-of-inputs>]
 * Syntax

<number-of-inputs> ::= <decimal-number>


 * Description
 * The INPUT method should be used by the client when the last response by the TS requires input. Therefore, the INPUT method provides passive input in the GN. The TS initiates passive input with a Class 3 response code. The response body of a Class 3 response is an XML with an <input-request> element, containing elements, conforming to GNschema.xsd. This body should be used as a template by the client and filled with client-provided data. The difference is that the result should be enclosed in an <input-response> element.
 * The INPUT method should be executed only immediately after a Class 3 response; it is also the only allowed method after such a response code. As with all other methods, INPUT has to be executed only after the INIT method.


 * Example


 * Comment
 * A client responds to a server Class 3 response code, which required two values: a string value with a query string "Product" and a double value with a query string "Price".

SAVE
SAVE
 * Syntax


 * Description
 * The SAVE method should be used by the client to receive the current state of the GN. The server responds with a GN definition conforming to GNschema.xsd. If the GN model has already performed a number of steps, the current time of the GN is indicated by the time attribue in the <gn> tag.
 * As with all other methods, SAVE has to be executed only after an INIT method and when the previous respose code was Class 2.

Client:
 * Example

Server:


 * Comment
 * A client queries the server for the current state of the GN model being executed. The server responds with a Class 2 success code and a GN, which has been executed for 10 steps.

Response codes
Response codes are used to help clients quickly identify the TS response. Most responses include a response body with XML containing details about the response. The root element of the XML document depends on the class of the response code. Below the response codes are listed by class.

Class 1 - Invalid request
Class 1 response codes are presentation level errors. They are issued by the TS if a server cannot understand the client request. The TS should not close the connection after Class 1 response codes. The response body of a Class 1 response is an XML document with an <tt><request-error></tt> element, conforming to GNschema.xsd.

Class 2 - Successfully completed request
Class 2 response codes are sent by the TS if the request has been successfully completed. The message body of a Class 2 response is an XML document with an element, conforming to GNschema.xsd.

Client:
 * Example

Server:


 * Comment
 * The TS has executed steps from 0 to 9 inclusive. On step 2 the "Product" token has entered place "L1" with the specified characteristics. On step 3 the "Client1" has moved to place "L2" and token "Client2" has left the GN through place "L5".

Class 3 - More information needed
Class 3 responses are sent by the TS when the execution of the GN requires additional input. In this case the TS sends as a response body an XML document with an <tt><input-request></tt> element, conforming to GNschema.xsd.

Client:
 * Example

Server:


 * Comment
 * The TS queries the client for two values: a string value with a query string "Product" and a double value with a query string "Price". An <tt>INPUT</tt> method, which is executed by the client in response to this request can be found in here.

Class 4 - Message body errors
Class 4 response codes are returned by the TS if an XML message body is not correct. An <tt><xml-errors></tt> element conforming to GNschema.xsd is returned as the response body containing details about the error. The TS should not close the connection after a Class 4 response code.

Client:
 * Example 1

Server:


 * Comment to Example 1
 * The XML element <tt> </tt> does not have a closing tag, so the server reports XML errors.

Client:
 * Example 2

Server:


 * Comment to Example 2
 * The XML element <tt> </tt> does not have an id attribute, which is required in GNschema.xsd.

Class 5 - GNTicker interpreter errors
Class 5 response codes are sent by the TS on behalf of the GNTicker interpreter whenever there are errors in the GN definition or run-time errors. Note: most of the GN definition errors are reported as response code 401 as they can be detected via validation against GNschema.xsd. Class 5 responses cover GN definition semantic errors, which are not straightforward to detect. The response body contains XML with a <tt><gnticker-errors></tt> element conforming to GNschema.xsd. After sending any Class 5 response code, the TS closes the connection.