PROTOCOL FOR COMPUTER SOFTWARE INTER-APPLICATION COMMUNICATION

Abstract: A protocol for computer software inter-application communication and messaging is disclosed in which messaging compatibility between two application programs is established through a conversation using a protocol which comprises the initiation and negotiation of options of a pre-defined kind, the options belonging to a set of options which is expandable to cover additional options.

Description: Protocol for computer software inter-application communication Field of the Invention This invention relates to a protocol for computer software inter-application communication and for establishing messaging compatibility. The protocol is of relevance to application integration and e-commerce. Some Definitions 'Messaging' is the transfer of messages, including application data, instructions and replies between applications. Messages have both content and a definite size. 'Communications' however is a broader concept including all forms of sending and receiving information, irrespective of whether or not the information can be regarded as a message. The term 'inter-application' communication used in this specification refers to communication between 'applications' (as defined below) as well as communications internal to an application. A computer application (typically referred to as an 'application' for the purposes of this patent specification) should be expansively construed to include (i) an end application, i.e. one that generates, interprets, or acts upon messages; (ii) a 'middleware' application, including (a) a message broker which interprets, generates and acts as end application, but which exists largely for routing and adding value/mapping, (b) asynchronous message queuing middleware ("MQM") (e.g. MQM systems such as IBM MQ Series or Microsoft MSMQ), and (c) a message gateway like a SWIFT CBT (see below for a description of a SWIFT CBT); (iii) 'middleware'; (iv) messaging protocols like remote procedure calls (RPCs); (v) a messaging API (application programming interface); (vi) components within an application; and (vii) components with a computer system (such as a process, thread or sub-routine). The term 'middleware' has been coined to describe software that can act between hardware, software (including protocols, APIs and procedure calls) or communications. Description of the Prior Art Protocols for computer software inter-application communication and messaging may, amongst other uses, enable different computer applications to exchange messages with one another. Protocols can be of central importance to application integration, interface interaction and to delivering application plug-and-play. There is however currently no common standard governing inter-application messaging and interoperability between applications; hence, no common standard or best practise yet defines how to connect, agree to connect or adapt between different protocols and application interfaces. To take a simple example, no common standard yet defines the procedure for establishing whether or not bi-directional data flow or 'windowing' is supported. ('Windowing' is a technique for sending messages without waiting for individual replies to be received before sending the next message - hence a 'window' of 10 means that a maximum of 10 outstanding replies is allowed). Many protocols also include application specific constraints which render them unusable with other applications. Hence, there exists a pressing need for a standard inter-application communications protocol allowing communications to be successfully sent between two different applications. This requirement for an inter-application communications protocol exists in many different computing sectors, but the need is particularly acute in application integration, Enterprise Application Integration (EM), Internet Application Integration (LAI), e-commerce, and messaging. For example, in the banking/finance field, many different applications need to communicate with the global banking network developed by S.W.I.F.T. sc. ("SWIFT"). S.W.I.F.T., the Society for World-wide Interbank Financial Telecommunications, is a co-operative organisation which runs a network between financial institutions. SWIFT has a strict format requirement for messages, which allows organisations to automate payments, confirmations and other transactions with participating institutions. Back office applications cannot however (in 1998) communicate directly with the S.W.I.F.T. network. In order to send and receive messages, applications in a given bank must talk to a computer within the bank, called the SWIFT computer based terminal (CBT). The SWIFT CBT in turn communicates with the SWIFT network. The CBT has to meet strict requirements and be certified before it can be used on the SWIFT network. Different companies produce SWIFT CBTs and, as a consequence, most CBTs have their own application interface. Yet there is no universal standard way for back office applications to communicate with a SWIFT CBT. Back office application vendors must adhere to more than one specification if they want to link to different CBTs. To get around this, many back office application vendors specify their own interface, which is typically a batch type interface (i.e. an interface in which several messages are written to a data file for subsequent processing) and leave it to the user to integrate with the CBT. This is unsatisfactory and costs the banking industry many millions every year in integration costs SWIFT will in 2000 likely introduce their Next Generation (NG) products and services, which may replace the traditional CBT. Under NG, SWIFT Net Link (SNL) is the only mandatory software component which must reside within the bank between an application and the new SWIFT network. However, applications will most likely continue to communicate with a gateway or messaging system rather than use SNL directly. NG alone is unlikely to remove the need for a standard way to communicate and application integration The scale of the problem is best appreciated by an example, which illustrates also the scale and success of SWIFT: SWIFT covers some 6,354 financial institutions and operates in 175 countries. The institutions comprise 2,984 members, 2,659 sub- members and 711 participants. Traffic for 1998 is expected to be in excess of 900 million messages. Some of the sub-member institutions are connected to SWIFT through their head or regional office. If it is assumed that 70% of sub-members are directly connected to SWIFT, then there are approximately 5,500 SWIFT CBTs. If it is also assumed that there are on average three back office applications per CBT, then there are some 16,500 banking applications alone which need to communicate with SWIFT. Many of these applications will have interfaces developed internally by a bank. They will not conform to any single standard for communicating application messages to SWIFT. Message Queuing Middleware (MQM) and Message Broker (MB) systems are a partial solution to sending application messages between different applications and have met significant success in the financial marketplace. A MQM/MB system gives an organisation a standard for passing messages and a way of enriching them. Major banks are now looking at and implementing MQM/MB systems in order to standardise their messaging infrastructure globally. MQM/MB systems typically provide an Application Programming Interface (API), which allows puts and gets, a store and forward facility, a rules based engine and data reformatting and mapping. Additionally, as a consequence of their focal position, MQM/MB based systems can provide monitoring and additional features that would not otherwise be possible. There are several well established MQM/MB systems. For example, the IBM MQSeries, which is a put and get infrastructure with store and forward, is well established. It incorporates secure and reliable messaging. TIBCO TLB/ETX is another put and get infrastructure like the IBM MQ Series. New Era Of Networks (NEON) NEONet is another example and employs relational database technology to store and forward messages in synchronisation with the application. It also provides a put and get infrastructure. Because there are several well established MQM/MB systems, each being proprietary and each with a significant user base, it is possible that none of the existing MQM/MB systems will become a de facto standard for inter-application communication, application integration, e-commerce and messaging. Hence, there exists a need for these MQM/MB systems to adopt a common protocol allowing effective messaging amongst themselves and with other applications. A standard Application Programming Interface (API) is also a partial solution to sending application messages between different applications. Candle's Roma BSP product is such an API. More recently (since 1998), the Open Applications Group (OAG) has adopted IBM's Application Messaging Interface (AMI) standard. But a common put() and get() API, like AMI, does not necessarily lend itself to send() and receive(). Message orientated middleware can generally be classified as either asynchronous (connection-less) or synchronous (connection-orientated). Asynchronous messaging queuing middleware (MQM) has conventionally been regarded as more flexible and capable than the synchronous solution, principally RPC (remote procedure calls). But MQM systems are more costly and demand significant infrastructure. Reference may also be made to TELNET, which is a terminal emulation protocol which supports some forms of option negotiation. TELNET will be discussed in more detail in the Detailed Description section ("RACE: a comparison with TELNET") of this patent specification. Statement of the Invention In accordance with a first aspect of the present invention, there is provided a method of communicating messages from a first computer application to a second computer application, wherein messaging compatibility between the first and second applications is established using a protocol which comprises the initiation and negotiation of options of a pre-defined kind, the options belonging to a set of options which is expandable to cover additional options. Hence, the present invention is based, in this one aspect, upon the insight of the utility of a protocol for inter-application messaging in which negotiating 'options' is fundamental. An 'option' can be any feature or characteristic of the manner by which messages can be transferred (i.e. the proper grammar of communicating messages). Expandability may typically be achieved by assigning a unique identifier to each option. That unique identifier (which may be a number) is used in any negotiation dialogue. Using numbers to identify options, for example, means that the set of options is readily expandable and unlimited. The unique identifiers may be used in the initiation as follows: the connecting party sends a request which in essence asks the connected party if they will perform or accept a given option - in the syntax of the preferred embodiment, this looks like "DO (option identifier)". The connected party may then say "WILL" if it can perform that option or "WONT" if it cannot perform that option. An example best illustrates the concept of options and option negotiation in practise: imagine that the first application wishes to send a batch of messages, which are already stored in a batch message file. Since the messages are already in a batch message file, the first application first asks the second application whether it supports batch message file transfer. If the second application says it does, the first application transfers its messages as a batch message file. If the second application says it does not, the first application can suggest a different, simpler connection type, such as "put/get". If the second application agrees, the first application can then send each message individually using "put". If the second application does not agree, the first application can suggest another connection type, such as "send/receive". If the second application agrees, the first application can then send each message individually using "send". Otherwise, if the second application still does not agree, compatibility cannot be reached. In this way, flexibility is introduced into the system since the method of the invention not only supports multiple communication protocols, but also enables applications to readily negotiate which actual communication protocol or communication protocols to use through, for example, a process of negotiation and compromise until one or more common denominators are found. A specific example would be that the present method enables communication with different CBT interfaces, whether they use send/receive or put/get or batch, in the manner explained in the above option negotiation example. If the other party does not support a suggested option, it merely has to reply "WONT". The parties can then compromise by agreeing a different option type, or else messaging cannot be established (unless there is a rudimentary default). Some options, but not all, need to be defined by parameter values. For example, consider the following option negotiation with parameter values: imagine that the first application wishes to use the option of windowing and in particular windowing using a parameter value of 10. Message windowing of this kind speeds up message transmission with the second application since there can be up to 10 messages unreplied to at any time. The first application initiates a dialogue with the second application by requesting whether or not the second application supports the option of windowing, and in particular a window of value 10. Imagine that the second application only supports a window of 2: the second application responds by stating that it does support windowing, but only up to a window of 2. The first application then accepts this. The entire dialogue can also be viewed as a 'negotiation', hence the use of that term in this patent specification. In many prior art systems, there would be a fixed window of 1 message from one application to another application with no scope for the system to expand to cover additional options. This is clearly less flexible than the 'expandable negotiated options' method of the present invention. Preferably, in the present invention, negotiating occurs within a range of allowable parameter values of any given messaging option. So, using windowing again, the range of allowable parameter values could be 1 to 10, with, in the previous example, the sender supporting up to 10 and the recipient supporting 2 or up to 2. Some options however do not include parameter values. Any option parameter values may be included with the request to negotiate, which makes negotiation faster, since normally only one "round trip" of negotiations is needed, as opposed to two. If necessary, an option can be negotiated even further with additional packets. Also, the connecting party may declare as many of the options it supports as it can in a single transmission, again speeding up negotiation. In a preferred embodiment, the connecting party sends a 'DO Option type' request; the connected party then sends a 'WILL' reply if that option type is supported. Only the connecting party may be able to initiate a negotiation. This approach results in the connecting party being able to control and compromise the negotiation. 'One-sided initiation' makes implementation considerably easier and avoids infinite loops, which may arise in symmetrical negotiation, as occurs in the TELNET protocol for emulating terminals (see the Detailed Description for commentary on TELNET). Symmetrical negotiation is also a possibility in the present invention. Further, negotiation can be restricted to a limited number of or even just a single occasion during the beginning of a conversation between applications. This makes implementation considerably easier and avoids infinite negotiation loops arising, as may occur in TELNET. Since the second application can be a message oriented protocol or API, the protocol enables mapping to message oriented protocols and application interfaces (i.e. it achieves inter-operability). It can achieve this without any store and forward functionality. In accordance with a second aspect, there is provided a method of communicating messages from a first computer application to a second computer application wherein messaging compatibility between the first and second applications is established using a protocol which uses a language with mandatory elements limited solely to the negotiation of options of a pre-defined kind, the options belonging to a set of options which is expandable to cover additional options. Using a simple, core language (i.e. a 'basic protocol'), which in this aspect is exemplified by an option negotiation language, has many advantages, such as ease of designing simpler systems and constituting a starting point for communication and a default for messaging (as well a default for option specification during the option design phase) Simplicity does not compromise the ability to design more complex systems because of the expandability to include other options and various values of options. The protocol language may be supplemented with a connect request, which will normally be supported by a party being connected to. A defined disconnect language may also be used. In a preferred embodiment, option negotiation does not occur until after the target service and application has been specified in a connect request packet. Authenticity, encryption (secure authenticity, confidentiality and integrity), and user passwords can then be provided during negotiation. In a third aspect, there is provided a method of communicating messages from a first computer application to a second computer application, wherein the first and/or second applications declare attributes to the protocol defined in the first or second aspects of the invention stated above. Attributes are properties of the application: they are features which the application can support. Not all attributes are directly related to options, but the protocol may treat those declared attributes that are related to options as an instruction to negotiate the related option. In a preferred embodiment, the first and/or second applications declare their attributes. Subsequently, associated options are negotiated via the protocol. As a final check, the negotiation result is verified to conform to the application attributes. It is important to differentiate between 'attributes' and 'options': options belong to the protocol, are negotiated, are given a unique option identifier and are documented as an option specification. They represent a choice which can be negotiated. Attributes on the other hand belong to and are a property of an application. They are declared in order to generate option negotiation and to enable matching of the results of negotiation. They are a property which the application is willing to support. In a further aspect, there is a method of assigning or using names as part of an address for an application, service, connection or a message, in which the message is communicated using any of the above inventive methods. In another aspect, there is a method of establishing a standard API using any of the above inventive methods. The protocol of the present invention is exemplified by the RACE Protocol developed by Global Financial Networks Limited of the United Kingdom, which is further described in the Detailed Description which follows. RACE deals with inter- application communication, on transferring messages and with connectivity. In further aspects, there is provided a method of application integration using any of the above inventive methods. Policies, adaptors and agents can also be added using any of the above methods. The terms of art 'application integration', any of 'policies', 'adaptors' and 'agents' are defined below. Application integration is the unrestricted sharing of data, information, workflow and processes between applications. The discipline encompasses a set of technologies, like communications middleware (which include message orientated middleware, messaging APIs, synchronous messaging, asynchronous messaging, inter-application communication, and messaging), database middleware and systems middleware. Application integration is performed at all levels (e.g. business/user, application, API, transport/data). Enterprise Application Integration (EAI) and Internet Application Integration (IAI) are buzzword terms to describe application integration within and between organisations and over the Internet. Within application integration, a key goal is to simplify the application interface, for example, to a simple put/get, send/receive, or database write/read. By simplifying the application interface, applications are easier to integrate and integration is faster. Another key goal is to loosely couple (or decouple) the application from its messaging. By simplifying and decoupling the application interface, functionality, which was previously within the application, can be moved outside the application. Once outside the application, functionality can be more readily changed and can be offered as a commodity. Polices - These are definitions, which exist external to the application, in order to drive the underlying function (which, in this case, is inter-application communication). Policies can be defined and changed without altering the application. Policies introduce features, like security, which affect the function, but which the application does not need to know. Adapters - These are software components, which provide connectivity, conversion and translation between two incompatible application interfaces. For example, Global Financial Networks Limited will build adapters to exchange messages between different CBT interfaces, MQM/MB systems, APIs and protocols. One adapter might talk between RACE and a Logica CBT. Another adapter might talk between RACE and one of SWIFT's own CBTs. An application can then use RACE to talk to either the Logica product or the SWIFT product. Alternatively, a third adapter might enable the application to talk to either. Adapters can be ready-made or one-off (bespoke). The more of a commodity they are, the better, as people want immediate connectivity. Adapters need a common environment, like RACE Services (see the Detailed Description for commentary on RACE Services), for ease-of-use and manageability. Adapters (like most other messaging products) must be secure and reliable. The RACE protocol allows adapters and RACE applications to be seamlessly plugged-in. i.e. plug-and-play. Agents - These are software components, like adapters, which add functionality outside the application. For example, a security algorithm, a directory service, etc. Again, agents need a common environment, like RACE API and RACE Services, for ease-of-use and manageability. In final aspects of the invention, there is provided computer hardware apparatus programmed to perform the inventive methods, carrier media programmed with software to enable computer hardware to perform the inventive methods, and application messages exchanged using or reliant upon the inventive methods. Detailed Description The present invention will be further described in relation to an embodiment called the RACE Protocol developed, distributed and licensed by Global Financial Networks Limited of the United Kingdom. RACE is a trade mark of Global Financial Networks Limited and is an acronym for Rapid Application Communication and Emulation. It is designed to be a common language for communication between computer systems in order to transfer application messages, adapt between messaging interfaces, couple/decouple applications, assist in application integration, enable interoperability, and provide an essential standard for messaging and e-commerce. RACE is an inter-application communication protocol, which standardises the way applications communicate and pass messages to each other. RACE is designed for the Internet and corporate networks, but, in principal, can be used on any network. At Appendix 1 is the Race Protocol Specification Version 1.1 (draft) for software developers, which gives a more detailed treatment of RACE. The advantages of RACE can be summarised by considering the acronym in more detail: RACE is 'Rapid' because it allows developers to rapidly integrate applications and because it allows messages to be transferred extremely quickly. The term 'Application' is used because it is a protocol amongst applications and deals with transferring application messages. 'Communication' is used because it is a communication protocol. 'Emulation' applies because it allows applications to be emulated. RACE is easily spoken by any modern computer system. Negotiated options, as defined in the Statement of Invention, enable secure, reliable and fast messaging, which is independent of applications. Negotiated options allow RACE to provide an unprecedented feature set which can assume any other message transfer protocol. RACE: a comparison with TELNET RACE possesses some superficial resemblance to the well-known Internet protocol, TELNET. The majority of computer systems, including dedicated devices such as routers and printers, speak TELNET. TELNET is a general protocol that allows terminals to be emulated. In the early days of computing, a mainframe computer had many physical terminals attached to it. Today, TELNET is widely used to replace physical connections and provide remote access. TELNET also makes it possible for terminals to talk to terminals and computers to talk to computers. Messages cannot however readily be communicated using TELNET since TELNET includes no concept of boundaries, which are inherently needed to define the start and ending of a message. TELNET and RACE share some conceptual similarities: both, for example, assume a 'basic protocol' of what the protocol can do. In the case of TELNET, the basic protocol is communications from a virtual terminal with a limited character set. In the case of RACE, the basic protocol is a connection to and rudimentary option negotiation as described earlier in this patent specification. A simple basic protocol is highly advantageous because it allows straightforward implementation on most computer systems. Secondly, TELNET and RACE have built into the basic protocol a method of negotiating options so that their respective protocols can be 'dynamically' extended (i.e. behaviour can change during a connection, rather than being fixed at the time of program creation, and newer applications can be easily integrated). In the case of RACE, if the connecting application can perform an option, it first asks whether the other application supports the option. It sends "DO" and/or "WILL" "option" with discretionary parameter values. A "DO" is sent to request an option. A "WILL" is sent to offer an option. If the other application does not support the option, it responds "WONT" and/or "DONT" "option" respectively. Otherwise, it responds "DO" and/or "WILL" "option" with discretionary parameter values and, then, the two assume the option or negotiate further, depending upon the option specification. This means that any application can participate in a RACE conversation with a very basic vocabulary. On the other hand, it also means that the protocol can be extended to do just about anything. Indeed, options can negate the basic protocol. In addition, TELNET was published for the Internet Community. As the underlying Internet protocols, like TCP/IP, become commonplace, so did TELNET. RACE may assume the same reliable 8-bit TCP transport (although in fact any reliable transport is appropriate) and use an Interpret-As-Command (LAC) character like TELNET (although it is in fact used to prefix a special delimiter). RACE can also be published as a standard for the Internet Community. RACE differs from TELNET in many significant ways. RACE'S focus is transferring application messages whilst TELNET's is emulating terminals. Hence, RACE provides unidirectional binary data transfer using packets by default, whilst TELNET provides bi-directional transfer of text and terminal control characters without packet boundaries by default. RACE takes this approach in order to make initial implementation easy without losing scope for additional functionality. RACE also differs in option negotiation. In TELNET, option negotiation is symmetrical and can take place at any time during a connection. In RACE only one side, the connecting side, can initiate negotiation and this can only occur in one place at the beginning of the conversation. RACE's approach to option negotiation makes it even easier to implement the connecting party, because it does not need to support negotiation. The connected party is also easier to implement because negotiation only occurs at one point in the basic protocol. Thereafter, both connecting and connected parties can assume a stable feature set. In addition, the connected party need not support WONT or DONT, because the connecting party cannot initiate WONT or DONT by default. This approach avoids infinite negotiation loops, which would otherwise have to be counteracted with quite some thought and programming. An option specification can negate this, so the approach does not preclude symmetric negotiation at any time during the connection. RACE'S option negotiation is also faster, because negotiation parameters are included with the request to negotiate. In TELNET, this is not the case and, if negotiation parameters are needed, it requires two round trips instead of one. Just as TELNET allows terminals to be emulated, RACE makes it possible to emulate applications. Once an application message standard is established, applications can be readily emulated. This emulation gives way to a new breed of applications, which sit in-between existing applications, that can extend and enhance individual or collective application value. Other RACE Features RACE can be both connection-orientated and connection-less. If the connecting party uses RACE to connect to an MQM infrastructure (which is asynchronous, connection-less) but which is guaranteed to exist (for example, because it resides on the same machine as the MQM), it shares the same connection-less properties as MQM. On the other hand, if the connecting party connects directly to a host application, it becomes connection-orientated (and a lot cheaper to implement in practise because a store and forward infrastructure is not needed). RACE also provides a standard for connecting between different message orientated middleware techniques and systems. Currently (as of 1998) the only alternative to using a protocol like RACE as the standard is to use standard APIs like Candle's Roma BSP product. RACE also allows applications and adapters to be swapped in and out without changing the other side of the RACE connection giving plug-and-play i.e. adapters, applications, MQM and MB can become a real commodity. For Roma BSP, the code (in order to connect to a different MQM or MB) has to be added to the other side of the connection. This means the application has either to be recompiled and linked before it can support a new MQM or MB system or else a new run-time module added. In addition, RACE also allows for assigned names of layered protocols, services and applications, like TCP/IP allows for assigned TCP/UDP port numbers. RACE can also offer a way to directly communicate with and over the new SWIFT network, with or without SWIFT Net Link (SNL), like it can also be used for conducting e-commerce over the Internet and corporate networks. Some RACE Options Described In RACE, options are uniquely identified by an option number; option numbering allows for future or experimental numbering which are not part of the initial RACE protocol release or Specification. NOREPLY - negates the behaviour of the basic protocol where a reply must be returned, waited for, and interpreted. This lends the protocol to different applications where either (i) the application handles acknowledgement/reply/synchronisation at the application level or (ii) applications fire messages, forget / don't care whether the messages get there and are interpreted. WINDOW. This is a technique used to speed up the transmission of messages between applications. If replies are needed, normally an application waits for the replies before it can send the next message. By using windowing, multiple messages can be sent without waiting for a message reply. Hence, there is a window of messages outstanding. This gives much better performance, but 1 ) if the link fails, all outstanding messages must be resent and reconciled 2) it is more complicated to program on the sending side. i.e. the sending program must keep track of what its sent and outstanding replies. LGRP. LGRP is 'logical grouping'; it is a way to identify more than one message, which should be treated as a single unit of work. i.e. they are processed as a whole. This is important for 1) processing batches of messages from batch orientated applications 2) transactions where all parts (messages) of the transaction must be completed for the transaction to complete as a whole. If one part of a transaction fails, the whole transaction fails and what has been done is rolled back. Additional options include MODE, SEQNO, PDE, RREF, LGIAUTH, MSGAUTH, MSGLEN, BATCH, NOM and BIGFOOT. Future options may include options for encryption, compression, get put, polling, block transfer of messages and files, and attachments. Appendix 1 may be consulted for a more comprehensive description of RACE options. RACE API also allows policies and agents to dictate application attributes and negotiation. RACE API RACE API is an implementation of the RACE Protocol from Global Financial Networks Limited. RACE API provides access to the RACE Protocol for developers and facilitates rapid and portable application integration. RACE API is unique because it introduces the concept of application attributes. Each application declares the attributes that it is willing to support. By default, these are close to the 'basic protocol' of the RACE Protocol. RACE API then negotiates the RACE Protocol options (with any RACE partner) to see whether the attributes are compatible. If they are, the connection is established and the application can examine which attributes were agreed. Otherwise, the connection is closed. RACE API also provides a unique application program interface (API), which is portable and extremely flexible. Hence, RACE API operates as follows as a default: a) Let the application declare its attributes. b) Negotiate protocol options accordingly c) Check whether the negotiation results match the application attributes. For example, the connecting application (DTE) declares the following attributes: NOREPLY_OFF, MODE_OUTPUT, PDE_ON, PDE_OFF. In this case, RACE API does not negotiate NOREPLY, because replies are in the basic protocol (i.e. assumed by default). RACE API proposes MODE, parameter OUTPUT and must match it in order to continue. RACE API proposes PDE and continues whether or not PDE is agreed (because the application supports PDE and no PDE). One implementation of the API allows the application to override this default. This is important for mapping to other protocols. It may also be necessary to allow the application to intervene during negotiation in order to negotiate a secondary, third, etc. option if the first option fails. Attributes do not need to relate to options. Take, for example, 'MODE control'. The attributes are MODEJNPUT, MODE_OUTPUT and MODE_BOTH, which the application can declare one or more of. The option is MODE and is only negotiated for attributes MODE_OUTPUT and MODE_BOTH. Also note, if the application does not support MODEJNPUT, it does not support the MODE control of the basic protocol (which is quite normal). For security, the application may use attributes SECURE_ON and SECURE_OFF. If it needs security, it will declare SECURE_ON. If it does not, it will declare SECUREJDFF. If it does not care, it will declare both SECURE_ON and SECURE_OFF. If it is to be negotiated, RACE API will pick the highest level of security first and then work its way down to lower levels. This may include negotiation of more than one option. RACE Connect RACE Connect is a Software Development Kit (SDK) for the RACE Protocol from Global Financial Networks Limited. The SDK includes RACE API. RACE Services and Adapters RACE Services is a software product for end-users from Global Financial Networks Limited. RACE Services provides the integrated framework to manage policies, naming, security, agents, and adapters (from Global Financial Networks Limited and third parties). RACE Services allows you to rapidly deploy applications and then centrally and remotely manage linkage at an enterprise level. Global Financial Networks Limited intends to provide ready-made adapters to enable switching between corporate messaging structures, like MQSeries and MSMQ, and batch and interactive communications. The adapter products build upon the RACE technology. RACE enables adapters to be naturally faster than similar store-and-forward solutions and facilitates plug-and-play. Detailed Description Appendix I RACE Protocol Specification Version I . I (draft) GLOBAL FINANCIAL NETWORKS LIMITED www.gfn.co.uk HARPENDEN UNITED KINGDOM TEL: +44 (0)1582 467 486 COPYRIGHT Copyright © Global Financial Networks Limited, 1999. All rights reserved. No part of this publication may be copied or reproduced, sold or transferred to any person in any manner or form or on any media, without the prior written permission of Global Financial Networks Limited. CONFIDENTIALITY This publication contains proprietary information from Global Financial Networks Limited. The recipient should not disclose this information to third parties without the written permission of Global Financial Networks Limited. DISCLAIMER Although Global Financial Networks Limited uses its best endeavours to ensure the accuracy of the contents, Global Financial Networks Limited assumes no responsibility for any inadvertent error or omission that may appear in this document. OVERVIEW 1.01 INTRODUCTION The Rapid Application Communication and Emulation (RACE) Protocol is a standard for inter-application communication and interoperability. The intent of the protocol is to provide a common interface and facilitate general application-to- application message transfer. The RACE Protocol provides a simple, extendable and efficient method of connecting applications and transferring messages. Applications assume a basic protocol and can negotiate protocol options in order to alter the protocol during communication. Applications can be rapidly integrated, because implementation is straightforward and on a need only basis. Any complex communication requirement can be supported, because the protocol is open-ended. For example, the protocol can support secure data transmission, windowing, data compression, etc. By combining simple protocol options, RACE enables powerful functions. The protocol is efficient and can achieve maximum transfer rates. RACE does not define an application message standard nor does it interfere with application message objects. Any binary data and, thereby, any application message can be passed over RACE. Application level protocols can be layered upon or mapped to RACE, with or without RACE providing message replies. Negotiated options facilitate protocol mapping and allow otherwise incompatible applications to agree a common protocol. Once mapped to RACE, a protocol can be easily spoken by applications and can be mapped to other protocols. By decoupling the application from its messaging, RACE provides a single gateway to multiple protocols and application interfaces. Communication can be changed without altering the application whatsoever. RACE assists in replacing and emulating applications. Once message syntax has been defined, an application can be replaced and emulated. RACE does not perform message translation itself, but it does enable messaging applications and adapters to be used as a commodity. The RACE approach gives "plug-and-play", which cannot be achieved using a standard application program interface (API) alone. RACE offers a fundamental standard, in conjunction with XML, for e-commerce and application integration. It works well over corporate networks and the Internet, and gives the kind of flexibility and throughput, which today's SMTP mail and HTTP systems do not provide. MOTIVATION There is no current standard for inter-application communication. Messaging has grown enormously and messaging middleware is now accepted as a key technology. Message queuing middleware (MQM), which provides asynchronous "put" and "get" services, has become commonplace. For example, IBM MQSeries and Microsoft Message Queue (MSMQ). Message brokering (MB) systems are numerous and beginning to take over the roles of routing, workflow management and data mapping from legacy applications. The role of middleware has changed, paving the way for completely new approaches. The growth in messaging is driven by the need for automation, globalisation, e- commerce and real-time settlement. There is an obvious need to standardise inter-application communication. The number of applications, which need to communicate with one another, have increased dramatically and integration work is spiralling out of control. Deployment of MQM and MB systems creates just as many integration issues as the systems were supposed to resolve. It is clear that just one messaging middleware solution is not enough. Customers are frustrated and often feel deceived by the cost and delay of integration. They want interoperable applications, which can work together immediately and be used like a commodity. MQM and MB systems cannot offer a standard for inter-application communication, because they are proprietary and require an expensive store and forward infrastructure. Message queuing systems are needed for queuing, but they are not a standard for connectivity. Off-the-shelf applications cannot support every system and users cannot be expected to adopt a single system. Organisations merge and need to communicate with one another. MQM and MB systems need to communicate with one another. Often, it is unrealistic to use a third system, when direct application communication is sufficient. Standards bodies have been formed in order to address these issues, but it is too early to expect any conclusive recommendations. The general approach being taken is to standardise the application programming interface (API), but whilst this makes sense, it does not provide a "plug-and-play" solution. "Put" and "get" APIs do not necessarily lend themselves to "send" and "receive". Run-time libraries need to be installed and tested before applications can communicate differently. In some cases, applications may need to be compiled and linked again. A standard API will also vary with different programming languages and computing platforms. What is needed is a common protocol (RACE), in addition to a common API. A protocol, like an API, is a specification, which can be open and standard. It does not involve the cost of store and forward for implementation. A standard protocol allows applications to communicate with new applications without changing the application itself. A simple protocol allows easy implementation by the masses. A flexible protocol facilitates interoperability with other protocols and messaging adapters. Existing protocols were not designed for open messaging and are not appropriate. The Remote Procedure Call (RPC) protocol is intended for calling remote procedures and allows applications to be distributed. RPC is a good application communication protocol, but it lacks the fundamental ability to negotiate. The TELNET Protocol negotiates, but it is designed for a completely different purpose, namely to replace and emulate dedicated terminals. There is no notion of a message in TELNET. Other protocols, which deal with object definition and content, are a layered function and not the plumbing standard. Finally, analysts often believe that some applications need to use asynchronous messaging (connection-less messaging using MQM) rather than synchronous messaging (connection- orientated messaging using a protocol). Asynchronous messaging employs store and forward, so it does not matter if the network and network partner are not available. Synchronous messaging, on the other hand, requires a network connection and the partner to be there. However, a protocol can be both asynchronous and synchronous, depending upon its use. For example, if a protocol is used to directly communicate with MQM (on the local system), messaging is asynchronous, but it can be easily made synchronous without changing the application. Using a protocol for communication between software components is efficient, as there is no significant performance degradation, when disk access is involved, compared to using procedure calls. GENERAL CONSIDERATIONS The RACE Protocol is normally implemented as a Transmission Control Protocol (TCP) connection, but it can be used on any similar data transport. RACE assumes a reliable bi- directional asynchronous 8-bit ordered byte stream. It does not employ TCP Urgent data. For TCP usage, an assigned port number will be requested in due course. RACE is a communication protocol between two applications. In order to form a RACE connection using TCP, one application, known as the Data Terminal Equipment (DTE), initiates a connect to a second application, known as the Data Communications Equipment (DCE), which listens on an assigned port. The DTE (the connecting application) and DCE (the listening application) can reside on any computer system or the same computer system. The DTE and DCE can be the same application. The computer systems where the DTE and DCE applications reside are known as the DTE host and DCE host respectively. In practise, a DCE host may service multiple DCE applications on a single TCP port. In this case, a daemon or server process is needed on the DCE host. The RACE protocol lends itself to this kind of concurrency between different DCE applications, but the implementation of the daemon and the definition of the interface between daemon and application is outside the scope of this document. By convention, the DCE daemon is called RACED. Once connected over TCP, the DTE and DCE applications assume a basic protocol. The basic protocol allows for connection, negotiation of protocol options, rudimentary message transfer, and disconnection. The basic protocol is simple without compromising RACE. In order to deviate from the basic protocol, the DTE can initiate the negotiation of one or more protocol options. This allows the actual protocol to be agreed at run-time, giving plug- and-play. Each protocol option is documented and assigned a unique number. Some protocol options use parameters in order to negotiate different values and usage. RACE uses one-sided negotiation for simplicity and in order to avoid infinite negotiation loops. RACE allows parameter data to be included in the initial negotiation sequence, so that only one round trip is normally required. RACE initially limits negotiation to the beginning of the session, so that message transfer is constant. If either DTE or DCE does not agree with the negotiation result, it can disconnect before message transfer is entered into. RACE uses varying length packets to transfer data and control information. These packets are designed for efficient transmission and can be assembled and interpreted in a straightforward manner. RACE facilitates assigning names for layered protocols and applications. Names can have 1 to 64 characters, which gives much wider scope for naming than TCP port numbers do. PAGE INTENTIONALLY LEFT BLANK BASIC PROTOCOL DIALOGUE By default, RACE is a unidirectional message transfer protocol. On one side is DTE and on the other side is DCE. Messages are prepared by DTE and transferred to DCE for interpretation. The protocol involves five distinct phases: PHASE 1: CONNECTION After TCP connection, the DTE sends CONNECT in order to specify a target DCE service and application. If the DCE can accept the connection, it replies READY. Otherwise, the DCE replies DISCONNECT, which indicates the reason for exiting (APPNOTAVA, APPBUSY, etc). If the DCE has responded DISCONNECT, the DCE and DTE should close the link, as a corresponding DISCONNECT is not expected from DTE. PHASE 2: OPTION NEGOTIATION Once the DCE has accepted the connection, protocol options are negotiated in the DTE's order of preference. If the DTE does not have any protocol options to negotiate, it can skip the negotiation phase altogether. For each supported option, the DTE can either offer it, request it, or both offer and request it, depending upon the option specification. In order to offer an option, the DTE sends WILL. If the DCE would like the DTE to perform the specified option, it responds DO. Otherwise, it responds DONT. In order to request an option, the DTE sends DO. If the DCE can perform the specified option, it responds WILL. Otherwise, it returns WONT. The DCE need only respond DONT/WONT if it does not support a protocol option. Option parameters, if required, are included in DO/WILL according to the option specification. Once an option has been agreed, it can be negotiated further using HERE-IS according to the option specification. The DTE can send multiple DO/WILL/HERE-IS packets without waiting for a corresponding DO/DONT/WILL/WONT/HERE-IS packet from the DCE. However, the DTE must be careful of the order of negotiation as some options depend upon other options. The DTE should only send one DO/WILL packet for each supported option unless the option specifies otherwise. Negotiation is complete once the DTE has received a DO/WILL/DONT/WONT reply for each DO/WLLL request and any additional negotiation is complete. PHASE 3: READY, READY In order to end negotiation and enter into message transfer, the DTE sends READY. If the DCE is satisfied with negotiation, it replies READY and the two enter into message transfer. Otherwise, if the DCE does not wish to proceed after receipt of READY, it replies DISCONNECT instead of READY, which indicates the reason for exiting (INSNEGOPT). If the DTE does not wish to proceed after negotiation, it sends DISCONNECT instead of READY, which indicates the reason for exiting (INSNEGOPT). If DCE or DTE has sent DISCONNECT, the DTE and DCE should close the link, as a corresponding DISCONNECT is not expected. PHASE 4: MESSAGE TRANSFER For each message to be transferred, the DTE assembles and sends a MESSAGE and waits for a corresponding MESSAGE-REPLY before going onto the next message. If the DCE accepts the message, the DCE responds with a positive MESSAGE- REPLY (SUCCESS). Otherwise, the DCE responds with a negative MESSAGE- REPLY and details the reason (LNVMSG, ...). The DCE continues servicing incoming messages even if it rejects some or all of them. The DCE should only use MESSAGE-REPLY to reject a message and not DISCONNECT. In the case of an authentication failure, resource failure, etc., the DCE may need to abort the connection by sending DISCONNECT. PHASE 5: SHUTDOWN At some point, either party will want to close the connection. For unidirectional connections, the message sender will typically initiate this after transferring its messages, unless a "keep alive" timer is in effect. In order to accomplish a graceful shutdown, either DTE or DCE can send DISCONNECT with code SUCCESS. Upon receipt of DISCONNECT with code SUCCESS, the other party should complete its processing and return a corresponding DISCONNECT with code SUCCESS. On receipt of or after sending the second DISCONNECT, the link can be closed. If the DCE has requested shutdown and no DISCONNECT has been received, it should continue to accept messages and return replies for a reasonable amount of time. If the DTE receives DISCONNECT while waiting for a message reply, it should continue to wait for the message reply and then send a corresponding DISCONNECT. The DTE should only request shutdown when no message reply is outstanding and it should not then go onto sending additional messages. It should be noted that the shutdown mechanism introduces a packet, which can be initiated by DCE in the basic protocol. In addition, the DTE or DCE can abort the connection using DISCONNECT at any time. Therefore, the DTE needs to be ready to handle this event. r example, a basic session: DTE DCE CONNECT("race$generic","TESTAPPL",) -> <- READY0 READY0 -> <- READY0 MESSAGE("Hello World!") --> <- MESSAGE-REPLY(SUCCESS) DISCONNECT(SUCCESS) -> <- DISCONNECT(SUCCESS) r example, a typical bi-directional session: DTE DCE CONNECT("race$generic","TESTAPPL",) --> <- READY0 DO(MODE,BIDIRECTIONAL) -> <- WILL(MODE,BIDIRECTIONAL) WILL(WINDOW,3) -> DO(WINDOW,3) -> <- DONT(WINDOW) <- WONT(WINDOW) READY0 -> <-- READYO MESSAGEC'IST CLIENT MSG") -> <- MESSAGE-REPLY(SUCCESS) MESSAGE("2ND CLIENT MSG") --> <- MESSAGE("1ST HOST MSG") <- MESSAGE-REPLY(SUCCESS) MESSAGE-REPLY(SUCCESS) -> DISCONNECT(SUCCESS) -> <- MESSAGE("2ND HOST MSG") MESSAGE-REPLY(SUCCESS) -> <~ DISCONNECT(SUCCESS) r example, the DTE rejects option negotiation: DTE DCE CONNECT("race$generic","TESTAPPL",) -> <- READYO DO(MODE,OUTPUT) --> <-- WONT(MODE) DISCONNECT(INSNEGOPT) -> r example, the DCE rejects option negotiation: DTE DCE CONNECT("race$generic","TESTAPPL",) <- READYO READYO -> <- DISCONNECT(INSNEGOPT) In these examples, the MODE and WINDOW protocol options and bi-directional message transfer are not part of the basic protocol. The basic protocol only includes the ability to negotiate and not the options themselves or their associated protocol. In the event of an unexpected error, like timeout or a protocol error, the program should, if possible, send DISCONNECT in order to detail the error and then close the link. A corresponding DISCONNECT is only expected or sent during the shutdown phase, when DISCONNECT contains SUCCESS. A corresponding DISCONNECT is not expected unless message transfer has been agreed, even if DISCONNECT contains SUCCESS. PACKET USAGE All RACE packets begin with a packet code and end in the End-Of-Packet (EOP) sequence. A packet code is a single byte, which indicates the start of the packet and the packet type. The EOP sequence consists of the Interpret- As-Command (LAC) byte, value 255, followed by the EOP byte, value 254. For example, <200><255x064>Hello World.<255><254> Here, <200> indicates the start of the packet and identifies it as a MESSAGE packet. "<255><064>Hello World." is the contents of the packet. <255><254> indicates the end of the packet. Most packets comprise of a varying number of variable length fields. Each field is prefixed by a two-byte sequence and terminated by either another field prefix or the EOP sequence. A field prefix consists of the IAC byte followed by a field identifier, whose byte value is predefined and in the range 0 to 253 inclusive. An optional field may be omitted. A field may have zero length, in which case only the field prefix is specified. For example, < 192x255x031 >race$generic<255x032>TESTAPPL<255><254> Here, <192> indicates the start of the packet and identifies it as a CONNECT packet. <255><031> indicates the start of field 31, which contains the target service identifier "race$generic". <255><032> indicates the end of field 31 and the start of field 32, which contains the target application name "TESTAPPL". <255><254> indicates the end of packet and the end of field 32. Option negotiation packets, DO/WILL/DONT/WONT/HERE-IS, do not follow this field prefix notation. Instead, the option code and option parameters are implicitly identified by position. The option code is the second byte in the packet and the option parameters, when included, immediately follow (normally at the third byte) and are terminated by the EOP sequence. For example, <193x041x255x254> Here, <193> identifies a DO packet. The option code <041> is the second byte in the packet. If present, the option parameters follow after the option code, but in this example there are no parameters. Within a packet, data is eight bit binary data. If byte 255 is used, it must be doubled in order to prevent misinterpretation. This is true for both option negotiation packets and packets that use field prefix notation. Doubling data byte 255 will realign subsequent data and increase the packet length (during transmission, before interpretation). For example, <200x255x064>Data byte "<255><255>" must be doubled.<255><254> Fields can be embedded within a field or within option negotiation parameters. For this to work, the IAC byte of each sub-field prefix has to be doubled so that a first level parser can treat it as binary data. For each layer of embodiment, the IAC bytes of each sub-field prefix must be doubled. Consider, <193xl l6> <255x255x031> <255x255x255x255x020>abcd <255x255x255x255x021>efgh <255><255><032>ijkl<255><254> Here, <193> identifies a DO packet. The option code is the second byte (116) and the option parameters start at the third byte until the EOP sequence. <255><255><031> identifies the first parameter sub-field and <255><255><032> identifies the second parameter sub-field. The first parameter sub-field, field 31 , contains two more sub-fields, identified by <255><255><255x255x020> and <255x255x255x255x021>. The two sub-fields of field 31, fields 20 and 21, contain "abed" and "efgh" respectively. The second parameter sub-field, field 32, contains "ijkl". Notice how the first level uses two IAC bytes and the second level uses four IAC bytes. This example does not follow a valid option specification and is only included for illustration. RACE does not dictate a maximum packet length. All packets, except the MESSAGE and MESSAGE-REPLY packets (where the length is application specific), have a defined maximum length. An option specification may be drawn up in the future in order for applications to agree a maximum message length. SERVICE AND APPLICATION IDENTIFIERS The CONNECT packet contains the target service identifier and the target application identifier. The service identifier identifies the type of service, while the application identifier identifies the application name or service instance. Service identifiers and application names prefixed by "race$" are reserved for the RACE protocol. Service identifiers and application names prefixed by a "$" are reserved for assigned names. Currently, only one RACE service is defined: race$generic - Generic messaging application Other services may be added in the future. Future services may assume a different basic protocol. REPLY AND DISCONNECT CODES Code values are used in MESSAGE-REPLY and DISCONNECT in order to return status information. A code is an unsigned short integer (in network byte order) as described later in this document. Applications must be ready to handle codes, which have not yet been defined, in order to support future versions of the protocol. The general ERROR code can be used to describe an unrecognised code. When the code is SUCCESS, it can be omitted from MESSAGE-REPLY or DISCONNECT in order to increase performance. If omitted, SUCCESS is assumed. For example, <201><255><254> is equivalent to <201x255x021x000x000x000x 00x255x254>. PAGE INTENTIONALLY LEFT BLANK PROTOCOL OPTIONS This chapter contains the RACE protocol option specifications. Global Financial Networks Limited (GFN) currently maintains the RACE protocol options. Recommendations for new protocol options should be sent to GFN using e-mail address: race@gfn.co.uk All recommendations will receive due attention and, if accepted, will be incorporated in a future version of this document. The following protocol options are defined: NAME CODE DESCRIPTION MODE 33 MESSAGE TRANSFER DIRECTION NOREPLY 34 NO MESSAGE REPLIES WINDOW 37 MESSAGE WINDOWING SEQNO 38 SEQUENCE NUMBERING PDE 53 POSSIBLE DUPLICATE EMISSION FLAG RREF 54 RECEIVER REFERENCE LGIAUTH 65 LOGIN AUTHENTICATION MSGAUTH 66 MESSAGE AUTHENTICATION LGRP 72 LOGICAL GROUPING MSGLEN 78 MESSAGE LENGTH BATCH 41 BATCH FILE TRANSFER NOM 42 NUMBER OF MESSAGES BIGFOOT 82 BIG CODE NUMBERING intended to add protocol options in the near future for: _ Encryption _ Data compression _ Checksum calculation _ Polling with go-ahead of messages and files _ Block transfer of messages and files 3.01 MODE [MODE OF MESSAGE TRANSFER] IDENTIFICATION Name: MODE, Code = 33 Dependencies: n/a OVERVIEW The MODE protocol option enables the transfer of messages from DCE to DTE or bidirectional message transfer. By default, the basic protocol only supports unidirectional message transfer from DTE to DCE. This option uses the following terminology in order to describe the direction of message transfer: - INPUT : One way from DTE to DCE (the default) - OUTPUT : One way from DCE to DTE - BIDIRECTIONAL : Two way (either direction independently) OUTPUT (from DCE to DTE) and BIDIRECTIONAL message transfer are similar to INPUT (from DTE to DCE) message transfer. Once message transfer has been agreed, either party can send messages depending upon the agreed mode. For OUTPUT message transfer, the DCE and DTE switch roles in sending and receiving messages. For BIDIRECTIONAL message transfer, each direction works independently and both DCE and DTE can send and receive. The rules of the basic protocol need to be followed in order to achieve graceful shutdown: the sender behaves like the DTE in the basic protocol and the receiver like the DCE in the basic protocol. If a message is received in the wrong direction, the receiving application should disconnect with code PRTCOLERR. This option will affect other protocol options, which are dependent upon the direction of message transfer. MOTIVATION Inter-application communication often requires OUTPUT and BIDIRECTIONAL message transfer, not just INPUT message transfer. The MODE protocol option extends the basic protocol in order to support this functionality. NEGOTIATION DTE and DCE may support one or more modes (INPUT, OUTPUT or BIDIRECTIONAL). The resultant mode is obtained by negotiating the supported modes in DTE's order of preference. Initially, INPUT is assumed. Then, the two negotiate and assume the final mode returned by DCE. If the DTE only supports INPUT message transfer, INPUT is assumed and negotiation does not take place. If the DTE would like to use BIDIRECTIONAL message transfer, it sends "DO MODE BIDIRECTIONAL": <193x033x003x255x254> --> If the DCE supports BIDIRECTIONAL message transfer, it responds "WILL MODE BIDIRECTIONAL" and BIDIRECTIONAL message transfer becomes agreed: <- <195><033x003x255x254> Otherwise, if the DCE does not support BIDIRECTIONAL message transfer, it responds "WONT MODE" and INPUT message transfer remains agreed: <- <196x033x255x254> If the DTE or DCE does not support BIDIRECTIONAL message transfer and the DTE would like to use OUTPUT message transfer, the DTE sends "DO MODE OUTPUT": <193x033x002x255x254> -> If the DCE supports OUTPUT message transfer, it responds "WILL MODE OUTPUT" and OUTPUT message transfer becomes agreed: <- <195x033x002><255><254> Otherwise, if the DCE does not support OUTPUT message transfer, it responds "WONT MODE" and INPUT message transfer remains agreed: <-- <196x033x255x254> If the application des not support the resultant mode, it should disconnect using code INSNEGOPT. PARAMETERS { mode } Mode is an unsigned byte, which indicates the direction of message transfer. Possible values are 3 for BIDIRECTIONAL or 2 for OUTPUT. Any other value is invalid. EXAMPLES DTE supports BIDIRECTIONAL, OUTPUT and INPUT; DCE supports OUTPUT; they agree OUTPUT. <193x033x003x255x254> -> <- <196x033x255x254> <193x033x002x255x254> -> <- <195x033x002x255x254> DTE supports OUTPUT; DCE does not understand the MODE option and only supports INPUT; they agree INPUT. The DTE subsequently disconnects. <193x033x002x255x254> --> <- <196x033x255x254> DTE supports BIDIRECTIONAL; DCE supports INPUT; they agree INPUT. The DTE subsequently disconnects. <193x033x003x255x254> --> <- <196x033x255x254> DTE supports INPUT; DCE supports BIDIRECTIONAL; they agree INPUT. The DCE subsequently disconnects. Negotiation does not take place. Two negotiations are rarely needed, since the DTE normally supports just one direction of message transfer. 3.02 NOREPLY IDENTIFICATION Name: NOREPLY, Code = 34 Dependencies: MODE OVERVIEW The NOREPLY protocol option turns off message replies. In the basic protocol, a MESSAGE-REPLY is expected for every MESSAGE sent. When this option is in effect, message replies are not used. This option can be used with any mode (INPUT, OUTPUT or BIDIRECTIONAL). With BIDIRECTIONAL message transfer, applications can provide synchronisation at the application level. With INPUT or OUTPUT message transfer, applications fire and forget. If delivery confirmation is not required, message transfer without RACE or application level replies may prove efficient. Care must be taken when programming the application interface, as an application cannot read beyond its number of available message buffers. Once the number of available buffers has been exceeded, the application must stop reading the packet stream. It can start reading again when one or more buffers become available. It should also be noted that a DISCONNECT packet may be waiting in the packet stream. If a message reply is received and replies have been disabled, the receiving application should disconnect with code PRTCOLERR. This option will affect other protocol options, which are dependent upon the existence of message replies. The MODE option should be negotiated before the NOREPLY option. MOTIVATION Many application level protocols use application specific replies and some applications fire and forget messages. In conjunction with the MODE option, this option extends RACE to a wide variety of applications and application level protocols. When given the choice though, it is preferable to map an application level protocol with RACE message replies rather than layer an application level protocol without RACE message replies. NEGOTIATION NOREPLY is negotiated separately for input and output message transfer. If the DTE would like to disable message replies (for the input stream), it sends "DO NOREPLY": <193x034x255x254> -> If the DCE can disable message replies (for the input stream), it responds "WILL NOREPLY": <- <195x034x255x254> Otherwise, if the DCE cannot disable message replies (for the input stream), it responds "WONT NOREPLY": <- <196x034x255x254> If the DTE can disable message replies (for the output stream), it sends "WILL NOREPLY": <195x034x255x254> -> If the DCE would like to disable message replies (for the output stream), it responds "DO NOREPLY": <- <193x034x255x254> Otherwise, if the DCE does not want to disable message replies (for the output stream), it responds "DONT NOREPLY": <- <194x034x255x254> PARAMETERS None. EXAMPLES Mode is BIDIRECTIONAL; DTE and DCE agree to turn off message replies: <193x034x255x254> -> <195x034x255x254> -> <- <195x034x255x254> <- <193x034x255x254> Mode is BIDIRECTIONAL; DTE wants to turn off message replies, but DCE needs them enabled. Message replies are disabled for the input stream and enabled for the output stream: <193x034x255x254> -> <195x034x255x254> -> <- <195x034x255x254> <- <194x034><255><254> 3.03 WINDOW IDENTIFICATION Name: WINDOW, Code = 37 Dependencies: MODE, NOREPLY OVERVIEW The WINDOW protocol option permits more than one message to be sent without waiting for a message reply. The term window refers to the number of outstanding messages for which a message reply has not been received. A small window of about three greatly increases performance. A large window does not give much improvement. A window of one represents the default behaviour of the basic protocol. If replies have been disabled, this option has no effect. If the link fails, the other party might not have received all of the messages in the window. MOTIVATION By default, a message reply has to be received before the next message can be sent. This wastes time. Data transfer is much faster if multiple messages can be prepared and sent before a reply is received. This allows the receiver to process messages whilst the sender is preparing and sending messages, and messages or message replies are in transit. NEGOTIATION WINDOW is negotiated separately for input and output message transfer. If the DTE would like to use a window size greater than one (for the input stream), it sends "DO WINDOW" and specifies the desired window size: < 193><037> { window-size } <255><254> -> If the DCE supports windowing (for the input stream), it responds "WILL WINDOW" with the actual window size. The actual window size should be lower than or equal to the requested window size: <- < 195x037> { window-size } <255x254> Otherwise, if the DCE does not support a window greater than one (for the input stream), it responds "WONT WINDOW": <- <196x037x255x254> If the DTE supports windowing (for the output stream), it sends "WILL WINDOW" with its maximum window size: < 195x037> { window-size } <255x254> --> If the DCE would like to use a window size greater than one (for the output stream), it responds "DO WINDOW" with the actual window size. The actual window size must be lower than or equal to the offered window size. <- < 193x037> { window-size } <255><254> Otherwise, if the DCE does not want to use windowing (for the output stream), it responds "DONT WINDOW": <-- <194x037x255x254> If either party does not support windowing, a window size of one is assumed (the default). PARAMETERS {window-size} The window size is an unsigned byte containing any value in the range 1 to 127 inclusive. Values outside the range are not allowed. EXAMPLES Mode is INPUT; DTE wants an input window of 10; DCE supports an input window of 3. They agree to use an input window of 3. <193x037x010x255x254> -> <- <195x037x003x255x254> Mode is OUTPUT; DTE supports an output window of 2; DCE does not understand this option and only supports an output window of 1. They agree to use an output window of 1. <195x037x002x255x254> -> <- <194x037x255x254> Mode is BIDIRECTIONAL; DTE supports an input window of 3 and an output window of 3; DCE supports an input window of 2 and an output window of 1. They agree to use an input window of 2 and an output window of 1. <193x037x003x255x254> -> <195x037x003x255x254> --> <- <195><037x002x255x254> <- <193x037x001x255x254> (DONT can also be used here) 3.04 SEQNO [SEQUENCE NUMBER] IDENTIFICATION Name: SEQNO, Code = 38 Dependencies: MODE, NOREPLY OVERVIEW The Sequence Number (SEQNO) protocol option allows messages and message replies to be numbered in the order in which they are transmitted. If agreed, the sending party must include an incremental sequence number with every message sent and the receiving party must include the same sequence number in each corresponding message reply. It is the responsibility of the message receiver to check the sequence numbering of messages and it is the responsibility of the message sender to check the sequence numbering of message replies. F10 is included in the MESSAGE and MESSAGE-REPLY packets in order to detail the sequence number. F10 contains an unsigned short integer in network byte order. Sequence numbers start at one at the beginning of a new connection, increment by one, and wrap back to one upon reaching 65,536 (i.e. 65,536, 131,071, ... become 1). Zero is not a valid sequence number. Data byte 255 must be doubled. Each party maintains a separate sequence number counter for each direction of message transfer. For example, <200x255x010x000x021x255x064>MY MESSAGE<255><254> -> <- <201x255x010x000x021><255><254> Here, the message and the positive message reply have sequence number twenty- one. Sequence numbers are only used to check the sequencing of messages and message replies during a connection. There is no point in storing the sequence number with the message after transmission or upon receipt. If an invalid sequence number is encountered for a message or a message reply, the application, which detected the error, should disconnect with code INVSEQNO. MOTIVATION Sequence numbering is not generally necessary, because RACE assumes a reliable transport. Message replies are returned in the order in which messages are received. However, it is often asked or expected for a RACE connection to support sequence numbering. So, this option allows for it. By default, sequence numbering is not used in order to keep transmissions efficient. NEGOTIATION If the DTE can offer sequence numbering (for all directions of message transfer), it sends "WILL SEQNO": <195x038x255x254> -> If the DCE wants sequence numbering (for all directions of message transfer), it replies "DO SEQNO": <- <193x038x255x254> Otherwise, the DCE replies "DONT SEQNO": <- <194x038x255x254> If the DTE wants sequence numbering (for all directions of message transfer), it sends "DO SEQNO" instead of "WILL SEQNO": <193x038x255x254> -> If the DCE can offer sequence numbering (for all directions of message transfer), it replies "WILL SEQNO": <- <195x038x255x254> Otherwise, the DCE replies "WONT SEQNO": <- <196x038x255x254> In order to keep transmissions efficient, applications need only offer SEQNO, but not request it. PARAMETERS None. EXAMPLES Both DTE and DCE support sequence numbering, but neither mandate sequence numbering. Sequence numbering is not used. <195x038x255x254> --> <- <194x038x255x254> DTE mandates sequence numbering, but DCE does not support it. Sequence numbering is not used. <193x038x255x254> -> <- <196x038x255x254> DTE supports sequence numbering and DCE mandates it. Sequence numbering is used. <195x038x255x254> --> <- <193x038x255x254> 3.05 PDE [POSSIBLE DUPLICATE EMISSION] IDENTIFICATION Name: PDE, Code = 53 Dependencies: MODE OVERVIEW The Possible Duplicate Emission (PDE) protocol option allows use of a PDE flag. Once enabled, the sender must include the PDE flag with messages, which may have already been sent. Likewise, the receiver must treat messages as possible duplicates if the PDE flag is present. F65 is included in the MESSAGE packet in order to indicate the PDE flag. F65 is an unsigned byte containing a binary one. For example, <200x255x064>Testing l23<255x065x001x255><254> The presence of F65 indicates that this MESSAGE is a possible duplicate emission. An application should only agree to use the PDE flag if it can properly detect or process the PDE flag. If F65 is encountered when this option is not in effect, the receiving application should disconnect with code INVPKTFID. MOTIVATION This option facilitates the detection of duplicate transmissions. Some application level protocols support the use of a PDE flag. This option allows RACE to be better mapped to these protocols. NEGOTIATION PDE is negotiated separately for input and output message transfer. If the DTE can provide the PDE flag (for the input stream), it sends "WILL PDE": <195x053x255x254> -> If the PDE information is useful to the DCE (for the input stream), it responds "DO PDE": <- <193x053x255x254> Otherwise, if the DCE does not want to receive PDE information (for the input stream), it responds "DONT PDE": <- <194x053x255x254> If the PDE information is useful to the DTE (for the output stream), it sends "DO PDE": <193x053x255x254> -> If the DCE can provide the PDE flag (for the output stream), it responds "WILL PDE": <-- <195x053x255x254> Otherwise, if the DCE cannot provide the PDE flag (for the output stream), it responds "WONT PDE": <- <196x053x255x254> PARAMETERS None. EXAMPLES Mode is BIDIRECTIONAL; Both DTE and DCE support PDE. <195x053x255x254> -> <193x053x255x254> -> <- <193x053x255x254> <~ <195x053x255x254> Mode is INPUT; DTE supports PDE, but DCE does not. <195x053x255x254> --> <-- <194x053x255x254> 3.06 RREF [RECEIVER REFERENCE] IDENTIFICATION Name: RREF, Code = 54 Dependencies: MODE, NOREPLY OVERVIEW The Receiver Reference (RREF) protocol option allows the message sender to get a unique identifier from the receiver for each message sent. This assists in investigation and reconciliation. Once agreed, the message receiver returns a unique message reference for every message using the MESSAGE-REPLY packet. F24 is included in the MESSAGE-REPLY packet in order to return the unique message reference. F24 may contain 1 to 64 ASCII characters, byte value 32 through 126 inclusive. As a matter of good practise, it is recommended to keep the reference to alphanumeric characters without leading or training spaces. For example, <201x255x024>DEF200105106E059<255><254> F24 in this MESSAGE-REPLY packet contains "DEF200105106E059", which uniquely identifies the received message. If a message is rejected, a unique message reference is still expected. If the receiving application does not allocate references for rejected messages, a pseudo reference should be used. For example, use the date and a counter that spans the day and is specific to the connection. References should be unique even if multiple application instances are used or different connections share the same application. If replies have been disabled, this option has no effect. MOTIVATION Many applications store transactions using a primary key or a transaction reference number. Sometimes, this information is needed by the sending application for subsequent investigation and reconciliation. A unique message reference is evidence that message transfer has taken place. NEGOTIATION RREF is negotiated separately for input and output message transfer. If the DTE would like to receive RREF (for the input stream), it sends "DO RREF": <193><054x255x254> --> If the DCE can supply RREF (for the input stream), it responds "WILL RREF": <-- <195x054x255x254> Otherwise, if the DCE cannot supply RREF (for the input stream), it responds "WONT RREF": <-- <196><054x255x254> If the DTE can supply RREF (for the output stream), it sends "WILL RREF": <195x054x255x254> -> If the DCE would like to receive RREF (for the output stream), it responds "DO RREF": <-- <193x054x255x254> Otherwise, if the DCE does not want to receive RREF (for the output stream), it responds "DONT RREF": <-- <194x054x255x254> PARAMETERS None. EXAMPLES Mode is BIDIRECTIONAL; DTE wants RREF, but can't offer it; DCE doesn't want RREF, but can offer it. <193x054x255x254> -> <- <195x054x255x254> Mode is INPUT; DTE wants RREF; DCE doesn't support this option and can't offer it: <193x054x255x254> --> <- <196x054x255x254> Mode is OUTPUT; DTE can offer RREF; DCE doesn't want RREF. <195x054x255x254> --> <- <194x054x255x254> 3.07 LGIAUTH [LOGIN AUTHENTICATION] IDENTIFICATION Name = LGIAUTH, Code = 65 Dependencies: n/a OVERVIEW The Login Authentication (LGIAUTH) protocol option allows applications to authenticate each other when the connection is opened. The authentication keys and identification of the authentication algorithm are agreed and distributed by some other means. Both applications can be authenticated separately. The requesting application sends a string to the other application for authentication. The other application calculates and returns an authentication code. The requesting application then calculates the authentication code again and compares it with the received authentication code. If the codes match, authentication passes. If authentication fails, the application, which expected to receive an authentication code, can either abort the connection immediately or wait until the end of negotiation. In either case, the authenticating application should send DISCONNECT with code LGIFAIL. MOTIVATION By default, a RACE connection is not secure. This option allows two co-operating applications to authenticate access. NEGOTIATION If the DTE can supply login authentication, it sends "WILL LGIAUTH": <195x065x255x254> --> If the DCE would like to receive login authentication, it responds "DO LGIAUTH" with a string for the DTE to authenticate: <- < 193x065> { auth-str } <255><254> Otherwise, if the DCE does not want to receive login authentication, it responds "DONT LGIAUTH": <- <194x065x255x254> If the DCE has agreed to receive login authentication, the DTE then sends "HERE- IS LGIAUTH" with its computed authentication code for the supplied authentication string: < 197><065> { auth-code } <255><254> --> If the DTE would like to receive login authentication, it sends "DO LGIAUTH" with a string for the DCE to authenticate: <193x065>{ aufh-str}<255><254> --> If the DCE can supply login authentication, it responds "WILL LGIAUTH" and then sends "HERE-IS LGIAUTH" with its computed authentication code for the supplied authentication string: <- < 195x065x255x254> <-- < 197><065x { auth-code } <255><254> Otherwise, if the DCE cannot supply login information, it responds "WONT LGIAUTH": <- <196><065x255x254> PARAMETERS {auth-str} Authentication string may contain 1 to 1024 unsigned bytes depending upon the authentication algorithm. Data byte 255 must be doubled. {auth-code} Authentication code may contain 1 to 64 unsigned bytes depending upon the authentication algorithm. Data byte 255 must be doubled. EXAMPLES DTE supplies login authentication to DCE: <195x065x255x254> -> <- <193x065>TODAY IS 20000828<255><254> <197x065>E06720587801C331<255><254> ~> DTE supplies login authentication to DCE, but DCE does not want it: <195x065x255x254> -> <- <194x065x255x254> 3.08 MSGAUTH [MESSAGE AUTHENTICATION] IDENTIFICATION Name: MSGAUTH, Code = 66 Dependencies: MODE OVERVIEW The Message Authentication (MSGAUTH) protocol option allows applications to authenticate messages. The authentication keys and identification of the authentication algorithm are agreed and distributed by some other means. Once agreed, the applications calculate a message authentication code (MAC) for every message, based upon the contents of the message, the keys and the algorithm. A separate key or the same key can be used for sending and receiving. The sending application calculates the MAC and adds it to the MESSAGE packet. The receiving application calculates the MAC again and compares it with the MAC in the received MESSAGE packet. If they match, the message passes authentication. Otherwise, the message fails authentication and is not processed. The MAC protocol option allows co-operating applications to check the authenticity and integrity of messages. It does not guarantee confidentiality. F66 is included in the MESSAGE packet in order to add the authentication code. F66 contains 1 to 64 unsigned bytes depending upon the authentication algorithm. For example, <200><255x064>Hello World! <255x066xl34xl61x003x255x255x201xl93x255x254> This message contains a 48-bit authentication code, hex value "86A103FFC9C1". If authentication fails, the message should not be processed. The receiving application should abort the connection by sending DISCONNECT with code AUTFAIL. MOTIVATION By default, a RACE connection is not secure. This option allows two co-operating applications to check the authenticity and integrity of messages. NEGOTIATION If the DTE can supply message authentication (for the input stream), it sends "WILL MSGAUTH": <195x066x255x254> -> If the DCE would like to authenticate messages (for the input stream), it responds "DO MSGAUTH": <- <193x066x255x254> Otherwise, if the DCE does not want to authenticate messages (for the input stream), it responds "DONT MSGAUTH": <- <194x066x255><254> If the DTE would like to authenticate messages (for the output stream), it sends "DO MSGAUTH": <193x066x255x254> -> If the DCE can supply message authentication (for the output stream), it responds "WILL MSGAUTH": <- <195x066x255x254> Otherwise, if the DTE cannot supply message authentication (for the output stream), it responds "WONT MSGAUTH": <- <196x066x255x254> PARAMETERS None. EXAMPLES DTE and DCE agree to authenticate messages for the input stream: <195x066x255x254> -> <- <193x066x255x254> DTE and DCE agree to authenticate messages in both directions: <195x066x255x254> -> <193x066x255x254> -> <- <193x066x255x254> <- <195x066x255x254> DTE would like to authenticate messages in both directions, but DCE does not understand this option: <195x066x255x254> --> <193x066x255x254> -> < „ <194x066x255x254> <- <196x066x255x254> 3.09 LGRP [LOGICAL GROUPING] IDENTIFICATION Name = LGRP, Code = 72 Dependencies: MODE OVERVIEW The Logical Grouping (LGRP) protocol option allows messages to be grouped and processed as a single unit of work. Once enabled, the sender can group consecutive messages together or continue to send individual messages like in the basic protocol. F67 is included in the MESSAGE packet in order to add the logical grouping information. F67 contains the logical group position, as an unsigned byte. It is included in the first and last messages in order to delimit the beginning and end of a group. The first message is assigned position 1 and the last message is assigned position 2. F67 is not used in intermediate messages. Sequence numbering within a logical group is not used, because a reliable connection is assumed. For example, <200x255x064>MSG-l<255x067x001x255x254> <200x255x064>MSG-2<255><254> <200x255x064>MSG-3<255><254> <200x255x064>MSG-4<255x067x002x255><254> <200x255x064>MSG-5<255><254> <200x255x064>MSG-6<255x067x001 x255x254> <2O0x255x064>MSG-7<255x254> <200><255x064>MSG-8<255x067x002x255><254> This input contains three logical groups. The first group contains four messages (MSG-1, MSG-2, MSG-3 and MSG-4). The second group contains only one message (MSG-5). The third group contains three messages (MSG-6, MSG-7 and MSG-8). If a logical group contains only one message, F67 is not used and a single message is put as per the basic protocol. Message replies, if enabled, are expected for every message sent. Windowing is allowed. A logical group becomes acknowledged after the last message in the group has been acknowledged. The group is then processed as a single unit of work. If one or more messages in a logical group are rejected, the whole group is rejected and subsequently not processed. The LGRP protocol option does not alter the use of the SEQNO protocol option. MOTIVATION It is sometimes necessary or practical to group messages together in order to process them as a logical whole. For example, if messages are read from a batch file, it is desirable to deliver them together. If a group of messages form a transaction, they need to be processed together so that, if one part fails, the whole transaction can be rolled back. NEGOTIATION Usage of logical grouping is negotiated separately for input and output message transfer. If the DTE would like to use logical grouping (for the input stream), it sends "DO LGRP": <193x072x255x254> -> If the DCE supports logical grouping (for the input stream), it replies "WILL LGRP": <-- <195><072x255x254> Otherwise, if the DCE does not support logical grouping (for the input stream), it replies "WONT LGRP": <-- <196x072x255><254> If the DTE supports logical grouping (for the output stream), it sends "WILL LGRP": <195x072x255x254> -> If the DCE would like to use logical grouping (for the output stream), it replies "DO LGRP": <-- <193x072x255x254> Otheriwse, if the DCE does not want to use logical grouping (for the output stream), it replies "DONT LGRP": <- <194><072x255x254> PARAMETERS None. EXAMPLES Mode is BIDIRECTIONAL; Both DTE and DCE support LGRP. <193x072x255><254> --> <195x072x255x254> -> <- <195x072x255x254> <- <193x072x255x254> Mode is INPUT; DTE supports LGRP, but DCE does not. <193x072x255x254> --> <- <196x072x255x254> 3.10 MSGLEN [MESSAGE LENGTH] IDENTIFICATION Name: MSGLEN, Code = 78 Dependencies: MODE OVERVIEW The Message Length (MSGLEN) protocol option allows the message length to be included in a MESSAGE packet. Depending upon negotiation, the message length can be included either before or after F64 (the message contents). F63 is included in the MESSAGE packet in order to add the message length. F63 is an unsigned long integer in network byte order. So, the maximum message length is 4,294,967,295 bytes (4GB) when this option is in effect. For example, The message length prefixed: <200x255x063xO00x000x0O0x016> <255><064>I HAVE 16 BYTES.<255x254> The message length suffixed: <200><255x064>I HAVE 16 BYTES. <255><063x000xO00x0O0x016x255><254> If the message receiver detects that the actual message length does not match the message length specified in F63, it should disconnect with code LNVMSGLEN. MOTIVATION If the message length is sent with the message, the receiving application can check the actual message length. If the message length is included before the message content, the receiving application can allocate space for the message in advance. For large message transfers, this can increase performance, because the receiving application can pre-allocate contiguous space. However, it may be difficult for the sending application to know the message length in advance or it may hinder performance for the sending application to determine the message length in advance. In addition, the size of F63 can degrade performance when many small messages are being transferred. NEGOTIATION If the DTE can provide the message length (for the input stream), it sends "WILL MSGLEN" and whether it can prefix or suffix it ( 1 , 2): <195x078>{prefix-suffix}<255><254> ~> If the DCE would like to receive the message length (for the input stream), it replies "DO MSGLEN" and whether to prefix or suffix it (1, 2). The DCE can only ask for the message length to be prefixed if the DTE has offered to prefix it. The DCE can ask for the message length to be suffixed in either case. <- < 193x078> { prefix-suffix } <255><254> Otherwise, if the DCE does not want to receive the message length (for the input stream), it replies "DONT MSGLEN": <- <194x078x255x254> If the DTE would like to receive the message length (for the output stream), it sends "DO MSGLEN" and whether to prefix or suffix it (1, 2): < 193x078> { prefix-suffix } <255><254> -> If the DCE can provide the message length (for the output stream), it replies "WILL MSGLEN" and whether it can prefix or suffix it (1, 2). The DCE should only offer to prefix the message length if the DTE has requested it to be prefixed. If the DTE has requested the message length to be prefixed and the DCE can only suffix it, the DCE should agree to suffix it. The DTE can then determine how it wants to proceed. <-- < 195x078x { prefix-suffix } <255x254> Otherwise, if the DCE cannot provide the message length (for the output stream), it replies "WONT MSGLEN": <-- <196x078x255x254> PARAMETERS {prefix-suffix} The prefix-suffix parameter is an unsigned byte containing 1 to prefix or 2 to suffix. EXAMPLES Mode is BIDIRECTIONAL; DTE can prefix MSGLEN and would like to receive MSGLEN prefixed; DCE can prefix MSGLEN, but is not interested in receiving it; they agree to prefix MSGLEN from DCE to DTE. <195x078x001x255x254> --> <193x078x001x255x254> -> <- <194x078x255x254> <- <195x078x001x255x254> Mode is INPUT; DTE can suffix MSGLEN; DCE would like to receive MSGLEN prefixed; they agree not to use MSGLEN (because the DTE cannot prefix it). <195x078x002x255x254> -> <- <194x078x255x254> 3.11 BATCH IDENTIFICATION Name: BATCH, Code = 41 Dependencies: MODE OVERVIEW The BATCH protocol option supports the transfer of sequential data files between applications. Typically, messages are written to the batch file by one program and then the batch file is transferred to another program. BATCH disables standard message transfer and enables batch file transfer. The MESSAGE packet is used to convey the batch file and the MESSAGE-REPLY packet for acknowledgement. The contents are transferred using F64 and the header is prefixed using F91 and F92. F91 is mandatory and details the filename. F92 is optional and details the creation date and time of the file in Greenish Meantime. If possible, the MSGLEN protocol option should be negotiated in order to include F63, the file size. If F63 is included, the receiving application can check the size of the received file. If F63 is included before the file contents, the receiving application can pre-allocate contiguous space and speed up the file transfer. The maximum file size is 4,294,967,295 bytes (4GB). The data file can contain any binary data. Data byte 255 must be doubled. However, applications normally agree to use ASCII and separate records using CRLF. Only sequential files are supported, since other formats are outside the scope of BATCH. For example, a file transfer: <200x255x091>PX2061.DAT<255x092>2002101510241600 <255><064>HERE ARE THE FILE CONTENTS. <255><254> -> <- <201x255x254> File PX2061.DAT, created at 10:24am on the 15 th October 2002, is transferred. The BATCH protocol option should be negotiated before the MODE protocol option. MOTIVATION Many existing or simple systems use batch files for message processing and transfer. NEGOTIATION BATCH usage is the same for input and output data transfer. Once enabled, batch file transfer replaces standard message transfer. If the DTE would like to use batch, it sends "DO BATCH": <193x041x255x254> --> If the DCE supports batch, it replies "WILL BATCH": <- <195x041x255x254> Otherwise, if the DCE does not support batch, it replies "WONT BATCH": <- <196x04 Ix255x254> If the DTE can offer batch, it sends "WILL BATCH": <195x041x255x254> -> If the DCE would like to use batch, it replies "DO BATCH": <- <193x041x255x254> Otherwise, if the DCE does not want to use batch, it replies "DONT BATCH": <- <194x04 Ix255x254> PARAMETERS None. EXAMPLES DTE would like to use BATCH; DCE supports BATCH; they agree to use BATCH. <193x041x255x254> -> <- <195x041x255x254> DTE would like to use BATCH; DCE does not support BATCH; they do not use BATCH. <193x041x255x254> -> <- <196x041x255x254> 3.12 NOM [NUMBER OF MESSAGES] IDENTIFICATION Name: NOM, Code = 42 Dependencies: MODE OVERVIEW The Number of Messages (NOM) option allows either party to determine the number of messages that are waiting to be downloaded at the time of negotiation. If the DTE wants to know or can offer the number of pending messages, it negotiates with the DCE. If agreed, the DTE sends its number of pending messages and/or the DCE sends its number of pending messages. It should be noted that the number of messages returned using this protocol option may be less than or more than the actual number of messages transferred. MOTIVATION Sometimes, it is desirable to display or know the number of messages that are waiting to be downloaded before they are actually downloaded. This option allows the number of messages to be known before data transfer is agreed and entered into. If no messages are pending, this option allows the other party to quickly disconnect, as it would otherwise have to wait for a timer to expire. For example, consider a message output program with user intervention. The message output program connects to an output message queue and retrieves the number of pending messages. It displays the number of messages to the user and asks whether the user wishes to download the messages. If the user agrees, the program enters into message transfer. Otherwise, the program disconnects. In this example, the program will need to watch that the connection does not timeout if the user does not respond immediately. NEGOTIATION If the DTE wants to know the number of pending messages (for the output stream), it sends "DO NOM": <193x042x255x254> -> If the DCE can offer the number of pending messages (for the output stream), it replies "WILL NOM" and then sends "HERE-IS NOM": <- <195x042x255x254> <- < 197><042> { number-of-messages } <255><254> Otherwise, if the DCE cannot offer the number of pending messages (for the output stream), it replies "WONT NOM": <- <196x042x255x254> If the DTE can offer the number of pending messages (for the input stream), it sends "WILL NOM": <195x042><255><254> --> If the DCE would like to know the number of pending messages (for the input stream), it replies "DO NOM": <-- <193x042x255x254> The DTE then sends "HERE-IS NOM" with the number of messages: < 197><042x { number-of-messages } <255><254> Otherwise, if the DCE does not want to know the number of pending messages (for the input stream), it replies "DONT NOM": <- <194x042x255x254> PARAMETERS { number-of-messages } The number of pending messages is an unsigned long integer in network byte order. If a party supports this option but cannot determine the number of messages, it returns a value of minus one (4,294,967,295) as the number of pending messages. If a party has no messages to send, the queue is empty, or mode does not permit sending messages, it returns a value of zero as the number of pending messages. If a party has 4,294,967,295 or more messages to send, it returns a value of 4,294,967,295 as the number of pending messages. I.e. it cannot determine the number of pending messages. Data byte 255 must be doubled. EXAMPLES Mode is OUTPUT; DCE agrees to give DTE the number of pending messages. <193x042><255><254> -> <-- <195x042x255x254> <~ <197x042xOOOxOO0xO0OxOO0><255><254> In this case, the DCE has no messages to transfer to DTE. 3.13 BIGFOOT [BIG CODE NUMBERING] IDENTIFICATION Name: BIGFOOT, Code = 82 Dependencies: n/a OVERVIEW The Big Code Numbering (BIGFOOT) protocol option extends the basic protocol in order to support a greater number of packet, field and option codes. When this option is in effect, identification of packets, fields and options can span one or two bytes. A value of 253 in the first byte indicates that the next two bytes contain the code number in network byte order. For example, consider the following WILL packet: <195x253x003x002x255x254> This WILL packet identifies option code 770 and does not contain any parameter data. For example, consider the following MESSAGE packet: <200x255x064>HELLO<255x253x201x255>C256<255><254> This MESSAGE packet contains two field ids: 64 and 51711. Field 64 contains "HELLO". Field 51711 contains "C256". For example, consider the following packet: <253x001x021x255x254> This packet has packet id 277, but does not contain any fields or data. Under this scheme, code values 253, 254 and 255 can be represented using the 2-byte code value. For example, <253xOOO><253>. This option gives 65,536 possible code values for fields, options and packets. Within the 2- byte code value, byte value 255 should not be doubled. MOTIVATION It is quite likely that the number of codes offered by a single byte will be exhausted some time in the future. This option recommends a preferred method for higher code numbering. NEGOTIATION If the DTE can offer big code numbering, it sends "WILL BIGFOOT": <195x082x255x254> -> If the DCE would like to use big code numbering, it replies "DO BIGFOOT": <-- <193x082x255x254> Otherwise, if the DCE does not want to use big code numbering, it replies "DONT BIGFOOT": <-- <194x082x255><254> If the DTE would like to use big code numbering, it sends "DO BIGFOOT": <193x082x255x254> -> If the DCE can offer big code numbering, it replies "WILL BIGFOOT": <- <195x082x255x254> Otherwise, if the DCE cannot offer big code numbering, it replies "WONT BIGFOOT": <- <196x082><255><254> The DTE need only negotiate this option if it plans to use higher numbered codes. PARAMETERS None. EXAMPLES DTE and DCE agree to use big code numbering. <193x082x255x254> -> <- <195x082x255x254> PAGE INTENTIONALLY LEFT BLANK PACKET SYNTAX The following packet codes are defined: NAME CODE MEANING CONNECT 192 Connect request DO 193 Request / agree protocol option DONT 194 Deny protocol option WILL 195 Offer / agree protocol option WONT 196 Refuse protocol option H HEERREE--IISS 1 19977 Sub negotiation READY 198 Ready DISCONNECT 199 Quit / shutdown request MESSAGE 200 Data message MESSAGE-REPLY 201 Logical reply This chapter describes each packet. All other codes are reserved for future use. The following codes have specific meaning when prefixed by the IAC byte within a RACE packet: NAME CODE MEANING END-OF-PACKET 254 End of packet (EOP). IAC 255 Data byte 255. FIELD-IDENTITY 000...253 Field id and separation (FID). The next chapter describes each field. Not all of the field identity codes are used. Unused field identity codes are reserved for future use, which includes usage other than for field identification. The packet descriptions now follow. CONNECT CONNECT is sent by DTE in order to specify and connect to a target DCE service and application. SYNTAX MEANING <192> Start of packet (192) <255><031 > { service-id } F31 - Target service [<255x032>{apρl-id} F32 - Target application [<255x033>{appl-id}]] F33 - User identifier <255><254> EOP - End of packet DESCRIPTION See the basic protocol. DO DO is sent by DTE in order to request a protocol option according to the option specification. DO is sent by DCE, after receipt of WILL, in order to accept or negotiate a protocol option further according to the option specification. SYNTAX MEANING <193> Start of packet (193) { opt-code } Option code [{opt-params}] Option parameters <255><254> EOP - End of packet DESCRIPTION The DTE can send DO during option negotiation subject to the option specification. The DCE can only send DO after receipt of WILL from DTE. This packet does not use field notation. If field identifiers are needed for option parameters, the IAC byte should be doubled. For example, specify field 22 as <255><255><022>. Then, the default parser will interpret the field identification as data and pass <255><022> on as data for further interpretation. A secondary parser can then interpret <255><022> as a valid field identifier. {opt-code}, by position (2nd byte) Option code as an unsigned byte, value 0-255. Data byte 255 must be doubled. {opt-params}, by position (after {opt-code}) Option specific parameters in order to sub-negotiate the option. Depending upon the option specification, this argument is optional and contains a varying number of data bytes. Data byte <255> must be doubled. 1.01 DONT DONT is sent by DCE after receipt of WILL, in order to reject the option specified by WILL. SYNTAX MEANING <194> Start of packet (194) { opt-code } Option code <255><254> EOP - End of packet DESCRIPTION This packet does not use field notation. { opt-code } , by position (2nd byte) Option code as an unsigned byte, value 0-255. Data byte 255 must be doubled. WILL WILL is sent by DTE in order to offer a protocol option according to the option specification. WILL is sent by DCE, after receipt of DO, in order to accept or negotiate a protocol option further according to the option specification. SYNTAX MEANING <195> Start of packet (195) { opt-code } Option code [{opt-params}] Option parameters <255x254> EOP - End of packet DESCRIPTION The DTE can send WELL during option negotiation subject to the option specification. The DCE can only send WILL after receipt of DO from DTE. This packet does not use field notation. If field identifiers are needed for option parameters, the IAC byte should be doubled. For example, specify field 22 as <255><255><022>. Then, the default parser will interpret the field identification as data and pass <255><022> on as data for further interpretation. A secondary parser can then interpret <255><022> as a valid field identifier. {opt-code}, by position (2nd byte) Option code as an unsigned byte, value 0-255. Data byte 255 must be doubled. {opt-params}, by position (after {opt-code}) Option specific parameters in order to sub-negotiate the option. Depending upon the option specification, this argument is optional and contains a varying number of data bytes. Data byte <255> must be doubled. WONT is sent by DCE after receipt of DO, in order to reject the option specified by DO. SYNTAX MEANING <196> Start of packet (196) { opt-code } Option code <255x254> EOP - End of packet DESCRIPTION This packet does not use field notation. { opt-code } , by position (2nd byte) Option code as an unsigned byte, value 0-255. Data byte 255 must be doubled. 1.01 HERE-IS HERE-IS is sent by DTE or DCE in order to negotiate an option further according to an option specification. The option must have been agreed before HERE-IS can be used. SYNTAX MEANING <197> Start of packet (197) { opt-code } Option code [{opt-params}] Option parameters <255><254> EOP - End of packet DESCRIPTION This packet does not use field notation. If field identifiers are needed for option parameters, the IAC byte should be doubled. For example, specify field 22 as <255><255><022>. Then, the default parser will interpret the field identification as data and pass <255><022> on as data for further interpretation. A secondary parser can then interpret <255><022> as a valid field identifier. {opt-code}, by position (2nd byte) Option code as an unsigned byte, value 0-255. Data byte 255 must be doubled. {opt-params}, by position (after {opt-code}) Option specific parameters in order to sub-negotiate the option. Depending upon the option specification, this argument is optional and contains a varying number of data bytes. Data byte <255> must be doubled. READY READY is sent by DCE after receipt of CONNECT in order to accept the connection. READY is sent by DTE after negotiation in order to indicate that it has finished and is agreeable to option negotiation. READY is sent by DCE after receipt of READY in order to indicate that it is agreeable to option negotiation. DTE and DCE immediately enter into data transfer after the DCE has sent this packet following negotiation. SYNTAX MEANING <198> Start of packet (198) <255x254> EOP - End of packet DESCRIPTION See the basic protocol. DISCONNECT DISCONNECT is sent by DTE or DCE to request shutdown of the link. DISCONNECT is sent by DTE at the end of option negotiation in order to reject negotiation and close the link. DISCONNECT is sent by DCE after receipt CONNECT or READY, in order to reject a connect request or negotiation, and close the link. DISCONNECT is also sent by DTE or DCE after a protocol or unexpected error. SYNTAX MEANING <199> Start of packet (199) [<255x021>{code} F21 - Disconnect code [<255><023>{text}]] F23 - Additional information <255><254> EOP - End of packet DESCRIPTION When used to initiate or complete shutdown, DISCONNECT must convey SUCCESS (0). Otherwise, DISCONNECT is interpreted as an exception and blocks further communication. F21, the disconnect code argument, can be omitted when its value is SUCCESS (0). When omitted, SUCCESS (0) is assumed. If F23 is present, F21 must also be present. MESSAGE MESSAGE is sent in order to transfer an application data message. SYNTAX MEANING <200> Start of packet (200) [<255x010>{seqno}] F10 - Sequence number [<255x091>{fnamej F91 - Filename [<255><092> { fstamp } ]] F92 - File creation date and time [<255x063>{msglen}] F63 - Message length (prefixed) <255><064>{msg} F64 - Message [<255><063>{msglen}] F63 - Message length (suffixed) [<255x065>{pde}] F65 - PDE flag [<255x066>{mac}] F66 - MAC [<255x067>{lgrp}] F67 - LGRP position <255x254> EOP - End of packet DESCRIPTION By default, messages are sent from DTE to DCE. The MODE protocol option modifies this behaviour by allowing output (from DCE to DTE) and bi-directional message transfer. The SEQNO protocol option determines the usage of F10. When SEQNO is enabled, F10 is mandatory. Otherwise, F10 should not be present. The PDE protocol option determines the usage of F65. When PDE is enabled for the direction of message transfer, F65 may be present in order to indicate a possible duplicate emission. The MAC protocol option determines the usage of F66. When MAC is enabled for the direction of message transfer, F66 is mandatory. Otherwise, F66 should not be present. The LGRP protocol option determines the usage of F67. When LGRP is enabled for the direction of message transfer, F67 may be present in order to indicate the beginning or end of a logical group. The MSGLEN protocol option determines the usage of F63. When MSGLEN is enabled for the direction of message transfer, F63 is mandatory and details the message length. Depending upon negotiation of MSGLEN, F63 is either expected before or after F64, the message contents. The BATCH protocol option determines the usage of F91 and F92. When BATCH is enabled, F91 is mandatory and F92 may be optionally present. Otherwise, F91 and F92 should not be present. When BATCH is enabled, F64 is the contents of the file rather than a specific application message. MESSAGE-REPLY MESSAGE-REPLY is sent after receipt of MESSAGE in order to indicate successful or unsuccessful interpretation of the data message. SYNTAX MEANING <201> Start of packet (201) [<255x010>{seqno}] F10 - Sequence number [<255><021>{code} F21 - Reply code [<255><023>{text}]] F23 - Additional information [<255x024>{umr}] F24 - RREF <255x254> EOP - End of packet DESCRIPTION Code SUCCESS indicates a positive message reply and that the message was accepted. Otherwise, the reply is negative and the message was not accepted. By default, message replies are returned from DCE to DTE. The NOREPLY and MODE protocol options modify this behaviour. NOREPLY turns off message replies. MODE allows message replies to be returned from DTE to DCE or in both directions depending upon the direction of message transfer. The RREF protocol option determines the usage of F24. When RREF is enabled for the direction of message transfer, F24 is mandatory and contains a unique message reference. Otherwise, F24 should not be present. The SEQNO protocol option determines the usage of FIO. When SEQNO is enabled, FIO is mandatory. Otherwise, FIO should not be present. F21, the reply code argument, can be omitted when its value is SUCCCESS (0), in order to increase performance. When omitted, SUCCESS is assumed. If F23 is present, F21 must also be present. FIELD SYNTAX FIO, SEQUENCE NUMBER Usage: SEQNO (MESSAGE, MESSAGE-REPLY) Format: unsigned short int (in network byte order) Detail: Sequence numbers are applied to both messages and message replies. Separate counters are used for input and output message transfer. Sequence numbers start at one at the beginning of a new connection, increment by one, and wrap back to one upon reaching 65,536 (i.e. 65,536, 131,071, ... become 1). Zero is not a valid sequence number. F21, REPLY OR DISCONNECT CODE Usage: BASIC (DISCONNECT, MESSAGE-REPLY) Format: unsigned short int (in network byte order) Detail: See later in this documentation for details of reply and disconnect codes and their meanings. If F21 is omitted in DISCONNECT or MESSAGE-REPLY, SUCCESS is assumed. F23, ADDITIONAL INFORMATION Usage: BASIC (DISCONNECT, MESSAGE-REPLY) Format: char [256] Detail: Additional information is used to supplement the code in F21. This field contains 1 to 256 bytes and is application specific. Typically, ASCII, byte value 32 to 126 inclusive, is used. F24, UNIQUE MESSAGE REFERENCE (UMR) Usage: RREF (MESSAGE-REPLY) Format: char [32] Detail: The unique message reference (UMR) is comprised of 1 to 64 ASCII characters, byte value 32 through 126 inclusive. As a matter of good practise, it is recommended to keep the reference to alphanumeric characters without leading, trailing or embedded spaces. F31, TARGET SERVICE Usage: BASIC (CONNECT) Format: char [64] Detail: The DCE service identifier (protocol type). The identifier comprises 1 to 64 ASCII characters, byte value 32 to 126 inclusive. F32, TARGET APPLICATION Usage: BASIC (CONNECT) Format: char [64] Detail: The DCE application name (daemon, connection point, I/O queue name). The identifier comprises 1 to 64 ASCII characters, byte value 32 to 126 inclusive. F33, USER IDENTIFIER Usage: BASIC (CONNECT) Format: char [64] Detail: The DTE application name (user identifier, connection point, I/O queue name). The identifier comprises 1 to 64 ASCII characters, byte value 32 to 126 inclusive, like F32. F63, MESSAGE LENGTH Usage: MSGLEN (MESSAGE) Format: unsigned long int (in network byte order) Detail: The length of F64, the content of the message. F64, APPLICATION DATA MESSAGE Usage: BASIC (MESSAGE) Format: unsigned char [] Detail: A varying number of unsigned bytes, which are application specific. If the MSGLEN protocol option is in effect, the maximum message length is 4,294,967,295 bytes (4GB). F65, POSSIBLE DUPLICATE EMISSION (PDE) FLAG Usage: PDE (MESSAGE) Format: unsigned char Detail: F65 indicates a possible duplicate emission (PDE). It should contain a single byte, binary value one. F66, MESSAGE AUTHENTICATION CODE (MAC) Usage: MAC (MESSAGE) Format: unsigned char [64] Detail: F66 contains 1 to 64 unsigned bytes depending upon the authentication algorithm. F67, LOGICAL GROUPING (LGRP) POSITION Usage: LGRP (MESSAGE) Format: unsigned char Detail: The first message in a logical group is assigned position one and the last message is assigned position two. F67 is not used for intermediate messages. If a logical group contains only one message, F67 is not used and a single message is put as per the basic protocol. F91, FILENAME Usage: BATCH (MESSAGE) Format: char [64] Detail: The filename of the batch file. F91 contains 1 to 64 ASCII characters, limited to the following: lowercase and uppercase letters; digits; the dollar character; the underscore character; and the period (full stop) character. The period character should only occur once in the filename and is used to separate the name from the type suffix. F92, FILE CREATION DATE AND TIME STAMP Usage: BATCH (MESSAGE) Format: char [16] Detail: The creation date and time stamp of the batch file in Greenish Meantime. The stamp is 16 ASCII digits, format YYYYMMDDHHMMSSNN, where YYYYMMDD represents the year, month and day, and HHMMSSNN represents the hour, minute, second and hundredth second. If part of the stamp cannot be determined, for example the hundredth second, it should be filled with ASCII zero. N.B. DATA BYTE <255> MUST BE DOUBLED. REPLY CODES The following codes have been defined for MESSAGE-REPLY. Your application should be ready to support other codes, which have not yet been defined, in order to support future versions of the protocol. 0 SUCCESS, Normal successful completion Description: A valid message was received, interpreted and processed. This may include safe-storage for subsequent processing. SUCCESS is assumed when MESSAGE-REPLY does not contain a reply code. Action: The sending application can now update the message as sent. Responsibility for the message passes to the receiving application. 1001 ERROR, Error Description: This error code should not be sent in MESSAGE-REPLY. Rather, it is used to describe an unknown error code (not currently defined in this section) to the user or calling software. Action: Consider updating your software to support the latest protocol version. 2001 LNVMSG, Invalid message Description: An invalid message was received and, therefore, could not be processed. Action: Check the message for errors. If OK, review the logic of the receiving application. Check F23 for additional information. DISCONNECT CODES The following codes have been defined for DISCONNECT. Your application should be ready to support other codes, which have not yet been defined, in order to support future versions of the protocol. 0 SUCCESS, Normal successful completion Description: Either DTE or DCE has completed its processing and is requesting or confirming shutdown of the link. SUCCESS is assumed when DISCONNECT does not contain a disconnect code. Action: If initiating shutdown, wait for a corresponding DISCONNECT packet in order to close the link. Upon receipt of a shutdown request, complete any processing and return a corresponding DISCONNECT packet. The link can then be closed. 1001 ERROR, Error Description: This error code should not be sent in DISCONNECT. Rather, it is used to describe an unknown error code (not currently defined in this section) to the user or calling software. Action: Consider updating your software to support the latest protocol version. 3014 SRVNOTAVL, Service not available Description: The DCE received a CONNECT request, but the requested service was not available or unsupported. Action: Check the name of the service and whether it is supported. 3025 APPNOTAVL, Application not available Description: The DCE received a CONNECT request, but the requested application was not available or did not exist. Action: Check the name of the target application. 3036 APPBUSY, Application busy, retry later Description: The DCE received a CONNECT request, but the requested application is currently busy. Action: If the DCE application is shared, close the link and try again (possibly after a short delay). If the DCE application is not shared, check that another DTE instance is not running. 3047 APPNOTRDY, Application not ready, retry later Description: The DCE received a CONNECT request, but the requested application is not currently listening for new connections. Action: Close the connection and try again (using a short delay and a maximum number of retries). 3058 LGIFAIL, Login failure Description: Either DTE or DCE could not continue, because the login information was incorrect or insufficient. Action: Check the login information, authentication keys, authentication algorithm, and supported protocol options. 3069 AUTFAEL, Authentication failure Description: Either DTE or DCE could not continue, because message authentication failed. Action: Check the authentication keys, algorithm, and supported protocol options. 3080 INSNEGOPT, Insufficient negotiated options Description: Either DTE or DCE cannot continue with the negotiated protocol options. I.e. One party needed one or more protocol features, which the other party did not support. Action: The applications are incompatible. Change one of the applications. 3091 RESFAIL, Resource failure Description: A message was received, but a resource failed, which prevented the message from being processed. For example, the receiving application might have run out of disk space or memory. The message may or may not be valid. The message may or may not have been processed. Action: An operator will most probably need to investigate why the receiving application failed. Reopen the link once the receiving application has been fixed. 3102 PRTCOLERR, Protocol error Description: The application received a known packet type, but the packet was unexpected. For example, if the DTE was expecting READY or DISCONNECT, and received a MESSAGE, this would constitute a protocol error. Action: Check your application for programming errors. 3113 LNVPKTTYP, Invalid packet type Description: The application received an invalid packet type. I.e. the first byte of the packet was not a valid packet identifier. Action: Check your application for programming errors. Check that the underlying transport is reliable. 3124 PKTOVFBUF, Packet overflows buffer Description: The application received a packet, which exceeded its internal buffer size. Action: Specify a smaller packet or increase the internal buffer size of the application. If a message is bigger than the maximum message length (defined at application level), INVMSG should be returned by MESSAGE-REPLY rather than PKTOVFBUF by DISCONNECT. Ideally, applications should not restrict the packet size. 3135 TOOM ANFLD, Too many fields in packet Description: The other application received a packet, which had too many packet fields for its internal buffers. Action: Typically, this is an indication of a programming error, which has resulted in too many fields. Check your application. If the packet is correct, increase the internal buffers of the other application. 3146 LNVPKTFID, Invalid packet field identifier Description: The other application received a packet, which contained an invalid field identifier. Action: Check the applications for programming errors. Check that the underlying transport is reliable. 3157 INVPKTS YN, Invalid packet syntax Description: The other application received a packet, which had invalid syntax. For example, a field was not properly formatted, was out of order or was missing. Action: Check the applications for programming errors. 3168 TIMEOUT, Timeout Description: The other application was expecting a packet, but did not receive one within its timeout period. Action: Check your application for programming errors. Check that the timeout period is sufficient for the applications, the underlying transport and the network. 3179 LNVSEQNO, Invalid sequence number Description: The SEQNO protocol option was agreed and a message or message reply was encountered, which had an invalid sequence number. Action: Check the programs for sequencing errors. INVMSGLEN, Invalid message length Description: The MSGLEN protocol option was agreed and the message length in F63 did not agree with the actual message length in F64. Action: Check for programming errors. Check that the underlying transport is reliable. If a message is bigger than the maximum message length (defined at application level), INVSG should be returned by MESSAGE-REPLY rather than INVMSGLEN by DISCONNECT. SAMPLE TRANSMISSION Here is a sample communication between two applications. The DTE connects for output message transfer and downloads one message. The DTE then initiates a graceful shutdown. tl: <192x255x031>race$generic<255x032>TESTAPPL<255><254> cl: <198x255x254> t2: <193x033x002x255x254> <193x053x255x254> <195x054x255x254> c2: <195x033x002><255><254> <195x053x255x254> <194x054x255><254> t3: <198><255><254> c3: <198x255x254> c4: <200><255x064>HELLO WORLD.<255><254> t4: <201x255x254> t5: <199x255x254> c5: <199x255x254> This can be summarised as follows: tl: DTE sends CONNECT, target service "race$generic", target application "TESTAPPL" c 1 : DCE responds READY t2: DTE sends DO MODE OUTPUT, DO PDE, WILL RREF c2: DCE responds WILL MODE OUTPUT, WILL PDE, DONT RREF t3: DTE can continue with or without RREF, so it sends READY c3: DCE responds READY c4: DCE sends its first MESSAGE ("HELLO WORLD."). t4: DTE returns a positive acknowledgement. t5: After a keep alive timer expires, DTE requests shutdown. c5: DCE confirms shutdown

Claims: Claims 1. A method of communicating messages from a first computer application to a second computer application, wherein messaging compatibility between the first and second applications is established using a protocol which comprises the initiation and negotiation of options of a pre-defined kind, the options belonging to a set of options which is expandable to cover additional options. 2. A method of communicating messages from a first computer application to a second computer application wherein messaging compatibility between the first and second applications is established using a protocol which comprises a language with mandatory elements limited solely to the negotiation of options of a pre-defined kind, the options belonging to a set of options which is expandable to cover additional options. 3. A method of communicating messages from a first computer application to a second computer application, wherein the first and/or second applications declare attributes to the protocol defined in either claim 1 or claim 2. 4. The method of any preceding claim wherein negotiating occurs within a range of allowable parameters of any given option. 5. The method of claim 4 wherein the negotiation parameters are included with the request to negotiate. 6. The method of any preceding claim wherein if an application can perform an option, it first asks whether the other application supports that option. 7. The method of claim 6 wherein an application sends a message stating discretionary option parameter values to the other application. 8. The method of claim 6 wherein if the other application does not support that option, it responds accordingly or alternatively, if it does support that option, it responds stating the discretionary parameter values acceptable to it, enabling the two applications to assume the option or to negotiate further. 9. The method of any preceding claim wherein negotiation can be allowed in only a limited number of occasions during the beginning of a conversation between the two applications. 10. The method of claim 1 or claim 2 wherein expansion to cover additional options may occur during communication. 11. The method of claim 3, wherein the first and/or second applications declare their attributes and then any associated options are negotiated to reach a negotiated result. 12. The method of claim 11 wherein the negotiated result is verified to conform to the attributes declared by the application or applications. 13. The method of Claim 1 or 2 in which a connecting application does not negotiate at all. 14. The method of Claim 1 or 2 in which a connected application responds with a DONT or WONT type message if it does not support a suggested option. 15. The method of Claim 1 or 2 in which a service identifier and an application identifier can be added into a connection request. 16. The method of Claim 1 or 2 in which a unique identifier is assigned to each option. 17. A method of application integration using any of the methods defined in any of the above claims. 18. A method of adding or using policies, adaptors or agents using the methods defined in any of the above claims. 19. A method of establishing or using a standard API using the methods defined in any of the above claims. 20. A method of assigning or using names as part of an address for an application, service, connection or a message, in which a message is communicated using the methods defined in any of the above claims. 21. The method of any preceding claims 1 - 16 in which messaging compatibility between the first and second applications is established using a protocol which enables several communication protocols to be supported by either the first and second applications, such that one or both of the applications negotiate and/or compromise to agree which communication protocol or protocols to actually use. 22. Computer hardware apparatus programmed to perform the method defined in any of claims 1 -19. 23. Carrier media programmed with software to enable computer hardware to perform the method defined in any of claims 1 - 19. 24. Application messages exchanged using or reliant upon the method defined in any of claims 1 -19.

Inventors: KILKENNY CHARLES, KILKENNY, CHARLES
Applicants: GLOBAL FINANCIAL NETWORKS LIMI, KILKENNY CHARLES, GLOBAL FINANCIAL NETWORKS LIMITED, KILKENNY, CHARLES
Application year: 1999
Main classification: G06F9
IPC codes: G06F9