Any faster cross boundaries comms than Remoting?

  • Thread starter Thread starter Urs Vogel
  • Start date Start date
U

Urs Vogel

Hi

For my application server, I had to overcome some limitations in older
COM-database drivers, whers sessions per driver instance are limited.
Instantiating the COM component several times does not help, since it still
reports the same Process ID to the DB server, so the limit persists.

When launching several external components (EXEs), each loading its own
database driver, the limitation problem is solved. I built this using .Net
remoting, where the application server is a multi client of these external
..Net components. It works fine, but this solution performs about factor 3
slower than binding the driver directly into the application server.

Now this is my question: is there's a faster way than .Net Remoting's way of
talking across boundaries to a .Net process on the same machine? Any hints
are appreciated.

Thanks, Urs
 
You can try to work directly with .NET sockets ( although it will take more
effort to implement ).
 
Urs Vogel said:
Hi

For my application server, I had to overcome some limitations in older
COM-database drivers, whers sessions per driver instance are limited.
Instantiating the COM component several times does not help, since it
still reports the same Process ID to the DB server, so the limit persists.

When launching several external components (EXEs), each loading its own
database driver, the limitation problem is solved. I built this using .Net
remoting, where the application server is a multi client of these external
.Net components. It works fine, but this solution performs about factor 3
slower than binding the driver directly into the application server.

Now this is my question: is there's a faster way than .Net Remoting's way
of talking across boundaries to a .Net process on the same machine? Any
hints are appreciated.
Click to expand...

The fastest IPC mechanisms (on the same machine) are synchronization objects
(mutexes, events...) and shared memory. AFAIK there is no managed support
for shared memory built into the .NET framework, but you might find
components on the internet; Otherwise, you could still P/Invoke the relevant
API functions yourself.

(C++ sample code can be found here:
http://msdn.microsoft.com/library/d.../fileio/base/creating_named_shared_memory.asp)

As both processes can share synchronization objects and physical memory the
performance is comparable to in-process cross-thread communication.

BTW: COM uses shared memory for out-of-processes communication on the same
machine.

Niki
 
I wrote a wrapper for shared memory a while back. You can find it here:

http://staff.develop.com/richardb/weblog/permalink.aspx/32c3abfb-bac9-4e19-bbc5-39ca338d906d

HTH

Richard Blewett ? DevelopMentor
http://staff.develop.com/richardb/weblog
?
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/
Hi

For my application server, I had to overcome some limitations in older COM-database drivers, whers sessions per driver instance are limited.
Instantiating the COM component several times does not help, since it still reports the same Process ID to the DB server, so the limit persists.

When launching several external components (EXEs), each loading its own database driver, the limitation problem is solved. I built this using .Net remoting, where the application server is a multi client of these external .Net components. It works fine, but this solution performs about factor 3 slower than binding the driver directly into the application server.

Now this is my question: is there's a faster way than .Net Remoting's way of talking across boundaries to a .Net process on the same machine? Any hints are appreciated.

Thanks, Urs


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.760 / Virus Database: 509 - Release Date: 10/09/2004

[microsoft.public.dotnet.languages.csharp]
 
Urs,

If you can afford to develop against the .NET 2.0 beta (for a product to
be released later), you might want to try the IpcChannel for remoting. It
basically uses named pipes to communicate, which is a much faster mechanism
than sockets.

Hope this helps.
 
Thanks for the hint, I'll look into this for future releases, but for the
moment I have to stick to released techs.

Urs

Nicholas Paldino said:
Urs,

If you can afford to develop against the .NET 2.0 beta (for a product
to be released later), you might want to try the IpcChannel for remoting.
It basically uses named pipes to communicate, which is a much faster
mechanism than sockets.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Urs Vogel said:
Hi

For my application server, I had to overcome some limitations in older
COM-database drivers, whers sessions per driver instance are limited.
Instantiating the COM component several times does not help, since it
still reports the same Process ID to the DB server, so the limit
persists.

When launching several external components (EXEs), each loading its own
database driver, the limitation problem is solved. I built this using
.Net remoting, where the application server is a multi client of these
external .Net components. It works fine, but this solution performs about
factor 3 slower than binding the driver directly into the application
server.

Now this is my question: is there's a faster way than .Net Remoting's way
of talking across boundaries to a .Net process on the same machine? Any
hints are appreciated.

Thanks, Urs
Click to expand...
Click to expand...
 
Back
Top