A Community Service
outside of the AxleBase presentation.

( Please forgive the year-long break in service due to redesign and rebuild of this site. The protocol was inside the documentation, which has been removed to slow intellectual property theft, and the protocol is just now being republished on its own page. It is the same protocol with upgrades. )

I do attest that this protocol is entirely my intellectual property. I do hereby offer this protocol as a gift for public use free and clear of copyright and without reservation, requirement, or encumberance of any kind so that it may be used, copied, and distributed by anyone and by everyone and for any purpose with the following exclusions and exceptions.

Specificity :
      The gift of this protocol is specific and does not include any other intellectual property. I do retain the copyright to all else unless specifically and explicitly stated otherwise. This gift does not in any way involve, include, or refer to AxleBase or to any other intellectual work.

Exclusion :
      The SysLink name as a communication protocol is not included in this release, but the name may be freely used for, with, and in reference to this protocol.

Exclusion :
      This release does not include the right to develop or alter the protocol. ( The developer invites requests and suggestions. )

Exclusion :
      Protocol development will not be bound by this release. The protocol is subject to change at any time.

John E. Ragan

SysLink is an application-level communication protocol. It is designed for communication control and to increase communication security.

The SysLink protocol is intended to set at the top of the network stack. To facilitate development and debugging in this complex profession, it is designed for human readability as well as for machine use. Human readability is specified as part of the protocol. Because it is for machine use, the command strings must be precisely stated.

Syslink was developed to support the operation of the AxleBase database manager, expecially in his distributed form, but is published as a general purpose protocol.

Comments and suggestions concerning this protocol are welcome.

Identifier : 20116
      Added an error type to the error handler.
      Clarified the server envelope.
      Expanded the authentication request.
      ( Without changing the existing request. )

Previous Release : 11118
      Replaced missing identifier pound sign in footer.
      Enhanced and clarified various definitions.

Previous Release : 11101
      A major upgrade. Restructured and expanded the envelope header. Added new commands. Added error handling.

Previous Release: 91101

Release Definition :
      A release denotes a published change in the protocol state.
      The release number identifies the current release of the protocol. Release numbers are sequential, but not necessarily consecutive. Although they are derived from dates, they do not necessarily reflect the date of the release. Release number 70203 may or may not have been published on 2007020300000000, but upon publication, that date most appropriately suggested the number.

The SysLink protocol governs communications at the application level. Levels below that, such as TCP/IP are expected to be governed by their own protocols which will not impinge upon the SysLink level. The involved apps will open, manage, and close the SysLink communication session.

A communication session within protocol is defined by its character. It consists of :
      multiple transmissions
      that are recognizable by both the sender and the receiver,
      which are the session interlocutors.

The reality and state of a communication session are independent of the state of the infrastructure and may be known only to the interlocutors. The nature and state of the infrastructure may change to any degree in any dimension without altering the session.

A session includes :
      A transmission that is identifiable as the opening transmission.
      A transmission that is identifiable as the closing transmission.
      And all transmissions between them.

A session may have an identifier that is shared by the interlocutors.

A session remains open until it is explicitly closed. Closure can be a unilateral notice or may be negotiated. Closure occurs for an interlocutor when notice is sent or received.

If the remote interlocutor fails to respond, then the local may unilaterally elect to close the session. Failure to respond may be a single check or may be negotiated. Closure in any case will be made explicit by a closure transmission regardless of the states of infrastructure and interlocutors.

Server timeouts are permitted. However, the server must send a closure notice.

There is no transmission outside of a session. Opener and closure transmissions are part of a session if the opener was successful.

Literal string specifications cannot be altered or translated and no substitution will be made.

The header, footer, and literals will not be altered, abbreviated, compressed, translated, or encrypted except when the entire transmission is compressed and(or) encrypted.

Contents of the header, footer, and literals are in English. Other special characters found on the American keyboard are permitted except where otherwise specified.

Only those control characters that are specified by the protocol are permitted in the header, footer, and literals.

( The following is being considered to enhance universalization.
      Where counts are specified, the character count will also be the byte count so that readings of a transmission by machines and humans are unambiguous.
      Unicode is not permitted in the header, footer, or literals.)

All messages are enclosed within the Syslink envelope. The envelope consists of a header and a footer.

The transmission envelope header contains twenty elements of variable lengths. The elements are each terminated by ASCII characters 13 and 10. That character string may not appear elsewhere in the header except within the authentication. The elements that are marked with asterisks must contain the specified data.

Permitted Characters :
      Characters in the envelope are controlled.
      The authentication element may contain any characters.
      Only the specified control characters are permitted.
      See the Universalization section specifications.

The footer has three elements that are each terminated by ASCII characters 13 and 10.

- 1   The ASCII character 127 is the first character in the footer.
- 2   Header and footer envelope identifiers must be identical.
- 3   The last element contains the thirty character literal string
            ** stop syslink transmission**
It and the element terminators terminate the transmission.

Errors

Error List :
      001   A header without a footer.
      002   A footer without a header.
      003   The header is not properly constructed.
      004   The footer is not properly constructed.
      005   Envelope contains no transmission.
      006   Header and footer message identifiers do not match.
      007   Other protocol non-compliance.
      008   Requested release number not supported.
      009   Invalid or unrecognized control string.
      ( Invalid authentication is being considered.)
      ( Invalid encryption response is being considered.)

Action :
      Transmission will be discarded.
      Response is discretionary.

See the error notification control string below.

Compounded Encryption

The protocol does not deny compounded encryption.

The message may be incrypted, placed in an envelope, and then the entire envelope may be encrypted before transmitting. The respondent would decrypt the transmission and then decrypt the enclosed message.

The following command and control strings are part of the protocol. Additional command strings are not disallowed, but only those listed below are part of the protocol.

An envelope that contains a command will contain only that command.

To facilitate development and debugging, the command and control strings are designed for human readability as well as for machine use.

Commands are precisely 30 characters. Where a command or response requires parameters, the control string is immediately followed by parameter brackets. The left bracket is a right pointer (>) and the right bracket is a left pointer (<). The parameters are placed within the brackets; e.g., >parameter<.

Command and control strings are case-sensitive literals. Each of them includes two asterisks at each end. Spaces within the strings are specific.

Specific Exclusion :
      The command strings do not include the numbers that are shown in the lists. Those numbers are only to ease comprehension, administration, and development by humans and may change without notice.

The header and footer strings are included in the following list only for clarity. The other control strings are placed inside the envelope.

Currently recognized control strings:

        001 ** open syslink transmission**
        002 ** stop syslink transmission**
        003 ** open new syslink session **
        004 **break our comm connections**
        005 **reverse connection to port**
        006 **syslink session identifier**
        007 ** execute local app command**
        008 ** resend lost transmission **
        009 **syslink error notification**
        010 
        011 ** information return query **
        012 ** information query return **
        013 ** identification requested **
        014 **identification is enclosed**
        015 **comm check please respond **
        016 **comm check 30 chr response**
        017 **authenticate**authenticate**
        018 ** authentication enclosed  **
        019 ** encryption specification **
        020 ** initialize app or system **
        021 **stop now. unload now. die.**
        022 ** transmissions size limit **
        023 ** denial of a transmission **
        024 ** operation status follows **
        025 
        026 
        027 
        028 
        029 
        030 ** * server return begin. * **
        031 ** * server return cease. * **

Command : 001 ** open syslink transmission**

This string is used only within the envelope header at the beginning of a transmission to declare the beginning of a single continuous transmission. (Note the difference between a transmission and a session.)

Command : 002 ** stop syslink transmission**

Used only within an envelope footer at the end of a transmission.

Command : 003 ** open new syslink session **

The protocol requires that the involved apps open the communication session. It may be opened either by this command or by the "reverse connection" command. If this command is used, then the "reverse connection" command may also be sent subsequently.

A response is not required. The sender will expect one of four possible results:
      No response, which may infer nothing.
      Acceptance.
      Rejection.
      Challenge.

Responses may take any form. For example, the challenge might be a demand for authentication.

The receipt of an error notice in response to this transmission should be recognized as a refusal. However, the recipient should terminate the session for clarity.

Command : 004 **break our comm connections**

This string is sent to advise the interlocutor of the cessation of communication. When that string is sent or received, the system is expected to immediately initialize communications without response or notice.

Sending this command ends the communication session.

The inclusion of the datetime in the envelope header is strongly recommended. It should be noted that transmissions may be delayed by activity in the recipient or by the infrastructure even when the infrastructure appears healthy.

( Under consideration is the possibility of an authentication demand.)

Command : 005 **reverse connection to port**

After the client connects to the server, the server will expect to transmit to the same port number on the client. This command may be used by the client to tell the server to use a different port number for transmissions to the client.

If this command is used, then both connections will be used for the duration of the session.

The request for a reverse connection is in the following format:
      **reverse connection to port**>specification<
The specification is the port number enclosed by the pointers.

If the session has not been opened and established, then the establishment of a reverse connection will be construed as an accptance of the request for a SysLink session.

The receipt of an error notice in response to this transmission should be recognized as a refusal. However, the recipient should terminate the session for clarity.

Command : 006 **syslink session identifier**

If this command is sent by either party, then the enclosed value will become the identifier of the current SysLink session until session termination. The session identifier will be included in the header of every transmission.

Transmission of this command will constitute acceptance of a session request.

The server is expected to specify the session after a request from a client. If the command is both transmitted and received by one of the interlocutors, then the command has been duplicated with concommitant confusion of both interlocutors. The session must be terminated because one or both cannot comply with the protocol. (However, the protocol does not disallow negotiation.)

The complete command is in the form :
          **syslink session identifier**>specification<
where specification is the session identifier which is enclosed by the pointers. The identifier is case-sensitive.

Command : 007 ** execute local app command**

This permits commands outside the protocol to be sent to a system for execution. The receiver is expected to extract the command and pass it to the desired target.

Examples :
      It could be a command to reboot the computer, a command to unload or restart a database manager, or any other command that may be recognized and executed.

The command and its parameters are placed in the following data structure which has nine elements.
      1. The 30 chr command: ** execute local app command**
      2. A right pointer.
      3. The name of the target app.
      4. A vertical bar. (Called a pipe by old Unix hands.)
      5. The command.
      6. A vertical bar.
      7. The parameters for the command.
      8. A vertical bar.
      9. A left pointer.

There is no further specification of the contents of the structure elements after the right pointer.

Example :
      In this case, AxleBase is embedded in the host, and the command tells the host to pass the extracted command to AxleBase to run a SQL query.
          ** execute local app command**> AxleBase | ExecuteSql | select * from table |<
      (Additional spaces are inserted in the parameter string for comprehension in this case. That is neither required nor disallowed by the protocol.)

Command : 008 ** resend lost transmission **

A request for the interlocutor to resend a lost transmission.

The command is followed by a parameter enclosure. The enclosure may contain the identifier of the lost transmission. An empty specification specifies the last transmission.

The retransmission will have a new header.
      The resend element will identify the original message.
      The response identifier will identify the resend request.

Examples :
      ** resend lost transmission **><
      ** resend lost transmission **>Qca0B0xofeegeegSA2i2b<

Command : 009 **syslink error notification**

Notice of errors is not required.

The error string is for errors at the protocol level and not at the communication or the application levels.

Identifier :
      The error string is followed by a pointer enclosure. The enclosure may optionally contain the error identifier.

Identifiers are free-form, and may be system-readable, but must be understandable by a person.

Examples :
**syslink error notification**><
**syslink error notification**>008 release number<
**syslink error notification**>008 Requested release number not supported.<

Command : 010

( Reserved. )

Command : 011 ** information return query **

This is a request for information. The command is followed by the parameter enclosure with the information specification.
      ** information return query **>aaaaaaaa<

( Human-readability of the specification is recommended, but is not required.)

Example :
      The location for the demonstration databases can be known only by the server, so before beginning a database build and test, AxHandle sends the following:
      ** information return query **>dbroot<

Command : 012 ** information query return **

This is a response to ** information return query **. If the system chooses to respond, then this is the appropriate response that is followed by the parameter enclosure with the information.

The transmission header may contain the identifier of the transmission to which this is a response.

( Human-readability of the information is recommended, but is not required.)

Example :
      The AxServer demonstration server may respond to the dbroot request with :
      ** information query return **>\\server19\c:\axserver\<

Command : 013 ** identification requested **

This is a request to the interlocutor to return its identification. Response failure is not a protocol error (, although it may be an application error).

The receiving app may require the sender's id and authentication in the header with this command, but this protocol does not require them.

Command : 014 **identification is enclosed**

This is a response to a request for identification. The identification will be in the header. Response failure is not a protocol error.

Command : 015 **comm check please respond **

This control statement may be initiated by client or server to verify a functional communication link. The command will constitute the entire message.

Command : 016 **comm check 30 chr response**

This is the expected response to a communication check if the system chooses to respond. The entire message will consist of only the response.

The identification of the request may be in the envelope header.

Failure to respond is not an error within this protocol.

Command : 017 **authenticate**authenticate**

Receipt of this command is expected to cause the recipient to respond with authentication. Failure to comply is not a protocol error, but may result in termination.

The command must be followed by a parameter enclosure. Contents of the enclosure will depend upon when the authentication is wanted and upon the nature of the applications. Some apps, such as AxleBase can authenticate without input, but some require an authentication seed from the requestor. A vertical bar indicates a seed.

An immediate reply is expected with authentication.
      If the enclosure is empty,
      or if the enclosure contains a single vertical bar,
      or if it contains a single vertical bar followed by a value.

Immediate authentication is not needed, but all subsequent transmissions from the interlocutor must contain authentication within the envelope header if :
      The enclosure contains the start string,
      or it contains the start string followed by a vertical bar,
      or it contains the start string, a bar, and a value.

Examples :
      **authenticate**authenticate**><
      **authenticate**authenticate**>|<
      **authenticate**authenticate**>|xyz123<
      **authenticate**authenticate**>start<
      **authenticate**authenticate**>start|<
      **authenticate**authenticate**>start|xyz123<

Command : 018 ** authentication enclosed **

This is a reponse to the request for immediate authentication if the system chooses to respond. The complete statement includes the authentication string and is in the form :
      ** authentication enclosed **>nnnnnnnnnnnnnn<
      Where nn... is a string of indeterminate length enclosed by two pointers and is the authentication string.

( AxleBase authentication is extremely verbose and uses the entire character set.)

Command : 019 ** encryption specification **

( This command protocol is still under active review and should be expected to change.)

This is a request to the interlocutor for encryption of subsequent transmissions. The complete statement includes an encryption specification which may be blank, but the enclosing characters must be present. The complete statement is in the form :
      ** encryption specification **>specification<
      Where specification is a string of indeterminate length, and is the optional encryption specification.

After this command is transmitted, the transmitting system will expect encryption until the command is rescinded. Rescission is accompished by transmitting the command with the "stop" string in the specification position.

Command : 020 ** initialize app or system **

This commands the recipient to initialize itself, an embedded app, or the operating system.

The command is followed by the parameter enclosure containing the target specification.

Compliance is optional. A return is optional.

Example :
      Because AxleBase can be distributed, operation and communication control is vested in the central control console. Therefore, that control is built into the AxleBase demonstrators.
      The AxHandle demonstrator likes to initialize AxleBase in the server after heavy duty cycles and in some job streams. When AxServer receives the command
      ** initialize app or system **>AxleBase<
he stops, unloads, and reloads AxleBase. When he receives the command
      ** initialize app or system **>computer<
he reboots the computer.

Command : 021 **stop now. unload now. die.**

The receiving app, server or client, is expected to respond to this command by unloading itself and any client software. There is no provision for a restart. (See the initialization command for a restart.)

If the server is running a job, then compliance may not be possible. Therefore, a comm-check is recommended after sending the command.

Non-compliance is not a protocol error.

Command : 022 ** transmissions size limit **

Allows an application to limit the size of transmissions from the interlocutor. The value is not negotiable. If both sides request a limit, then the lower value wins. If a requested return exceeds that size, then the interlocutor will be expected to drop the response and send an appropriate error notice.

No specification or a specification of zero means that there is no limit.

The specification will remain in effect for the duration of the communication session.

The command is followed by the parameter enclosure enclosing the return size specification.
      ** server return size limit **>nnnnnn<

Command : 023 ** denial of a transmission **

This states a refusal to comply. Its use is optional and may be used in response to any message.

The recipient may expect to find the number of the transmission to which it is a response in the header, but the sender is not required to send that information.

Command : 024 ** operation status follows **

This transmits the state or status of an operation. Its use is optional and is provided for application-specific needs.

The command is followed by the parameter enclosure. A report within the enclosure is optional.

Examples :
      ** operation status follows **>intermittent noise<
      ** operation status follows **>daily operation completed<
      AxleBase handles his own reporting needs, so he never uses or complies with this command string.

Command : 025 thru 029

(Reserved for future use.)

Server returns are managed by a server envelope. The server envelope consists of a single element header string and a single element footer string. Each is a thirty character literal that is terminated by chrs 13 and 10.

The server envelope header is :
          030 ** * server return begin. * **
and the server envlope footer is :
          031 ** * server return cease. * **

The server envelope is a message and is placed inside a transmission envelope. The server envelope with its contents is alone within the transmission envelope.

A server may return anything within the server envelope including application error messages, but not protocol error messages.

The header and footer strings conform to the control command format.

( The protocol does not deny the ability of both interlocutors to be servers and/or clients.)

End Of Syslink Protocol

SysLink does not deny additional layers in the network stack. For example, the ODBC protocol may be carried by SysLink. Any protocol that conforms to the requirements of Syslink can be carried by Syslink. Additional layers must not conflict with the layers below them.

Copyright 2003 - 2012 John Ragan

Web site maintained with Notepad and command line FTP.