D-Bus TCP Transport layer

[Andrew Johnson]

Can someone who knows comment on the security, robustness and maturity 
of the TCP/IP D-Bus transport layer?

A related question: the D-Bus Unix transport layer is said to implement 
connection management within the context of a single machine; does/will 
the TCP/IP transport layer extend that to remote systems and be able to 
detect and report disconnection events caused by power and/or network 
failures?

Some context for my question: I'm looking at the feasibility of using 
D-Bus to re-implement the functionality of an existing network protocol 
called EPICS Channel Access, which is used by research laboratories 
throughout the world to build "slow" control systems for large 
distributed scientific experiments [visit http://www.aps.anl.gov/epics/ 
for more information about EPICS].  It would be great for the next major 
version of EPICS to be able to base its network communications on a 
standard IPC protocol like D-Bus, although we'd obviously have to write 
our own wrappers to achieve all the functionality we have now.  However 
there is no point our adopting D-Bus if it can't provide the features we 
need from the network transport layer.

Our existing protocol implements a Publish and Subscribe model across a 
network subnet, using both UDP and TCP; client applications use UDP to 
broadcast the names of those data channels they are interested in, and 
the servers for those data channels identify themselves in a UDP reply, 
at which point the clients connect to those servers directly using TCP 
and subscribe to data updates for the relevant channels.  Data updates 
are published to the individual clients asynchronously as they occur, 
and the clients can also do gets and puts of data as they wish.

It's very important for us that the IPC layer should correctly handle 
connection management in the face of network and/or server failures, 
which is one area where many of the other standard network IPC protocols 
are severely lacking.  If a connected server dies for any reason (the 
process may end nicely or be killed, the server machine may be turned 
off without any warning or the network connecting the two might fail), 
the clients that were subscribed to any of its data channels must be 
able to discover this within about 30 seconds of the fault.  If the 
server later comes back on line, its clients must be able to discover 
this and reconnect immediately without having to be restarted. 
Similarly if a server only gets started after the clients that are 
interested in its data channels, those clients should immediately 
recognize that a new server is available and be able to check if it has 
any of the unresolved channels they want.

Thanks in advance,

- Andrew
-- 
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro