I know enough of that kind of problems. Just to summarize: 1) TCP/IP is the only standard way to use Remoting in .NET. Both TcpChannel & HttpChannel need TCP/IP. Other channels have to be installed separately. 2) TCP/IP require at least a loopback network card interface. So, for IPC between processes on the same machine, this could be a problem. Without going too far with embedded machine examples, if you have a notebook with a Network PCMCIA Card, when you are disconnected from the network removing the card (sometime it happens, otherwise why on earth do you buyed a notebook?) you have no TCP/IP available, neither 127.0.0.1 addess is reachable. TCP/IP stack is not available. Remoting doesn't work. 3) Named Pipe provides security based on Win32 access tokens. Named Pipes communicates using shared memory (memory mapped files) between connections on the same machine if you use \\.\pipe\mypipename as pipe name, but if you use \\MYPCNAME\pipe\mypipename where MYPCNAME is your PC name, then Named Pipe go through an available network protocol (like TCP/IP) to make the connection. Note you can use \\192.168.1.42\pipe\mypipename as a named pipe name, so you can avoid name-resolution problem and make sure to use TCP/IP protocol on a client which has other installed network protocols in common with the named pipe server. 4) When you use Named Pipe on local machine (using '.' as machine name), you have soooo better performance than going through TCP/IP or other network protocols. 5) I never compared Named Pipe with COM communications, and probably it's not an easy task, because you are really comparing the serialization you use on TCP/IP (of course you have to go on the binary one) with the marshalling capabilities of Platform Invoke, and we know that numerb and type of parameters make a big difference here (non-isomorphic types are really slower than isomorfic ones).
So, if you want to go fast with Remoting on the same machine, use Named Pipes. If you want to go faster, use memory mapped files and say bye-bye to type safety (your code is going to be unverifiable). Anyway remember that you can choose the faster Remoting channel, but remoting serialization is the real bottleneck here. Why .NET doesn't have a good and reliable IPC solution not related to TCP/IP? Because (I suppose) named pipes are NT-specific (9x is not capable to instantiate a named pipe server) and there isn't a standard IPC channel (or we can consider RPC a candidate?). Marco -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of Shawn A. Van Ness Sent: sabato 18 gennaio 2003 4.03 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? Maybe... but I'd prefer a true local-only solution, so that I don't have to endure the security liability of listening on a network endpoint. I can't believe .NET is leading so many folks to use TCP for what would be interprocess comm purposes... scares the heck out of me, quite frankly. -S On Fri, 17 Jan 2003 11:22:15 -0800, Howard Hoffman <[EMAIL PROTECTED]> wrote: >Doesn't Named-Pipe transport w/in machine get implemented by Win32 as >memory-mapped file (i.e. shared memory)? > >You can read messages from the Advanced DOTNET archive, unsubscribe >from Advanced DOTNET, or subscribe to other DevelopMentor lists at >http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
