HPI: The Calculator Protocol (TCP) version 4
M. v. Löwis, HPI
January 3, 2011
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
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. |
7.2. Informative References
| [REGISTRATION] | Hasso-Plattner-Institut, "Registry for Extensions," 2009. |