Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11753

Re: Interplatform (interprocess, interlanguage) communication

Show all headers | View raw

On 2/3/2012 12:52 PM, Stefan Ram wrote:
>    »X« below is another language than Java, for example,
>    VBA, C#, or C.
>

I am mostly a C developer, so I am writing more from my perspective...


>    When an X process and a Java process have to exchange
>    information on the same computer, what possibilites are
>    there? The Java process should act as a client, sending
>    commands to the X process and also wants to read answers
>    from the X process. So, the X process is a kind of server.
>
>    My criteria are: reliability and it should not be extremely
>    slow (say exchanging a string should not take more than
>    about 10 ms). The main criterion is reliability.
>
>    »Reliability« means little risk of creating problems, little
>    risk of failure at run-time. (It might help when the client
>    [=Java process] can reset the communication to a known and
>    sane start state in case of problems detected at run-time.)
>
>    The host OS is Windows, but a portable solution won't hurt.
>
>    A list of possibilities I am aware of now:
>
>    Pipes
>
>    I have no experience with this. I heard one can establish
>    a new process »proc« with »exec« and then use
>
> BufferedWriter out = new BufferedWriter(new
>    OutputStreamWriter(proc.getOutputStream()));
> BufferedReader in = new BufferedReader(new
>    InputStreamReader(proc.getInputStream()));
>

no real comment, as I don't have much experience using pipes on Windows.


>    Files
>
>    One process writes to the end of a file, the other reads
>    from the end of the file? - I never tried this, don't know
>    if it is guaranteed to work that one process can detect and
>    read, whether the other has just appended something to a file.
>
>    What if the processes run very long and the files get too
>    large? But OTOH this is very transparent, which makes it easy
>    to debug, since one can open the files and directly inspect
>    them, or even append commands manually with »copy con file«.
>

IME, I have often seen synchronization issues in these cases. sometimes 
the OS will refuse to let multiple programs access the same file at the 
same time, but sometimes it does work (I think depending on how the file 
is opened and which flags are given and similar).

if just naively using "fopen()" or similar (in C), IME/IIRC, the OS will 
typically only allow a single version of the file to be open at once 
(not necessarily as limiting as it may seem).


in scenarios where it has worked (multiple versions can be opened), it 
often seems like the OS is "lazy": one process will see an out-of-date 
version of the file data (the data will often be out-of-date until the 
writer closes the file or similar).

I never really felt all that inclined to look into the how/why/when 
aspects of all this.

a partial exception is when using shared-memory, which tends to stay 
up-to-date.


these issues don't seem to really pop up so much if one passes data in 
an "open file, write, close file" or "open file, read, close file" 
strategy (then the file is always seen up-to-date, and typically the 
chance of clash remains fairly small).

this strategy is arguably not very efficient, but it is fairly simple 
and tends to work "well enough" for many use cases (particularly passing 
"globs of data once in a great while", or when operating at 
"user-interaction" time-frames, such as the file is reloaded, say, 
because the user just saved to it).

if done well, this can be used to implement things like a "magic 
notepad", whereby data edited/saved in Notepad is automatically 
reflected in the running app (say, by polling+"stat()", then processing 
the file if it has changed).

conceptually, the latency should only really be limited by polling rate 
(although granted polling isn't free, and a process bogging down the 
system by polling a file in a tight loop isn't necessarily desirable 
either).


another advantage of files is that they are more amendable to "makeshift 
options" than some of the other strategies (one doesn't really need to 
care what apps are thrown in the mix, so long as they can read/write the 
files in question).


>    Sockets
>
>    This is slightly less transparent than files, but has the
>    advantage that it becomes very easy to have the two
>    processes running on different computers later, if this
>    should ever be required. Debugging should be possible
>    by a man-in-the-middle proxy that prints all information
>    it sees or by connecting to the server with a terminal.
>

I have used sockets for IPC before fairly well.

a minor issue with TCP for IPC though is that sometimes the buffering 
does something very annoying:
no matter how long one waits, TCP will not send the data until a certain 
amount has been written to the socket (IIRC, one can disable buffering 
or similar to prevent this, but unbuffered sockets can be evil on a 
network if used naively, such as writing an individual byte or datum at 
a time, rather than sending the entire message in a single write, since 
an unbuffered socket may attempt to send a datagram for *every* write to 
the socket).

TCP works fairly well for transmitting lots of small messages (and apart 
from the potential buffering issue has very little latency).

UDP also has some merit, but the big annoying hassle of having to pack 
ones' messages into UDP datagrams (however, UDP is much more resistant 
against stalls, which can easily become an issue for TCP sockets if 
going over the wider internet, however UDP is unreliable and unordered 
which also needs to be taken into account).


>    JNI
>
>    JNI might be used to access code written in C or
>    ABI-compatible languages. This should be fast, but I heard
>    that it is error prone to write JNI code and needs some
>    learning (code less maintainable)?
>

JNI can work, but is also annoying in some ways.

if one simply wants to call functions or pass data or messages to/from C 
code, it works fairly well. JNI is, however, not readily capable of IPC 
AFAIK. it also may result in some level of "physical coupling" between 
code in the languages in question (may or may not be desirable, probably 
depends on the task, often it is preferable IME to avoid coupling where 
possible, even often within code within the same language).

it is also not necessarily all that much more convenient than options 
such as sockets (likely depends a lot on the task though, for many, it 
may just be easier to write a message parser/dispatcher for whatever 
comes over the socket).

Back to comp.lang.java.programmer | Previous | Next | Find similar | Unroll thread

Thread

Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-06 01:48 -0700

csiph-web