Document .NET Remoting alternative - Sockets

[karelz]

Our porting doc is vague on replacement of .NET Remoting. We concluded System.Net.Sockets is best alternative.

There is worry that it is tricky to write, so we should provide a sample (maybe in docs repo?).

[morganbr]

Sockets seem like an extremely low-level replacement for a very high-level API. Why should people use sockets instead of ASP.NET or WCF, which are a closer level of abstraction to remoting?

[karelz]

Both approaches need also server on both sides, right? Http server is either legacy/compat-only HttpListener, which we don't recommend. Or ASP.NET which is not available on .NET Native. WCF server is not available neither in .NET Core nor in .NET Native AFAIK.

[morganbr]

That really depends on what kind of communication you're doing. Lots of problems can be modeled as client/server communication and only need a server on one side, which should make ASP.NET a good choice.

I'm not sure the lack of ASP.NET on UWP is a good reason not to suggest it for .NET Core. UWP apps rarely talk to each other; they much more frequently communicate with outside servers (that could use ASP.NET as a server). For inter-process communication within UWP, WinRT is a reasonable alternative.

[karelz]

Fair, Sockets is better from .NET Standard perspective. I am not married to particular solution, it would be nice to have a simple starter sample for folks though. We can have more of them :)

[akoeplinger]

I agree with @morganbr that sockets is on a whole different level than an RPC framework such as Remoting/WCF.

A comparable alternative would be e.g. gRPC (http://www.grpc.io/), they do have a C#/.NET Core client and server examples: http://www.grpc.io/docs/quickstart/csharp.html

[karelz]

@akoeplinger that's a great idea to suggest 3rd party libraries - is there a list of RPC solutions somewhere? Maybe on .NET Foundation site? So that we don't suggest just one specific?

There is still value to also mention "inbox" alternatives (even though poor) as not everyone can pull in 3rd party NuGet packages (yes, sadly, some enterprises have those requirements and limitations).

[akoeplinger]

I don't know of a list off the top of my head that's specific to RPC solutions.

Something like the Messaging section in https://github.com/Microsoft/dotnet/blob/master/dotnet-developer-projects.md would probably be good (the ones there are more in the message bus / distributed direction, like Orleans, Akka.NET etc).

[karelz]

Orleans and Akka.NET are under Platforms section. I don't see your gRPC there at all. Should we add it? What exactly would you propose to link? (sorry, I am not familiar with most of the libraries, so have to rely on suggestions of others)

BTW: Just submitted a PR to make the sections linkable: https://github.com/Microsoft/dotnet/pull/377.

[akoeplinger]

Orleans and Akka.NET are under Platforms section. I don't see your gRPC there at all. Should we add it?

No, gRPC is probably a better fit for Messaging or Libraries. The list in the Microsoft/dotnet repo is community maintained so anyone can add their project to it.

What exactly would you propose to link?

None of the existing sections is 100% perfect for a Remoting replacement, but I think linking to the Messaging and Libraries section would probably be a good start.

[davidmatson]

From a related issue (#17688) and as mentioned above, I think it's worth distinguishing which abstraction level an IPC mechanism supports, and choosing based on that and other tradeoffs. For something RPC-like, I think the only modern built-in option is an HTTP stack.

Here's a synthesis of options & tradeoffs after an internal survey (more from the Windows/platform mechanism side than from the .NET side) on what options to consider for local IPC in .NET.

• Things that operate above the stream level/at an app contract level:
  • Modern option: HTTP
  • Legacy options: WCF, .NET Remoting, COM Interop (?)
• Things that operate at the stream level: Sockets, Pipes
• Things that operate below the stream level: File Mapping (unsynchronized access to whole chunks of bytes, rather than synchronized communication via streams of bytes)

Some details regarding tradeoffs:

• File Mapping: Very low level; does not even provide a signaling mechanism to say when data is ready to be read. It requires some other IPC/signaling mechanism to do that part. But because it's just shared memory, there's not even any data copying, so it's extremely fast (basically can't get faster than this).
• Pipes:
  • vs sockets: Pipes can handle message framing for you (splitting up a stream of bytes into distinct messages, via Message mode), while with sockets you have to add that part yourself (or use something higher level-like HTTP that already does it), so in at least that one sense pipes are a slightly higher-level abstraction (not to say they’re better that sockets).
  • vs file mapping/shared memory: I think I've heard that pipes are fairly close to an abstraction that just takes file mapping/shared memory + signaling and packages them together into a synchronized byte stream view, so it should be very fast/cheap for local IPC.

If that's all accurate, a summary would be that for .NET, the closest modern replacement to .NET Remoting is some kind of HTTP stack, and that for general purpose local IPC there are two good byte stream-level options: sockets (cross-plat; easy to move off-machine if remote IPC is needed) or pipes (Windows-only, but likely excellent performance for local IPC). For the ultra-perf-critical, there’s also file mapping/shared memory, with the tradeoff that it’s even lower-level and requires handling signaling separately.

If this all sounds right, I could try to work up a documentation PR.

[karelz]

Documentation, needs to be in 2.0, but can be Post-ZBB.

[chaseaucoin]

As an RPC alternative to System.Remoting, WCF, or Sockets, I generally use ZeroMQ It is robust for RPC it sits on top of sockets but is much friendlier from an end-developer syntax standpoint. It also allows for other strategies like push-pull, pub sub, etc..

[jakesays-old]

Sockets is hardly a replacement for remoting.

[chaseaucoin]

Is there more to that synopsis? Which parts "Specifically" are you interested in that you don't get from sockets? BTW, most IPC is handled via socket. Are you concerned about higher level abstractions or is it something else?

[aelij]

The StreamJsonRpc library used by VS for IPC works with any stream, including pipes. I found it a very adequate replacement for Remoting.

[jmrnilsson]

To me both signalr and sockets seem like viable options for what I need. The discussion was very helpful anyways.

https://docs.microsoft.com/en-us/aspnet/core/signalr/dotnet-client?view=aspnetcore-2.1

[lostmsu]

@jmrnilsson , unfortunately, SignalR server is only supported for ASP.NET Core. So no UWP.

[karelz]

gRPC is likely the best choice. We are investing now in the area.