Brian Cameron wrote:
Rob/George:
The main reason for running with orbitrc configured with IPv4 turned on
is so that Java applications are accessible. Since Java supports CORBA,
but does not support CORBA over a UNIX socket, it is necessary to
turn on IPv4 for Java programs to be accessible. The LocalOnly
flag is then desirable to ensure that nobody from other machines
can use TCP/IP to connect to the ORBit server.
I'm not sure how Java a11y will work with D-Bus. Is this in the
plan at all?
Supporting com.sun.java.accessibility shouldn't be hard, but we really
need with some input from people who understand how accessibility is
exposed by AWT/SWT/Swing..
I'm a bit confused by the slowdown, though. I thought that programs
that use UNIX sockets to connect to the ORBit2 server will continue to
do so even when TCP/IP is enabled. My understanding was that enabling
TCP/IP with ORBit2 just made it possible for programs that want to use
TCP/IP to also be able to connect to the ORBit2 server (such as Java
programs).
Well, the slowdown occurs when you disable local sockets, so no suprise
there :)
Thanks,
Rob
Brian
i.e. an orbitrc of
OBITIIOPIPv4=1
ORBLocalOnly=1
is roughly 10% slower than
ORBITIIOPUsock=1
(on a linux system, in this case)
We could test DBus over tcp (non-local) against ORBit over TCP
(non-local), though I'm not sure how common a use-case this is.
I'd expect that the numbers would get more similar between the dbus and
orbit versus using unix sockets, as the time spent in transport would
come to dominate. Message sizes are roughly similar between the two
technologies and almost always would be under MTU.
Thanks,
Rob