[olsr-dev] new ipc
Lorenz Schori
(spam-protected)
Thu Mar 9 13:54:38 CET 2006
hi all
i did sacrifice some days of my vacencies and put together some basic
code and a concept for the new ipc mechanism. at the moment i did not
care about how data will come from the client to olsrd and back - i
simply assume plain ascii, so the protocol itself is still open for
discussion.
currently the whole stuff is packed into a hijacked httpinfo plugin.
for production it will have to move into olsrd itself in order to
make the symbols available everywhere.
the icp system consists of the following parts:
targets: addressable parts of olsrd or plugins.
actions/parameter: actions which can be sent to targets. actions can
have multiple paramters of different types.
session: a client session which consists of a list of actions.
targets, actions and paramters are identified by a string value, the
selector. targets can contain actions and actions can contain
paramters. each of them has to be registered with the ipc system with
the following functions:
ipc_target_spec* icp_register_target_spec_once(char* selector);
ipc_action_spec* icp_register_action_spec_once(char* selector,
ipc_target_spec*);
ipc_param_spec* icp_register_param_spec_once(char* selector,
ipc_action_spec*, char type);
as soon as the appropriate specs are registered with the ipc system a
target can adopt a handler for an action:
int ipc_adopt_action_handler(ipc_target_spec* target,
ipc_action_spec* action,
ipc_action_handler handler,
void* user_info);
some sort of protocol will now allow the client to send commands to
targets using target+action+parameter selectors with a session. each
session contains a list of actions which are created using the
appropriate xxx_spec structures.
ipc_action*
ipc_session_add_action(ipc_session* session, ipc_action_spec* spec,
ipc_target_spec* target);
ipc_param*
ipc_action_add_param(ipc_action* action, ipc_param_spec* spec, void*
data, int size, int flags);
as soon the session is ready it is executed by:
int ipc_session_perform(ipc_session* session);
this function loops several times thru the whole action list, each
time incrementing its session state from init thru header, body,
footer then fini and finally eos (end of session). this allows action
handlers to react in one or more states of the session. if the
session is in header, body or footer state data can be sent to it using
int
ipc_send_session(ipc_target_spec *target, char* string, int size,
ipc_session* session);
to simplify monitoring tasks for olsr messages there is a function
which installs a default handler for the monitoring action for a
given target. this handler will install a parser function and call
the formatter function for each incomming olsr message of the
specified type as long as there are interested clients:
int
ipc_adopt_target_olsr_formatter(ipc_target_spec* target,
olsr_u8_t olsr_msgtype,
ipc_olsr_formatter,
void* user_info);
note: targets can only have ONE formatter.
there is much missing in the code and there are major bugs for sure.
just want to gather some feedback on the concept and the code so i
can estimate if its worth working further on it. someone interested
in cooperation?
lorenz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipc.zip
Type: application/zip
Size: 18782 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20060309/ad9e349e/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20060309/ad9e349e/attachment.sig>
More information about the Olsr-dev
mailing list