As discussed during the conference, we are running out of the TraCI-namespaces in terms of the used numerical IDs for commands, subscriptions, and responses.
We now have - 15 contexts - each has four access types (get, set, context subscription, variable subscription), and each access type has an own response - three singular commands (version, close, step) a) Enlarging the namespace Below are some ideas on how to increase the name space. a1) responses have the same return value as their respective getters This means, instead of // command: subscribe induction loop (e1) context #define CMD_SUBSCRIBE_INDUCTIONLOOP_CONTEXT 0x80 // response: subscribe induction loop (e1) context #define RESPONSE_SUBSCRIBE_INDUCTIONLOOP_CONTEXT 0x90 // command: get induction loop (e1) variable #define CMD_GET_INDUCTIONLOOP_VARIABLE 0xa0 // response: get induction loop (e1) variable #define RESPONSE_GET_INDUCTIONLOOP_VARIABLE 0xb0 // command: subscribe induction loop (e1) variable #define CMD_SUBSCRIBE_INDUCTIONLOOP_VARIABLE 0xd0 // response: subscribe induction loop (e1) variable #define RESPONSE_SUBSCRIBE_INDUCTIONLOOP_VARIABLE 0xe0 We would have something like this: // command: subscribe induction loop (e1) context #define CMD_SUBSCRIBE_INDUCTIONLOOP_CONTEXT 0x80 // response: subscribe induction loop (e1) context #define RESPONSE_SUBSCRIBE_INDUCTIONLOOP_CONTEXT 0x80 // command: get induction loop (e1) variable #define CMD_GET_INDUCTIONLOOP_VARIABLE 0x90 // response: get induction loop (e1) variable #define RESPONSE_GET_INDUCTIONLOOP_VARIABLE 0x90 // command: subscribe induction loop (e1) variable #define CMD_SUBSCRIBE_INDUCTIONLOOP_VARIABLE 0xa0 // response: subscribe induction loop (e1) variable #define RESPONSE_SUBSCRIBE_INDUCTIONLOOP_VARIABLE 0xa0 (responses have the same id as the commands) That would save half of the namespace. The cleanest way to do this would be to keep the upper-most four bytes reserved for describing the type of access, for example: - 00xxxxxx: set - 01xxxxxx: get - 10xxxxxx: variable subscription - 11xxxxxx: context subscription I would additionally reserve the third-highest bit for any other context-specific access types (not planned, yet). We would then have 5 bits (32 values) for the contexts - twice as many as now. a2) A second possibility would be to use two bytes instead of one, sure. I personally do not think that this is necessary by now. a3) Just to name it: we could of course as well introduce some kind of grouping or extensions; for example, if a 0xff comes first, the command has to be read from the next byte on, using a new namespace. Not really nice. b) I think that the "global" (step, close, version) commands should be reworked; I'd propose to reserve the zero-namespace for them. - 00000000 version - 00000001 step - 00000010 close It seems like we could enlarge the namespace without breaking too much, as only the following things would change - the constants - responses would have the code of the command (partially hard-coded in SUMO, may be as well the case in clients) Regarding the timeline, I'd propose to schedule this for the next version. We kindly ask you to: - tell us whether you need more than three months to update your clients - discuss the possibilities to test your software Of course, any other comments are welcome. Sincerely, Daniel ------------------------------------------------------------------------------ The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk _______________________________________________ sumo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sumo-devel
