Update readme regarding default transport

This commit is contained in:
Steve Sanderson
2016-06-28 18:06:13 +01:00
committed by GitHub
parent b684aeb6d2
commit 44bd5f195e

View File

@@ -356,13 +356,15 @@ services.AddNodeServices(new NodeServicesOptions
**Available hosting models** **Available hosting models**
* `Socket` (default) * `Socket`
* Launches Node as a separate process, and communicates with it using named pipes (on Windows) or domain sockets (on Linux / OS X). * Launches Node as a separate process, and communicates with it using named pipes (on Windows) or domain sockets (on Linux / OS X).
* This is faster than `Http` because it uses a low-level binary protocol with very low overhead. It retains one continuous connection for the whole lifetime of the Node instance, so it doesn't have to keep waiting for new connections to open. * This is faster than `Http` because it uses a low-level binary protocol with very low overhead. It retains one continuous connection for the whole lifetime of the Node instance, so it doesn't have to keep waiting for new connections to open.
* `Http` * `Http` (default)
* Launches Node as a separate process, and communicates with it by making HTTP requests. * Launches Node as a separate process, and communicates with it by making HTTP requests.
* This primarily exists because it was implemented before `Socket`, but there's no particular reason to use it now that `Socket` is available. It could theoretically be useful if you wanted to run Node instances on separate servers (though there isn't currently any built-in API for configuring that). * This primarily exists because it was implemented before `Socket`, but there's no particular reason to use it now that `Socket` is available. It could theoretically be useful if you wanted to run Node instances on separate servers (though there isn't currently any built-in API for configuring that).
The default transport may change from `Http` to `Socket` in the near future, because it's faster.
### Custom hosting models ### Custom hosting models
If you implement a custom hosting model (by implementing `INodeServices`), then you can get instances of that just by using your type's constructor. Or if you want to designate it as the default hosting model that higher-level services (such as those in the `SpaServices` package) should use, register it with ASP.NET Core's DI system: If you implement a custom hosting model (by implementing `INodeServices`), then you can get instances of that just by using your type's constructor. Or if you want to designate it as the default hosting model that higher-level services (such as those in the `SpaServices` package) should use, register it with ASP.NET Core's DI system:
@@ -372,4 +374,4 @@ services.AddSingleton(typeof(INodeServices), serviceProvider =>
{ {
return new YourCustomHostingModel(); return new YourCustomHostingModel();
}); });
``` ```