This is more efficient in terms of memory and hash lookups, it is also
not prone to string format bugs in remote stacks such as leading zeros
being treated as a different handle as can be experience with
Nokia N950 which sends events using a handle with leading zeros but
message listing don't have them.
96 bytes in 3 blocks are definitely lost in loss record 217 of 310
at 0x4C29E84: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5977858: g_malloc0 (in /usr/lib/libglib-2.0.so.0.3600.3)
by 0x433A87: map_register_event_handler (map-event.c:76)
by 0x4324C1: set_notification_registration (map.c:1722)
by 0x4325BB: map_probe (map.c:1801)
by 0x42D55C: obc_session_register (session.c:862)
by 0x42BE4B: create_callback (manager.c:100)
by 0x42CA0D: connect_cb (session.c:281)
by 0x4191CB: handle_response (gobex.c:949)
by 0x4196F0: incoming_data (gobex.c:1192)
by 0x5971DA5: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.3600.3)
by 0x59720F7: ??? (in /usr/lib/libglib-2.0.so.0.3600.3)
The MAP specification allows to reuse one MNS server instance for all
local MAS client instances. This dispatching of event reports to the
correct MAS client instance is done by the MAS instance id and the
device address.
The dispatcher component allows MAS client instances to register a
notification handler. Events reports are forwarded by the MNS server using
map_dispatch_event.
