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 <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
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
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
--
Kyley Harris
+64-21-671821
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
