[DUG] Reference counting

[Kyley Harris]

Why not? Scalability. You now have a system that will only run on cpu.
With Media streaming apps such as Ross is writing it is certainly an  
advantage to
have a scalable app that can run on more than one process to take  
advantage of streaming tools.

there is nothing inherantly wrong with using files, or memory or whatever,  
until oneday you want/need to
scale your application and if you havent architected it well, which I find  
so many havent, you will be
doing a rewrite, instead of swapping one message streaming protocol out  
for another.

So all I am saying is that the Pro's list for TCP is (in most cases) a lot  
higher than any other method for
passing messages from one process to another. Advantages? Any of my  
systems will talk to any other system from anywhere at all in the lan/wan,  
localhost is just another case of clustered communication. I build from  
the ground up for scalability. That is an advantage. All the time I  
contract to companies who after years of developing things using files,  
shared memory etc, are growing and then go, oh hell. It's not scalable is  
it?

If you fit in that category, then contrats.

On Fri, 25 Nov 2005 14:14:41 +1300, Leigh Wanstead <leighw at softtech.co.nz>  
wrote:

> Why not use share memory? Nothing will be faster than sharing the same
> memory block. Of course need to be little careful.
>
> Regards
> Leigh
> http://www.salenz.com
>
> -----Original Message-----
> From: delphi-bounces at ns3.123.co.nz
> [mailto:delphi-bounces at ns3.123.co.nz]On Behalf Of Kyley Harris
> Sent: Friday, 25 November 2005 2:05 p.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: Re: [DUG] Reference counting
>
>
>> 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.
>
> ;) I Think you should test. TCP runs as fast as your network card. so
> around 10mb per second
> on a 100mb card.
>
> The following code runs at around 5,500 iteratations a second as a ping
> returning same
> quantity of data, not 20.... As I said, its not TCP thats slow, its the
> programmers who implement
> stuff on top of it.
>
> procedure TForm1.BitBtn1Click(Sender: TObject);
> var
>    i:integer;
>    l:TLIst;
>    c:cardinal;
>
> begin
>    IdTCPClient1.Host := 'localhost';
>    IdTCPClient1.Port := 11000;
>    IdTCPClient1.Connect;
>
>    i := 0;
>    c := GetTickCount;
>    repeat
>
>      IdTCPClient1.WriteLn('Testing one two three four five size seven
> eight');
>      IdTCPClient1.ReadLn;
>      Inc(i);
>    until GetTickCount-c > 1000;
>    showmessage(inttostr(i));
>
>
> end;
> On Fri, 25 Nov 2005 12:07:06 +1300, Ross Levis <ross at stationplaylist.com>
> wrote:
>
>> 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.
> _______________________________________________
> 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



-- 
Kyley Harris
+64-21-671821