PodballModNetwork

Ideas how to move to a network architecture

The idea is this: The podball application communicates with the control modules over TCP/IP sockets.

Advantage:
The control modules can be written in any language and on any system that supports an IP network stack.

Disadvantage:
Control modules need to implement the application layer network stack.
But if a sufficiently simple and widespread protocol is chosen, chances are good that there exists libraries in most languages that support this out-of-the-box in many languages and on many platforms.

Best candidate for the application layer protocol so far:
JSON-RPC over TCP streams - http://en.wikipedia.org/wiki/JSON-RPC
It is simple to implement and implementations are readily available on a wide variety of platforms and languages.
Links:

• Specification: http://www.jsonrpc.org/specification
• http://www.simple-is-better.org/json-rpc/transport_sockets.html
• A C++ implementation (CMake support, MIT license!):
  http://cinemast.github.io/libjson-rpc-cpp/
  https://github.com/cinemast/libjson-rpc-cpp

Ruled out:
CORBA, SOAP/XML/HTTP - Too much boilerplate, too complicated, overkill.

Who is the server and who is the client?

Podball is calling functions on the control modules. So naturally, one would think of podball being the client and the control modules being servers.
However it is conceptually simpler that podball is the server and the control modules connect to it.
Control modules should open the TCP connection to the server and call a registration function, passing some general information about the module along the way. From this point on, the server (podball) may call the control modules RPC functions for Init, Play, etc.

Protocol Definition (proposal)

TBD.

Sidetrack: How should float/double values be exchanged over a text-based protocol in order to preserver precision?
Interesting read:
http://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2/