Message-Id: <m0xG0NO-000S1oC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT edu DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
Organization: INTI
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com,
        Michael Mauch <michael DOT mauch AT gmx DOT de>
Date: Tue, 30 Sep 1997 14:28:42 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: DJGPP, interprocess communication, and DPMI
Precedence: bulk

Eli wrote:
> On Mon, 29 Sep 1997, Salvador Eduardo Tropea (SET) wrote:
> 
> > Is easy to communicate only 2 process but for more I think is more complex.
> > Any ideas?
> 
> First, you can have separate buffers for each connection, allocated by
> the TSR when the connection is established.  Then each pair of
> processes only checks its own buffer for any new data.
Yes I thinked about that, but making that only 2 copies can live and talk. For 
some purposses is OK, but not for all. My main idea is to communicate copies of 
my editor (RHIDE perhaps too). The first application could be indicate that 
another copy of the program is editing some file and in this way avoid that 2 
copies make chnages at the same time ;-). But is just a low priority 
experiment.
 
> If that's too complicated, or wastes too much memory, a single buffer
> could be used, with a special magic signature at the beginning of data
> that identifies the connection.  (The first data exchange would then
> need to be with some kind of generic sugnature and hold the specific
> signature to be used for the rest of the connection.)
Yes!, look in the code I posted, I'm using:
MAGIC, From ID, To ID (0xFFFFFFFF==broadcast), Type, Data...
But is almost a network packet ;-)))).
 
> There's also a problem of using the same buffer for reading and
> writing by several pairs of connected processes.  A simple solution
> would be to wait until the buffer is emptied (if the message in the
> buffer appears to belong to another connection).  
I use it, when you read a message for you, you delete the first char of the 
magic and the buffer is free. When I transmit first I check  if the buffer is 
empty, if not I start a timer if after some time nobody taked the message I 
assume the message is no longer valid and I transmit.

> Another possibility
> is to allow appending data to the buffer without destroying its
> previous contents and making it possible for the reading side to read
> and empty only part of the buffer's data.
Sounds interesting, but pretty complex if the data is of variable size.

> Anyway, these problems are solvable, one way or the other.  
Yes.
> So I would
> suggest at first to make this work for a single connection, and leave
> improvements to later releases.
Did you got my code?, I'll send you a copy. It works for a pair of programs, 
uses the Bill's TB TSR, the one he propossed for a common transfer buffer.

SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013