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