Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
I could be wrong but if you set 0 as the port that the app should listen on then the remoting channel picks an open port.. now if you load via TS or fast user switching should this not be a separate process and different port? Here is the example you might be looking for [1]... HTH scott [1]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwi nforms/html/reaworapps1.asp -Original Message- From: Shawn A. Van Ness [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 2:12 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? I feel perhaps I'm not making my #1 complaint clear: if I open up a *well-known* TCP port, even if it's just on the loopback adapter or whatever, my app will break under Terminal Services (eg: Remote Desktop, and Fast User Switching). I'd like for my app to not crash or choke, just because my roommate and I are both running instances of it, in different FUS sessions on our XP Home machine -- IOW, I'm looking for intra-session IPC, not intra-machine IPC. (If I let the OS assign a TCP port dynamically, then I'd need some way to publish/communicate that port number to other instances of the app in the current session... then I'm back to square one.) The nice thing about named pipes is the ability to create one with a name like \\.\pipe\Local\x-guidoruriorsomething-xxx (note the Local keyword) thus ensuring instances running in different TS/RD/FUS sessions don't interfere with each other. But IIRC, any user that happens to be running as Session 0 will have his pipe exposed on the network. Sure, there is a security descriptor on the pipe... but the default secdesc is a little too open for my taste, and the thought of p/invoking those nasty NT security-descriptor manipulation functions makes me cringe. So, a remoting channel based on memory-mapped files or LRPC would be ideal. I'll add this to my pet-project list, but it's the kind of thing I can never find time to do except while I'm looking for a job. :] MS must have hundreds of apps that rely on LRPC for interprocess comm... I just can't believe they'd punt this out of the featurelist for .NET. :( -S 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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
But you get no real benefit , selecting port 0 you are using ip and you still get in memory IP packest generated to send over the in memory port. There is nothing here which cant be done its only a question of difficulty eg easy Remoting - you get the protocol and remoting overheads less easy sockest - you get the IP overhead and no class etc just raw data . more difficult - DDE , COM , COM+ etc , no protocol overhead and with some formats eg DDE you get just Raw Data. I still would be interested to see the performance of talking to a a registered COM object versus IP remoting. Ben -Original Message- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Densmore Sent: Friday, 24 January 2003 1:08 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? I could be wrong but if you set 0 as the port that the app should listen on then the remoting channel picks an open port.. now if you load via TS or fast user switching should this not be a separate process and different port? Here is the example you might be looking for [1]... HTH scott [1]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwi nforms/html/reaworapps1.asp -Original Message- From: Shawn A. Van Ness [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 2:12 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? I feel perhaps I'm not making my #1 complaint clear: if I open up a *well-known* TCP port, even if it's just on the loopback adapter or whatever, my app will break under Terminal Services (eg: Remote Desktop, and Fast User Switching). I'd like for my app to not crash or choke, just because my roommate and I are both running instances of it, in different FUS sessions on our XP Home machine -- IOW, I'm looking for intra-session IPC, not intra-machine IPC. (If I let the OS assign a TCP port dynamically, then I'd need some way to publish/communicate that port number to other instances of the app in the current session... then I'm back to square one.) The nice thing about named pipes is the ability to create one with a name like \\.\pipe\Local\x-guidoruriorsomething-xxx (note the Local keyword) thus ensuring instances running in different TS/RD/FUS sessions don't interfere with each other. But IIRC, any user that happens to be running as Session 0 will have his pipe exposed on the network. Sure, there is a security descriptor on the pipe... but the default secdesc is a little too open for my taste, and the thought of p/invoking those nasty NT security-descriptor manipulation functions makes me cringe. So, a remoting channel based on memory-mapped files or LRPC would be ideal. I'll add this to my pet-project list, but it's the kind of thing I can never find time to do except while I'm looking for a job. :] MS must have hundreds of apps that rely on LRPC for interprocess comm... I just can't believe they'd punt this out of the featurelist for .NET. :( -S 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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
Sure, sure -- but then how would the listening app publish/communicate that port number, so that other client apps could connect to it? I would need some kind of simple, secure, per-session comm. channel for that -- so I'm back to square one. In the article you cite, the author seems to use a registry key for that purpose... ugh. IMHO, the technique of using HKCU to publish a TCP endpoint is totally broken, from both a security and multi-session perspective: 1) Security: Listening on TCP is always dangerous... anyone with a port-scanner and IP-spoofing tool can throw malicious messages at my app. Even binding to localhost doesn't help -- in a TS environment, an underpriv'd user could throw malicious messages at a port owned by an administrator... someone please tell me if I'm wrong, or if I'm overlooking something (I'm not a TCP guru). 2) Multi-session support: I don't know about NT4/Win2k, but I believe I've heard that future versions of Windows Server will allow TS to be configured to allow multiple instances of a single user session (eg: Administrator). So using HKCU to publish what would be per-session endpoint info is simply not good enough... again, someone please tell me if I'm wrong. I'm starting to wonder if this isn't the reason we're seeing such an explosion of system services, in Windows XP and later -- because secure, robust, intrasession IPC is just too hard, without some kind of system-wide intermediary...? :-/ -S On Thu, 23 Jan 2003 21:07:39 -0800, Scott Densmore [EMAIL PROTECTED] wrote: I could be wrong but if you set 0 as the port that the app should listen on then the remoting channel picks an open port.. now if you load via TS or fast user switching should this not be a separate process and different port? Here is the example you might be looking for [1]... HTH scott [1]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwi nforms/html/reaworapps1.asp -Original Message- From: Shawn A. Van Ness [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 2:12 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? I feel perhaps I'm not making my #1 complaint clear: if I open up a *well-known* TCP port, even if it's just on the loopback adapter or whatever, my app will break under Terminal Services (eg: Remote Desktop, and Fast User Switching). I'd like for my app to not crash or choke, just because my roommate and I are both running instances of it, in different FUS sessions on our XP Home machine -- IOW, I'm looking for intra-session IPC, not intra-machine IPC. (If I let the OS assign a TCP port dynamically, then I'd need some way to publish/communicate that port number to other instances of the app in the current session... then I'm back to square one.) The nice thing about named pipes is the ability to create one with a name like \\.\pipe\Local\x-guidoruriorsomething-xxx (note the Local keyword) thus ensuring instances running in different TS/RD/FUS sessions don't interfere with each other. But IIRC, any user that happens to be running as Session 0 will have his pipe exposed on the network. Sure, there is a security descriptor on the pipe... but the default secdesc is a little too open for my taste, and the thought of p/invoking those nasty NT security-descriptor manipulation functions makes me cringe. So, a remoting channel based on memory-mapped files or LRPC would be ideal. I'll add this to my pet-project list, but it's the kind of thing I can never find time to do except while I'm looking for a job. :] MS must have hundreds of apps that rely on LRPC for interprocess comm... I just can't believe they'd punt this out of the featurelist for .NET. :( -S 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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
I brought this up on the MS .NET remoting newsgroup last summer. I can't believe MS wants us to use TCP for IPC ON THE SAME MACHINE. So inelegant. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
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 s 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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
A Serviced Component living inside a COM+ Server Application could be used as an IPC broker. It'd be always-on, resident in RAM. If anything needed to be persisted, it could be stored in a local XML file or an ISAM table. Or what about a message queue for IPC? Not as flexible as a SC but you get the storage question answered for free. Maybe a combo of SC+MSMQ for persistent storage. Or if you want to live with the assumption that TCP is always on the computer, install the loopback adapter and give it an internal Class C address (make it non/routable if you want). Since NT4, I've been installing the loopback adapter as part of a server build. It's better to have it and not need it It gets away from worrying about what other apps might do with 127.0.0.1. It also lets you run public services on the box that you want kept private. :) As a ferinstance, I needed a centralized way for several Win2K Services living on the same hardware to send mail. I created an SMTP server on the loopback NIC and set it to relay for everyone with no security checks. Since the SMTP server could only listen to network traffic inside the box, mail would only be delivered for my unattended processes on the same server; external hosts can't see that port 25 is open because they can't even reach it. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
I feel perhaps I'm not making my #1 complaint clear: if I open up a *well-known* TCP port, even if it's just on the loopback adapter or whatever, my app will break under Terminal Services (eg: Remote Desktop, and Fast User Switching). I'd like for my app to not crash or choke, just because my roommate and I are both running instances of it, in different FUS sessions on our XP Home machine -- IOW, I'm looking for intra-session IPC, not intra-machine IPC. (If I let the OS assign a TCP port dynamically, then I'd need some way to publish/communicate that port number to other instances of the app in the current session... then I'm back to square one.) The nice thing about named pipes is the ability to create one with a name like \\.\pipe\Local\x-guidoruriorsomething-xxx (note the Local keyword) thus ensuring instances running in different TS/RD/FUS sessions don't interfere with each other. But IIRC, any user that happens to be running as Session 0 will have his pipe exposed on the network. Sure, there is a security descriptor on the pipe... but the default secdesc is a little too open for my taste, and the thought of p/invoking those nasty NT security-descriptor manipulation functions makes me cringe. So, a remoting channel based on memory-mapped files or LRPC would be ideal. I'll add this to my pet-project list, but it's the kind of thing I can never find time to do except while I'm looking for a job. :] MS must have hundreds of apps that rely on LRPC for interprocess comm... I just can't believe they'd punt this out of the featurelist for .NET. :( -S You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
You shouldn't need to use sockets ( what if there is no IP stack) , .NET object are COM/COM+ objects which are very advanced forms of IPC. For more info see the Microsoft.ComServices namespace , here is a start. http://www.csharphelp.com/archives/archive116.html. Disclaimer I am no expert on this , but Word and Excel have been using this since office was first released (COM was an enhancement of DDE) which is way before network stacks became common. Ben PS : On Unix people often use sockets as is easy...same for java , the recomendation is generally to use sockets for communicating to a process on the same machine to avoid the hassle and overhead of Corba / RMI . It is the same in .NET ,setting up remoting using sockets is trivial . -Original Message- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Shawn A. Van Ness Sent: Saturday, 18 January 2003 11:03 AM 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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
PS : On Unix people often use sockets as is easy...same for java , the recomendation is generally to use sockets for communicating to a process on the same machine to avoid the hassle and overhead of Corba / RMI . It is the same in .NET ,setting up remoting using sockets is trivial . When you use a connection to localhost, 127.0.0.1, it's no longer on the wire, correct? So if you limit listening to localhost you would have garaunteed both real ipc and no network access to your channel. I have an unproven assumption that ipc would be faster using tcp than using COM, though it is a reasonable suggestion. If both statements are true, you'd be hard pressed to choose COM over tcp when you facter in all the extraneous issues COM brings into a .net project. I tend to feel the same way about Named pipes, though ignorance has a lot to do with my feelings there. Named pipes between machines have been the source of s many network problems for me. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
I agree with you , I would use IP sockets / remoting as it is probably faster than COM. I was replying to Shawns comment and stated some options. Shawn said 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. 2 things to note though 1. Some machines dont have an Ip stack or a NIC. 2. Some drivers have been known to do silly things with 127.0.0.1. In addition if the program goes on a secure server you may still have to open the port , depending on the firewall software. Ben -Original Message- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Philip Nelson Sent: Sunday, 19 January 2003 10:50 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? PS : On Unix people often use sockets as is easy...same for java , the recomendation is generally to use sockets for communicating to a process on the same machine to avoid the hassle and overhead of Corba / RMI . It is the same in .NET ,setting up remoting using sockets is trivial . When you use a connection to localhost, 127.0.0.1, it's no longer on the wire, correct? So if you limit listening to localhost you would have garaunteed both real ipc and no network access to your channel. I have an unproven assumption that ipc would be faster using tcp than using COM, though it is a reasonable suggestion. If both statements are true, you'd be hard pressed to choose COM over tcp when you facter in all the extraneous issues COM brings into a .net project. I tend to feel the same way about Named pipes, though ignorance has a lot to do with my feelings there. Named pipes between machines have been the source of s many network problems for me. 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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
There is also the question of how much overhead a TCP connection imposes. Even localhost, and even not hirtting the wire - will the stream not be encoded into TCP packets? Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Ben Kloosterman [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 4:20 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? I agree with you , I would use IP sockets / remoting as it is probably faster than COM. I was replying to Shawns comment and stated some options. Shawn said 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. 2 things to note though 1. Some machines dont have an Ip stack or a NIC. 2. Some drivers have been known to do silly things with 127.0.0.1. In addition if the program goes on a secure server you may still have to open the port , depending on the firewall software. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
It would be a really cool pet project to develop a remoting channel over shared mem... but that's a heck of a lot of code to write. Anyone know if it's been done already? -S On Fri, 17 Jan 2003 07:16:10 -, Richard Blewett [EMAIL PROTECTED] wrote: You thought of using shared memory? In the early days of the .NET betas more than one person wrapped the win32 API to provide managed access. Regards Richard Blewett DevelopMentor -Original Message- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of Shawn A. Van Ness Sent: 16 January 2003 02:25 To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? I have two winforms apps that would like to talk to each other. In fact, two instances of the same winform app. I struggle to find a good approach for this, in .NET. Remoting? Yeah, sure -- but I don't want to open up a TCP port (for a variety of reasons, from security threat-surface considerations, to TS-awareness, to not wanting to trample the TCP port-space). And I can't require IIS to be installed and running. I'm considering using Jonathan Hawkins' NamedPipe-based remoting channel [1]... is that what everybody else is using? [1] http://www.gotdotnet.com/userfiles/jhawk/NamedPipeChannel.zip The way I see it, namedpipes beat tcp in two ways: (1) the space of endpoints is vastly larger (about 256 chars vs 15 bits), thus avoiding conflicts with other apps, and (2) the pipe name can be scoped to the current session, via the Local\ prefix, thus achieving ts-awareness. But I'm still concerned about the threat surface of listening on a named pipe... the pipe channel allows me to specify a security descriptor -- even the default is probably ok -- but I just don't believe my innocent little winforms app should be listening for signals on the network. I just can't believe there's no IPC mechanism built into .NET, out of the box. Am I missing something? Longing for the days of ncalrpc... -Shawn http://www.arithex.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. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
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.
Re: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC?
You thought of using shared memory? In the early days of the .NET betas more than one person wrapped the win32 API to provide managed access. Regards Richard Blewett DevelopMentor -Original Message- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of Shawn A. Van Ness Sent: 16 January 2003 02:25 To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Remoting: What is everybody doing for simple, robust, secure, efficient IPC? I have two winforms apps that would like to talk to each other. In fact, two instances of the same winform app. I struggle to find a good approach for this, in .NET. Remoting? Yeah, sure -- but I don't want to open up a TCP port (for a variety of reasons, from security threat-surface considerations, to TS-awareness, to not wanting to trample the TCP port-space). And I can't require IIS to be installed and running. I'm considering using Jonathan Hawkins' NamedPipe-based remoting channel [1]... is that what everybody else is using? [1] http://www.gotdotnet.com/userfiles/jhawk/NamedPipeChannel.zip The way I see it, namedpipes beat tcp in two ways: (1) the space of endpoints is vastly larger (about 256 chars vs 15 bits), thus avoiding conflicts with other apps, and (2) the pipe name can be scoped to the current session, via the Local\ prefix, thus achieving ts-awareness. But I'm still concerned about the threat surface of listening on a named pipe... the pipe channel allows me to specify a security descriptor -- even the default is probably ok -- but I just don't believe my innocent little winforms app should be listening for signals on the network. I just can't believe there's no IPC mechanism built into .NET, out of the box. Am I missing something? Longing for the days of ncalrpc... -Shawn http://www.arithex.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. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
