HPI: The Calculator Protocol (TCP) version 2
M. v. Löwis, HPI
June 3, 2008
The Calculator Protocol (TCP) version 2
This memo presents The Calculator Protocol, an protocol for distributed computing.
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 a user-defined data type, double-precision floating point numbers. They are encoded with a tag of value 160, 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;
}
}
A server for the calculator protocol receives Request messages, and responds with Reply messages. 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. June 3, 2008
Initial Revision
7. References
7.1. Normative References
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. |
| [RFC4234] | Crocker, D., "Augmented BNF for Syntax Specifications: ABNF," RFC 4234, October 2005. |
7.2. Informative References
| [REGISTRATION] | Hasso-Plattner-Institut, "Registry for Extensions," 2007. |