"Michael Purdy" <email@hidden> wrote:
>I will be needing to implement a method to allow two java applications
>to communicate and transfer data. It will need to operate at the
>fastest possible rate.
There are two distinct aspects of communication speed: latency and bandwidth.
Latency is "how long does it take to turn a message around". It may not be
constant. There may be different initial latency and recurring latency.
Bandwidth is "how many messages can you transfer per second".
You can have blistering bandwidth, but if the latency is high, then
throughput can be abysmal. You can also have moderate bandwidth with low
latency, yet get better throughput and noticeably better responsiveness.
So which do you need, high bandwidth, low latency, or both?
And how much of your total comm cost is spent in translation? That is, in
encoding and decoding messages, parsing, instantiating, assembling replies,
etc. Sometimes you can measurably increase throughput by simplifying your
representation, reducing the translation overhead. Generally, this affects
latency, not bandwidth. It affects bandwidth only when messages become
smaller.
>My plan thus far is to establish a socket
>connection between the two and create a sort of client-server system.
>Does anyone have opinions on this strategy or suggestions for alternate,
>possibly faster, methods.
I've used the loopback address 127.0.0.1 with excellent results. It was a
pure client-server system, not "a sort of" one. It just happened to be
that both the client and the server were on the same host.
You might also try named pipes. See 'man mkfifo' in Terminal. I don't
know how they compare to 127.0.0.1 sockets, in either latency or bandwidth.
It's easy to set up a test for bandwidth and latency using sockets. Then
you can play with some of the socket-timing parameters, too. It's also
pretty easy to set up a similar test using named pipes (fifos). A test
using a shared-memory buffer is probably of similar difficulty.
I strongly suggest creating tests and doing measurements. Otherwise all
you've got is speculation, not measurements. For example, you may find
that "fastest" depends on JVM version, OS version, CPU type, and amount of
physical RAM. Or you may have to trade off "fastest" against ease of
maintenance, security, or some other factors.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
