TOC 
HPIM. v. Löwis
 HPI
 January 3, 2011


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




 TOC 

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.



 TOC 

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].



 TOC 

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".



 TOC 

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.



 TOC 

5.  Security Considerations

This protocol does not include any security mechanisms. All data are transmitted unencrypted, and communication partners are not mutually authenticated.



 TOC 

6.  Revision History



 TOC 

6.1.  December 12, 2009

Initial Revision



 TOC 

6.2.  December 29, 2009

Drop unused struct Literal



 TOC 

6.3.  January 3, 2011

TCPv4: Add Error message



 TOC 

7.  References



 TOC 

7.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


 TOC 

7.2. Informative References

[REGISTRATION] Hasso-Plattner-Institut, “Registry for Extensions,” 2009.


 TOC 

Author's Address

  Martin v. Löwis
  Hasso-Plattner-Institut
  Potsdam,
  Germany
Email:  martin.vonloewis@hpi.uni-potsdam.de