Any faster cross boundaries comms than Remoting?

[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

[Nadav]

You can try to work directly with .NET sockets ( although it will take more
effort to implement ).

"Urs Vogel" wrote:

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

[Niki Estner]

"Urs Vogel" <uv****@msn.com > wrote in
news:uj******** ******@TK2MSFTN GP15.phx.gbl...

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.

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/de...red_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

[Richard Blewett [DevelopMentor]]

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

http://staff.develop.com/richardb/we...5-39ca338d906d

HTH

Richard Blewett ? DevelopMentor
http://staff.develop.com/richardb/weblog
?
nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.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.publi c.dotnet.langua ges.csharp]

[Urs Vogel]

Thanks Richard, this will definitely do it.

Urs

"Richard Blewett [DevelopMentor]" <ri******@devel op.com> schrieb im
Newsbeitrag news:ue******** *****@TK2MSFTNG P14.phx.gbl...

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

http://staff.develop.com/richardb/we...5-39ca338d906d

HTH

Richard Blewett ? DevelopMentor
http://staff.develop.com/richardb/weblog
?
nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.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.publi c.dotnet.langua ges.csharp]

[Urs Vogel]

Niki

Thanks, Richard Blewett sent me a link to a similar sample solution.

Urs

"Niki Estner" <ni*********@cu be.net> schrieb im Newsbeitrag
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

"Urs Vogel" <uv****@msn.com > wrote in
news:uj******** ******@TK2MSFTN GP15.phx.gbl...

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.

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/de...red_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

[Nicholas Paldino [.NET/C# MVP]]

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]
- mv*@spam.guard. caspershouse.co m

"Urs Vogel" <uv****@msn.com > wrote in message
news:uj******** ******@TK2MSFTN GP15.phx.gbl...

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

[Urs Vogel]

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 [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> schrieb
im Newsbeitrag news:uj******** ******@TK2MSFTN GP11.phx.gbl...

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]
- mv*@spam.guard. caspershouse.co m

"Urs Vogel" <uv****@msn.com > wrote in message
news:uj******** ******@TK2MSFTN GP15.phx.gbl...

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