serviceipc

IPC Among OKWS Services

When communication across services is required, a simple API is available via RPC.

One-Way Communication

The best-tested, most stable way to do this is with one-way communication, via the CUSTOM1 RPC interface. This is, a client in one service makes an RPC to servers in different services. The servers respond with a status code, and a combined status code is sent back to the calling client. Note that there is no way for the servers to communicate back to the client, but they could, in turn, initiate their own 1-way CUSTOM1 calls back to the client.

For a service to serve inter-Service IPC, it needs to override the virtual methods custom1_rpc and custom2_rpc. That is, in my service my_srvc_t, I would implement the following class methods:

void my_srvc_t::custom1_rpc (svccb *sbp) { ok_xstatus_t res (OK_STATUS_OK); my_xdr_struct_t s; ok_custom_data_t *arg = sbp->Xtmpl getarg<ok_custom_data> (); bytes2xdr (s, arg->data); // do some stuff with your struct s; perhaps s is a union that // acts differently for different types of commands. sbp->replyref (res); }

That was the server side. On the client side, I use the regular client RPC interface:

void my_srvc2_t::process () { ok_custom_arg_t arg; ptr<ok_status_t> res = New refcounted<ok_status_t> (); arg.progs.push_back ("/home"); arg.progs.push_back ("/list"); my_xdr_struct_t s; // load s with all sorts of goodies xdr2bytes (arg.data.data, s); get_okd_aclnt ()->call (OKCTL_CUSTOM_1_IN, &arg, res, wrap (cb, res)); }

2-Way IPC

A recently added feature (and one that is not too well tested) is 2-way IPC, in which each of the services that receive an RPC can respond with their own response, all of which are bundled up and returned to the calling service. Here is what the server looks like in this new world:

void my_srvc_t::custom2_rpc (svccb *sbp) { ok_xstatus_t res (OK_STATUS_OK); ok_custom_data_t *arg = sbp->Xtmpl getarg<ok_custom_data> (); ok_custom_data_t res; bytes2xdr (s, arg->data); // do some stuff with your struct s; perhaps s is a union that // acts differently for different types of commands. also, formulate // a response and stick it in res via xdr2bytes sbp->replyref (res); }

In other words, the server side of things looks pretty much the same. The big difference to notice is that we're now overloading custom2_rpc instead of custom1_rpc, and that the signature of the corresponding CUSTOM2 RPC is different, in that it has a different return type (ok_custom_data_t as opposed to ok_xstatus_t).

On the client side, call OKCTL_CUSTOM_2_IN instead of OKCTL_CUSTOM_1_IN, and now note that the response to this RPC is of type ok_custom_res_set_t, which is duplicated here (the originals can be found in libaok/okprot.x):

union ok_custom_res_union_t switch (ok_xstatus_typ_t status) { case OK_STATUS_OK: ok_custom_data_t dat; default: void; };

struct ok_custom_res_t { ok_prog_t prog; ok_custom_res_union_t res; };

struct ok_custom_res_set_t { ok_custom_res_t results<>; };

Unfortunately, the routing software for the 2-way IPC calls in okd is not very well-tested, so let me know if you see any problems.