body { margin:0px; background-color:#fff } img { margin:0px; border-style:none } button { margin:0px; border-style:none; padding:0px; background-color:transparent; vertical-align:top } p:first-child { margin-top:0px } table { empty-cells:hide } .f-sp { font-size:1px; visibility:hidden } .f-lp { margin-bottom:0px } .f-x1 { } .f-x2 { } .f-x3 { } a:visited { color:#8b0000; text-decoration:underline } .capsub { color:#808080; font-weight:bold; text-transform:uppercase; letter-spacing:2.4px } .bold { color:#00f; font-weight:bold } .bulletlist { margin-left:0px; margin-right:0px; margin-top:0px; margin-bottom:0.1px } .fixed { color:#000; font-family:monospace } .rightaligned { margin-left:0px; margin-right:0px; text-align:right; margin-top:0px; margin-bottom:0.1px } .footer { color:#808080; font-size:90% } .FWExtra { } .FWExtra a:link { text-decoration: none; } .FWExtra a:active { text-decoration: none; } .FWExtra a:visited { text-decoration: none; } .FWExtra a:hover { text-decoration: underline; } -->
Equi4 Softwaremetakit

top pages

 

Metakit
Tclkit
Starkit
CatFish

 

Soapbox

 

Blog
Musings

Tclers' Wiki
The SAX

Company

 

About
Services
Contact info
Support

 

Site map

Remote procedure calls

Metakit storages (both file-based and in-memory) can easily be serialized and de-serialized using the load/save calls provided in each language binding. This capability has been used in a number of projects to send MK data "over the wire", i.e. across sockets.

A small extension to this concept is to also send a bit of extra information, turning such serialized streams into Remote Procedure Calls, effectively. MK-RPC is a formalization of this idea, with some conventions added to greatly enhance its inter-operability across machines, platforms, and languages.

design

The API of MK-RPC deals with sending requests and receiving replies, both using the same protocol. The amount of meta information sent alongside a MK storage is constrained to:

  • a numeric request code (0..65535)
  • any number of integers (MK "I" items, i.e. standard signed ints)
  • any number of strings (MK "B" items, i.e. arbitrary data, also binary)

And of course an optional MK storage. This maintains total extensibility, even when the above format is too restrictive, because arbitrarily large and complex data can always be added to the MK storage object itself.

MK-RPC is designed to be extremely efficient and add very little overhead:

  • data is sent in binary form, using MK's compact column-wise format
  • tiny requests (req code + 1 int, no other data or storage) are super efficient
  • basic requests (req code, ints, strings, no storage) can be sent compressed
  • full requests send MK storages as is, i.e. using MK's serialization logic
  • serialization from file use memory mapping to avoid copying

The design takes advantage of the fact that MK storages are 100% self-descriptive, that they take care of byte-order issues, and that the header of a serialized stream contains the size of the entire object. With some extra logic, all types of requests are distinguishable in the receiver by simply examining the first 8 incoming bytes.

programming interface

The design of the calling API is language specific. Basically, the call to send a request is:

  mkrpcsend <iochan> <reqcode> <intlist> <strlist> <storage>

Where the last three arguments are optional. This is not the whole story: there are also a few options, to specify compression and to indicate whether a storage may be modified in place to include some extra data (an optimization trade-off).

The reply will contain these same items, requests and replies share the same logic.

MK-RPC has been designed to later support asynchronous use, and multiplexing of multiple request/reply streams over a single connection.

protocol

The following figure describes the protocol of bytes going over the wire:
 

metakit index

Intro / News

Overview

Documentation

Licensing

Download

Mailing lists

To-do list

Acknowledgements

Quotes

Links

item2