Programming Rules and FAQ

rDSN provides a coherent framework from which developers build their systems with minor adjustment from traditional development styles, and code built on atop of rDSN conforms to certain rules (see why).

• All non-deterministic behavior must go through rDSN's Service API, to ensure the underlying tools and runtime frameworks be reliable. Image something you want to do perfectly while some hidden hands suddenly dig a hole where you don't see. We have identified the commonly seen non-determinisms used by distributed systems as part of rDSN's Service API, which includes RPC, tasking, thread synchronization, file IO, and environment input (random, time). This API is a little bit low level, so rDSN also introduces higher level syntactic sugars here. On the other hand, calling deterministic and blocking APIs is safe. Any further non-determinisms we should be aware of, please let us know.

• No global variables. Because rDSN allows multiple "service process"es as "[service app] (https://github.com/Microsoft/rDSN/blob/master/include/dsn/internal/service_app.h#L38)"s inside the same physical process for simulation with lots of useful tools, global variables are not allowed to avoid global state confliction. A common approach to have "global variables" is to put them as member variables of your target "service app", and you can call [::dsn::service::system::get_current_app()] (https://github.com/Microsoft/rDSN/blob/master/include/dsn/service_api.h#L123) to access them. Similarly, the original main logic for a node should also be moved to inside service_app::start to avoid conflictions with other nodes.

Frequently Asked Questions