The Calculator Protocol (TCP)

M. v. Löwis, HPI

June 1, 2007

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.) [1].

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{
  sequence<any> parameters;

  struct Expression= ID 6 {
    binary host; /* IPv4 address */
    int port;
    parameters arguments;
  }

  struct Literal = ID 7 {
    double value;
  }

  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. May 20, 2007

Initial Revision

7. References

7.1. Normative References

7.2. Informative References

Hasso-Plattner-Institut, "Registry forExtensions," 2007.

Author