Questions ad minimal server loop implementation ( Re: Howto setup/connect to a listening server [dbus_server_liste (...)] ?
rony
rony at wu.ac.at
Tue Jul 26 02:13:14 PDT 2011
What are the minimal requirements for implementing a DBus server loop?
Would it be sufficient to employ a timeout function (set with
"dbus_server_set_timeout_functions()")?
If so, what is the timeout handler supposed to do then, how can it
get to the DBusConnection or is it supposed to create it on its own?
Is it supposed to invoke the new-connection function
("dbus_server_set_new_connection_function")? If not, which function
is responsible for invoking the supplied new-connection function
supplying the DBusConnection?
If one is supposed to supply a watch function (set with
"dbus_server_set_watch_functions()"):
How to learn what to watch? What is the handler supposed to do, how
can it get to the DBusConnection or is it supposed to create it on
its own? Is it supposed to invoke the new-connection function
("dbus_server_set_new_connection_function")? If not, which function
is responsible for invoking the supplied new-connection function
supplying the DBusConnection?
Any (brief and conceptual) answers would really help a lot to understand
the needs one has to fulfill in a server loop!
Would an implementation for the timer and watch functions like in
<http://read.pudn.com/downloads116/ebook/495803/winDBus/dbus/dbus-server.c__.htm>
be reasonable for any platform? If so, how does the
new-connection-function get invoked in order to get access to the
DBusConnection that attached to the server (which function is
responsible to invoke it)?
---rony
On 23.07.2011 15:55, rony wrote:
> Dear Mike:
>
> 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
> handler?
>
> Even pseudo-code showing the most important steps would help
> tremendeously in this situation!
>
> TIA
>
> ---rony
>
>
>
>
>
> 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
>>> (authenticated?).
>>>
>> 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
>>> dbus_server_set_new_connection_function()-call.
>>>
>> 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
>> dbus_server_set_new_connection_function.
>>
>>
>>> 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
>>>> set).
>>>>
>>> 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.
>>
>> Hth,
>> -Mike G-
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110726/967d8d01/attachment.html>
More information about the dbus
mailing list