Thanks Simon for detailed explanation. My use case is similar to what you have explained NetworkManager (signal when something interesting happens :)). We are in the process of developing one playback system. One of the sub-system within this will function as media player UI. Through this media player UI, user can give many commands like play, stop etc. to player, Player in turn updates UI about command execution status and clip status (playing/time details etc). Also, the media player UI might get signals from other sub-systems (eg. USB device connected). UI need to interact authorization module to autherise operator/contents etc. The monitor module should also able to listen all events happening within system. All these components will sit on same machine. So we are planning to use DBUS for interaction between these sub-systems. DBUS gives advantage here as some of sub-systems are written in python scripts and by using DBUS we can concentrate more on main application requirements rather than caring about interprocess communication. Apologize for late reply as I was on vacation :). <div class="gmail_quote">On Wed, Aug 29, 2012 at 7:56 PM, Simon McVittie <<a href="mailto:simon.mcvittie@collabora.co.uk" target="_blank">simon.mcvittie@collabora.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 29/08/12 14:05, rajnikant jachak wrote: > As I said, my client emits 'req' signal and server processes it. In my > system, there would be multiple clients emitting same signal 'req', > which server in turn needs to process. </div>That's fine. Multiple client processes are fine, multiple threads within one process are more problematic (because they share an address space, so they need mutexes and very careful programming practices). <div class="im"> > Would such type of many to one association, overload DBUS? </div>Many-to-one communication is fine - it's a large part of why D-Bus exists. But you're asking about performance without giving any indication of what you're actually doing, so I should give you the usual performance advice. The standard D-Bus system and session buses are really designed to be used for "signalling" - individual messages or short bursts of messages when something interesting happens - rather than for continuous bulk traffic. For instance, it's ideal for something like NetworkManager. When the user takes action or "interesting" things happen in the real world (network cable plugged in, wireless network detected, etc.), relatively many messages are sent, but that's a temporary situation. When the computer is idle, NetworkManager only needs to send a message to the UI every few seconds (or even every few minutes) to say "signal strength has changed to 42%" or similar. Similarly, the Telepathy IM framework sends D-Bus messages when you send or receive messages, start or receive calls, or when your friends' presence statuses change, but in between "interesting" events, it's idle. That's the sort of thing D-Bus is meant for. My usual rule of thumb is that if you have to worry about D-Bus' performance or what percentage of CPU time it will take up, you should consider whether D-Bus is actually the right thing for you. You can always use the system bus to do the "handshaking" for a private Unix socket or something, then do your bulk data transfer over that. If you tell this mailing list what your use case is, we're more likely to be able to say whether D-Bus is appropriate. Otherwise, the only answer you're likely to get is "it depends". <div class="im"> If yes, would > such problem get resolved if every client emits different signal (ex. > client1 emits req1, client2 emits req2 etc) for server? </div>No, renaming messages does not alter the amount of CPU time they'll require. S _______________________________________________ dbus mailing list <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/dbus" target="_blank">http://lists.freedesktop.org/mailman/listinfo/dbus</a> </blockquote></div> -- Regards, Rajnikant Jachak. The pessimist sees difficulty in every opportunity. The optimist sees the opportunity in every difficulty.