[DUG] Reference counting

[John Bird]

Almost hestitate to mention it, but there is another way to pass string or
arbitrary information between applications that is extremely low-tech and
universal.  (It may not suit real-time immediate messaging).  And that is
via a file, with fixed content and one side monitors a block of data and the
other side modifies it.

I have used a scheme like this for years to communicate with a background
printer servicing program (the idea of it was to allow a non-networked
printer to be shared - the print command and filename was passed to the pc
which had the printer - but could be used for any purpose).  I did it this
way because:

1 - familiar with Unix where everything in the OS including memory can be
seen in the filesystem somewhere
2 - I was communicating between 2 programs in different languages, only one
in Delphi
3 - It allowed with no modifications the same communication between
different pcs - the file was in a shared folder on the server.
4 - differing versions of windows on the network
5 - Once a file is being continuously monitored Windows will cache it anyway
- performance hit was always undetectable.

Only trick is to be not rewriting the file, but updating a block of data, eg
first 512 bytes of the file and use that.  Files are opened using
TFileStream, The 'listener' reads the block in a timed loop, and the
'sender' writes the block using 

Eg
Fs:TFileStream;
Chbuff:array[1..512] of char;

        fs.seek(byteoffset,soFromBeginning);
        sizewrite:=fs.write(chbuff,lreclen);

And whenever does a 'send' does a 	fs.free; and reopens to force the
cache update - that's the only performance penalty, and if the loop is not
too frequent it has no penalty.  And this gives simple debugging - you just
have a file to look at, and I also have a third program (a monitor) that
could look at the shared file and monitor and alter options, so it was a 3
way communication.

John

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
Behalf Of Ross Levis
Sent: Friday, 25 November 2005 12:07 p.m.
To: leighw at softtech.co.nz; NZ Borland Developers Group - Delphi List
Subject: Re: Re: [DUG] Reference counting


TCP is definately useful.  I've implemented a remote utility to check 
the status of my player and provide some control and details of what's 
playing etc, but I decided to use the memory sharing facility because I 
wanted the audio engine to be separate from the application which 
controls it.  So I have 2 apps which needed fast communication, since 
it's providing VU meter data and elapsed times etc continuously 20 times 
a second.  I don't think TCP would handle that well.

This system allows users to install an update to the controlling 
application without stopping play, assuming the audio engine doesn't 
need updating as well.  This is useful since it is designed for radio 
broadcasting.

Ross.

----- Original Message ----- 
From: "Leigh Wanstead" <leighw at softtech.co.nz>
To: <delphi at ns3.123.co.nz>
Sent: Friday, November 25, 2005 11:23 AM
Subject: RE: Re: [DUG] Reference counting


Frankly speaking, I like TCP so much that I once study TCP protocol in 
Linux
source code.

Regards
Leigh
http://www.salenz.com

-----Original Message-----
From: Kyley Harris [mailto:kyleyharris at gmail.com]
Sent: Friday, 25 November 2005 10:58 a.m.
To: leighw at softtech.co.nz; NZ Borland Developers Group - Delphi List
Subject: Re: Re: [DUG] Reference counting



> TCP is universal. But modern solution will be web service. ;-)

I doubt ;) Its too slow and inefficient. The fact that its generic might be
an advantage in some ways, but the fact that the more generic you get (which
is like getting more
microsoft) the easier it is
to hack your system still turns a lot of companies off. There isn't anything
particularly wrong with the concept, but the implementation is lame.

Also, Its slower than a snail last time I tried. Which is probably why 
so
many are going back to
Terminal Clients, rather than rich thin clients. They have been let down by
the absurb network traffic speeds of soap servers and other generics. If
people of the modern era still focused on speed AND quality, like many of
you must remember from the good old 386 days, then we'd all be pumping 
out
high power thin/rich clients.

There will never be a win to that discussion though, because everyone 
has
preference.


_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz http://ns3.123.co.nz/mailman/listinfo/delphi

_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz http://ns3.123.co.nz/mailman/listinfo/delphi