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\xxxxx-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.
