Note: the multiplexing-rpc library is in development and isn't ready for use at the moment.

• The protocol, used in the multiplexing-rpc for client-server communications, is platform-neutral. This means that it can be implemented and used for communications between any modern OS and any modern CPU architecture (any combination of Linux, Solaris, FreeBSD, Windows, 32 bit, 64 bit, big endian, little endian, etc.). The current implementation uses the fiber-framework as cross-platform base library. New implementations can be added in the future.
• On-the-wire protocol format was designed to be as compact as possible. This means that it uses binary encoding and contains only essential data. Signed and unsigned integers are encoded the same way as google's protocol buffers' integers. It doesn't use various ASN.1 encodings, because they are overly complex for simple protocol such as multiplexing-rpc on-the-wire protocol.
• Ability to re-use byte stream for sending unlimited number of serial RPCs. This allows to conserve OS resources, which are usually spent for connection establishing per each RPC call in other RPC implementations.
• Ability to send multiple independent RPC requests and responses in parallel over the same byte stream. This allows to improve overall RPC processing speed, because server can process multiple RPCs in parallel. Also this helps to increase bandwidth utilization for streams with high latency, because there is no need to wait while the current RPC request will be delivered to server or the current RPC response will be returned to client before sending new RPC.
• Abstraction of byte streams for RPC multiplexing. It is possible to use arbitrary byte stream, including TCP, pipe or any custom stream. For instance, it is possible to use custom stream, which implements reliable byte stream over UDP. Also byte stream abstraction allows to transparently implement authentication, compression and encryption on the level below the multiplexing-rpc logic.
• Ability to distribute RPC requests among available cluster of servers. Each parameter in the RPC request can be used for calculation of a special 'hash key', which then will be used by 'distributed client' in order to determine to which server to send the given RPC request. This way different distribution policies can be implemented for providing load balancing, scalability and / or high availability. The list of available servers can be dynamically changed at any time.
• Support for flow control at the level of each currently running RPC. This prevents starvation of concurrently running RPCs, when at least one of these RPCs is able to saturate all the bandwidth of byte stream between client and server. In this case bandwidth consumed by such an RPC will be limited, so other currently running RPCs can proceed. Currently this feature is at design stage.
• Each RPC can have it's own response timeout. Currently this feature is at design stage.
• An RPC interface compiler, which is able to generate either client code either server code from the given RPC interface definition file. The multiplexing-rpc uses its own interface definition language instead of standard IDL, because IDL is overly complex. It provides many features, which aren't used by the multiplexing-rpc. Also it doesn't support some multiplexing-rpc features. Currently multiplexing-rpc interface definition language syntax and compiler are at design stage.
• Support for multiple responses per each RPC request (aka RPC streaming or server push). An RPC can be defined in the way that the server will be able to send arbitrary number of responses to the client. This feature can be used for various distributed event implementations. Think about realtime market quotes or chat system. Currently this feature is at design stage.
• Support for wide range of RPC parameters' types.
  • Signed and unsigned integers with length up to 64 bit.
  • Char arrays (aka ANSI strings) with length up to 2^16 characters. The maximum length of char arrays is artificial. It's main purpose is security-minded - it prevents possible DoS attacks aimed at overflowing process' address space by sending huge strings in RPC requests. Use blobs instead of char arrays if you need to send large amounts of data.
  • Wide char arrays (aka Unicode strings) with length up to 2^16 wide characters. The same rules are applied for the length of wide char arrays as for char arrays. Read the comment about maximum length of char array for more info.
  • Blobs. Currently the blob size is limited to 2Gb, but this limit can be increased to serveral Pb in the future. Blob parameters are streamed to temporary files, not in the current process' address space. This allows to work around 2-4Gb address space limit for 32-bit processes and to keep process' working set small for both 32-bit and 64-bit processes. Blobs can be useful for p2p files sharing systems.
  • Lists of integers. The list can contain up to 1024 integers (including zero integers). This limit is artificial and security-minded. Read comments above for more info. Currently 'list of integers' type is at design stage.
  • Lists of ANSI strings. The list can contain any number of strings, but total string's size in the list must be less than 2^16 characters. This limit is artificial and security-minded. Read comments above for more info. Currently 'list of ANSI strings' type is at design stage.
  • Lists of Unicode strings. The list can contain any number of strings, but total string's size in the list must be less than 2^16 wide characters. This limit is artificial and security-minded. Read comments above for more info. Currently 'list of Unicode strings' type is at design stage.
  • Lists of blobs. The list can contain up to 1024 blobs. This limit is artificial and security-minded. Read comments above for more info. Currently 'list of blobs' type is at design stage.
  • Byte streams. RPC definition can contain any number of parameters with types mentioned above and only one byte stream as response parameter, which must be the last in the response parameters' list. This allows to use RPC for establishing two-way (duplex) byte streams between server and client. Think about an RPC for establishing TCP connection on server side. Currently 'byte stream' type is at design stage.