The Calculator Protocol (TCP) version 4
Abstract
This memo presents The Calculator Protocol, an protocol for distributed computing.
Table of Contents
1.
Introduction
2.
Conventions in this document
3.
TWP Extensions
4.
Protocol Specification
5.
Security Considerations
6.
Revision History
6.1.
December 12, 2009
6.2.
December 29, 2009
6.3.
January 3, 2011
7.
References
7.1.
Normative References
7.2.
Informative References
§
Author's Address
1.
Introduction
The Calculator Protocol supports computation of a mathematical formula in a distributed manner.
Each node supports a specific operation; it may refer to other nodes to compute the arguments to
the operation first.
2.
Conventions in this document
The key words "MUST" and "MAY"in this document is to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
3.
TWP Extensions
This protocol introduces an application type, double-precision floating point numbers. They are encoded with a tag
of value 160, followed by a length field of value 8, followed by the IEEE-754 byte sequence of the double value in network byte order. In TDL, this type is
denoted by the keyword "double".
4.
Protocol Specification
The Protocol is defined with the following TDL specification:
protocol Calculator = ID 5{
typedef Term;
sequence<Term> parameters;
struct Expression{
binary host; /* IPv4 or IPv6 address */
int port;
parameters arguments;
}
union Term{
case 0: double value;
case 1: Expression expr;
}
message Request = 0 {
int request_id;
parameters arguments;
}
message Reply = 1 {
int request_id;
double result;
}
message Error = 2{
string text;
}
}
A server for the calculator protocol receives Request messages, and MUST respond with either a Reply or an Error message.
The request message contains the argument of the operation; the operation itself is specific to the server.
The parameters may either be Expression or Literal values. For an Expression value, the server can contact
the given host and port, sending the arguments in a Request message. For a Literal value, the value field
denotes the parameter.
A server SHOULD forward any extensions received in a Request message when it needs to contact other
servers in order to perform the request.
5.
Security Considerations
This protocol does not include any security mechanisms. All data are transmitted unencrypted, and communication partners are not mutually authenticated.
6.
Revision History
6.1.
December 12, 2009
Initial Revision
6.2.
December 29, 2009
Drop unused struct Literal
6.3.
January 3, 2011
TCPv4: Add Error message
7.
References
7.1. Normative References
7.2. Informative References
Author's Address