Comments (13)
Is it a prototype or you already use it in production?
It will soon be ready for production, after the following features are completed:
- Automatic sweeping of expired sessions
- Sign messages before encryption (https://docs.microsoft.com/en-us/dotnet/standard/security/cryptographic-signatures)
- Serialize parameter data in a separate step instead of serializing only entire WireMessage objects
- Collection of performance statistics
There are also some more unit tests needed to ensure good quality.
I'm working on a .NET Remoting based projecs for many years which has more than 1.1 millon lines of code, why it is almost impossible to rewrite using WebAPI or gRPC, so I created CoreRemoting to have a migration path to .NET 5.
Any chances you could sketch up a new transport layer for Zyan based on CoreRemoting?
Yes. I would like to do the following:
- Create a branch of Zyan code base
- Set build target to .NET Standard 2.0 (so it will work for .NET Framework 4.7x+ and .NET Core / .NET 5)
- Replace classic .NET Remoting calls with CoreRemoting calls
- Remove ProtocolSetup implementations that are based on .NET Remoting
- Create new WebSocket ProtocolSetup based on CoreRemoting
- Use existing CoreRemoting functionality where possible to prevent double implementations (e.G. remote delegate support)
I'll try to make as few compatibility breaks as possible.
.NET Standard 2.0 will make migrations to the new branch more soft, because users of Zyan can migrate while still compile against .NET Framework 4.7x+.
I remember in the past you once made a working proof-of-concept WCF-based transport for Zyan.
WCF is also deprecated, so this is a dead end.
Websocket-sharp based CoreRemoting is a good replacement for the TcpDuplexChannel, because it also supports duplex communication over one single connection (makes callbacks/push through firewalls possible). I've tried several Websocket libraries and choosed Websocket-sharp at the end, because it gave the most reliable results. My first approach for CoreRemoting was gRPC. It worked quite nice too, but I ran into issues, when I tried to use it with Blazor clients, because gRPC relies on native C++ DLLs (there is managed code only new variant of gRPC, but this one doesn't run on .NET Framework 4.x).
TLS / SSL is difficult when it comes to Linux, so I decided to implement message based encryption similar to Zyan TcpDuplexChanel.
When it comes to serialization I ended in using classic BinaryFormatter (with applying your extensions to make it more safe :) and DataContractSerializer (which was used in WCF as default). The latter was required to support Blazor clients, because Microsoft blocks BinaryFormatter usage in Blazor. I've tried almost other serialization libraies (Protobuf, MessagePack, JSON.NET, ...) I could find on nuget, but they all have some restrictions that they are not usable for a .NET Remoting replacement library.
To leave to door to other transport and serialization technologies open, I've made them pluggable in CoreRemoting.
from zyan.
Precise estimates are difficult
Before I start to migrate Zyan from classic .NET Remoting to CoreRemoting, development of CoreRemoting must be completed. There are only few tasks left. You can track the progress on the Project Kanban board.
When that tasks are done, CoreRemoting is feature complete.
Then I'll start to migrate Zyan. I start with it as soon as possible, because everyone using .NET Remoting or Zyan is already searching for a replacement. If it take to long, most users will have found other solutions.
from zyan.
It will soon be ready for production, after the following features are completed
Sounds exciting! :)
You're going to build message integrity right into the transport protocol?
I'm working on a .NET Remoting based projecs for many years which has more than 1.1 millon lines of code
Did you ever use Zyan in your company's projects?
I'll try to make as few compatibility breaks as possible.
Perhaps we could get rid of too many constructor overloads in Zyan classes :)
I believe they were written before C# supported default parameter values.
I kept them to ensure 100% backwards compatibility, but now it's going to be a major breaking change anyway.
WCF is also deprecated, so this is a dead end.
Sure, WCF is a dead end.
I mentioned it because I believe that fork had some different approach to plugging transport channels.
But I don't remember much details about it.
To leave to door to other transport and serialization technologies open,
I've made them pluggable in CoreRemoting.
That's great! It would be awesome to make them pluggable in Zyan itself.
If we don't serialize anything really weird like delegates, it should be possible.
from zyan.
First migration steps towards .NET 5 are done.
Basic Zyan RPC features are now running on .NET 5 with CoreRemoting under the hood.
Many things like events, delegates, InterLinq are not working yet.
This is the commit: 0aca4ad
You can find the CoreRemoting migration version at the following branch: https://github.com/zyanfx/Zyan/tree/with_coreremoting
from zyan.
I recently created a library to migrate large classic .NET Remoting projects to .NET 5 based on websocket-sharp, named CoreRemoting.
Some parts of the code may be also useful for Zyan to create a transport layer that runs well on .NET 5.
from zyan.
Hello Hagen, great to hear from you again! :)
The project looks very interesting!
Is it a prototype or you already use it in production?
Some parts of the code may be also useful for Zyan to create a transport layer that runs well on .NET 5.
I've always felt annoyed that such a good library is doomed because of the deprecation of Remoting.
Zyan is used in many projects and still gets quite a lot of bugfixes based on a real world use cases.
Your new library provides a great opportunity to spin off a future-proof fork of Zyan.
Any chances you could sketch up a new transport layer for Zyan based on CoreRemoting?
I remember in the past you once made a working proof-of-concept WCF-based transport for Zyan.
from zyan.
You're going to build message integrity right into the transport protocol?
I have to add only a Signature property to the WireMessage class.
OK, someone may say, that message integrity is a separate concern and should be implemented separately. But I want to keep the code as easy and lean as possible. SoC is important, but keep the complexity low is important too.
Did you ever use Zyan in your company's projects?
Unfortunately not
The main project is a large ERP application. It's development was started in the early 90s. So it's difficult to migrate the infrastructure to a new framework. There was never budget for that.
We currently use classic .NET Remoting. Since last year we're switched from standard TcpChannel to GenuineChannels (gtcp). This one is a masterpiece. But it is still .NET Remoting which is deprecated.
So CoreRemoting will open a migration path even for that old grown large application to .NET 5 (I believe, that .NET 6 will be out, before the migration really begins).
Perhaps we could get rid of too many constructor overloads in Zyan classes :)
Of course, the Zyan source code should be polished.
Currently I develop almost everything on Linux and using JetBrains RiderIDE. It has excellent code inspection and makes refactoring much more easy compared the Visual Studio (only my subjective opinion).
If we don't serialize anything really weird like delegates, it should be possible.
No, only parameters to call delegates are serialized.
The problems I had with most serializers are to serialize DataSets / DataTables. And not only current snapshots of them, but rather complete DiffGrams (to bring RowStates and original values over the wire).
from zyan.
Unfortunately not
😭 .
The main project is a large ERP application. It's development was started in the early 90s. So it's difficult to migrate the infrastructure to a new framework. There was never budget for that.
Sounds familiar...
Although we started many new projects with Zyan, we never migrated our legacy Remoting apps to Zyan.
from zyan.
Hey Guys!
Any estimates and projections of when and if this is going to happen?
from zyan.
That's great!
InterLinq probably just needs a new adaptor/query executor for the CoreRemoting.
I think that events and delegates will be the most tricky part...
As far as I remember, the current implementation relies on a special treatment for MarshalByRefObjects.
from zyan.
CoreRemoting currently does support delegates and events, but not MarshalByRefObj. So I have implement this first in CoreRemoting.
MarshalByRefObj behavior is tricky to achieve on .NET Core / .NET 5, because there is no RealProxy implementation. So I'll using Castle.DynamicProxy. This one is great, but it can only proxy interfaces without limitations. When proxy a class, only virtual members could be intercepted.
Interface proxies should be enough to get Zyan event and delegate support running, but not enough to easily migrate classic .NET Remoting applications to CoreRemoting. Generating a wrapper with IL on runtime could be possible fallback solution.
My next steps will be:
- Adding basic support for interface covered MarshalByRefObjects in CoreRemoting
- Fix delegate and event support in Zyan
- Fix InterLinq support in Zyan
- Fix other Zyan features like call interception
from zyan.
CoreRemoting currently does support delegates and events, but not MarshalByRefObj. So I have implement this first in CoreRemoting.
Do we really need MarshalByRefObj
support?
It looks to me as an implementation details in Zyan, not a feature.
One of key points of Zyan is to avoid using MarshalByRefObjs and other .NET Remoting APIs.
This one is great, but it can only proxy interfaces without limitations. When proxy a class, only virtual members could be intercepted.
Zyan only supports proxies for interfaces, does it?
from zyan.
But Zyan is using MarshalByRefObjects internally to provider delegate and event support.
So I have two options to get Zyan delegate and event support running on .NET 5:
- Implement interface baked MarshalByRefObj on CoreRemoting (Zyan delegate / event logic then should work without many changes)
- Rework the Zyan delegate and event support, so that it does no longer user MashalByRefObj internally (It can use delegates instead)
from zyan.
Related Issues (20)
- RemoveClientServerWires freeze HOT 1
- Single event handler invocation queue per session HOT 1
- Annotate worker threads HOT 1
- Improve ReconnectRemoteEvents logic
- Event storage high watermark HOT 1
- [Question] Dotnet Core HOT 2
- Improve decompression memory management HOT 2
- Use SDK-style csproj for .NET 4.0 and above
- Unhandled exception in duplex TCP channel
- Race condition in ZyanDispatcher related to SessionManager
- Memory mapped files, MessagePack and heap memory allocation questions HOT 8
- Connection lock issue in duplex TCP channel
- ZyanConnection: remoting channel registration race
- TcpEx: another locking issue
- InterLINQ query execution
- User determination in BasicWindowsAuthProvider HOT 3
- Custom serialization have to be configured for List<> too HOT 3
- Error returning List<T> or T[]
- Are Async Methods supported
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zyan.