Howto setup/connect to a listening server [dbus_server_liste (...)] ?
rony at wu.ac.at
Sat Jul 23 06:55:30 PDT 2011
again, many thanks for your comments and hints!
So far I had (wrongly) assumed that there is a default implementation
which gets kicked-off using dbus_server_listen() which will dispatch
connection attempts and invokes the new_connection callback function.
Probably this "wish was the father of my thoughts". Or with other words:
thought that dbus_server_listen() would set up and run a loop and
whenever a connection attempt is undertaken, authenticates and calls the
registered new_connection function. It seems that I need to create a
handler myself that does all of that.
Now, I am a little bit lost as to what steps in which order are needed
in such a server handler to determine whether a connection attempt was
undertaken, what to do then (like how to authenticate, how to assign a
unique bus-id, if necessary at all, ...)!
Do you know of a link to a description of what must be tackled, when
creating a loop in a separate thread to handle new connections for a
listening server? Surely, somewhere there is a specification for what a
server handler is supposed to do?
Is there somewhere a (simple) implementation that one could study to
create an own loop to service new connections to the listening server,
without using glib or the like, just a "raw", maybe
"strawman-like/nutshell" dbus reference implementation for a server
Even pseudo-code showing the most important steps would help
tremendeously in this situation!
On 23.07.2011 02:53, Mike Gorse wrote:
> On Sat, 23 Jul 2011, rony wrote:
>> There is no main-loop in this case, but a callback function that should
>> get invoked by the server once a connection is established
> Then what are you using to listen for events on your server, if not a
> main loop? Ie, are you calling select() on a set of file descriptors?
>> According to the documentation the server gets started with a call to
>> dbus_server_listen() and if a connection happens the function gets
>> called back that gets submitted via the
> As discussed in the documentation to dbus_server_listen,
> dbus_server_set_watch_functions() and
> dbus_server_set_timeout_functions() need to be called in addition to
>> The server starts and supplies the given addresses to clients that try
>> to connect to these addresses. But nothing more happens, the callback
>> function on the server side is not invoked. Calls from the client get no
>> answers but timeout.
>>> If you're using glib, then there's a function in dbus-glib called
>>> dbus_server_setup_with_g_main that will integrate the server into the
>>> glib main loop. Otherwise that function might be useful to look at (I
>>> don't understand how watches work all that well, but they need to be
>> glib is not used at all in this case. Also there are no watch and
>> timeout callbacks set up as there is no main-loop to be serviced.
> If you aren't using a standard main loop, then I think you'll need to
> roll your own code to handle dbus watches and invoke their callbacks
> when there is data available; otherwise libdbus won't know that there
> is data to process on the socket. Your binding will need to expose or
> wrap these watch functions somehow. If you have a binding for glib,
> then I'd recommend binding the dbus_*_setup_with_g_main functions from
> dbus-glib as well, since they make it convenient to integrate a dbus
> server or connection.
> -Mike G-
More information about the dbus