Memory mapped files, MessagePack and heap memory allocation questions

[netcorefan1]

Hello,
I would like to ask if it is possible to use memory mapped files as custom transport protocol and if this is something easy to implement (some sample code would be appreciated).

I also saw that it is possible to use custom serializers and I would like to ask if MessagePack could work out of the box while still preserving the "Unobtrusive" feature which allows to declare plain classes and interfaces without any ServiceContract/OperationContract attributes.

Are there any limitation with a configuration like the above or I can take advantages of all features described in the home page?

I saw another IPC library that provides nearly heap memory allocation free and this is something I would like to take advantage of, but I have not been able to find any info on Zyan on that matter.
Thanks
P.S. I don't care of multiplatform support, I only need to work with Windows (at least for now).

[yallie]

Hi @netcorefan1,

it is possible to use memory mapped files as custom transport protocol
and if this is something easy to implement

I'd say it's possible but probably not feasible to implement.

Zyan is built on top of a legacy technology, .NET Remoting, so it can't be
ported to .NET Core. So I wouldn't recommend using Zyan for the new projects,
although I myself occasionally do.

As far as I remember, Genuine Channels project has a memory mapped file
transport sink which can be used in Zyan, but I believe that native IPC channel
uses memory-mapped files as well.

I also saw that it is possible to use custom serializers

Custom serialization hooks in Zyan are used to provide serialization support
for non-serializable classes such as LINQ expressions or POCO objects, but
on the transport level everything is still wrapped in BinaryFormatter envelopes,
again because of the Remoting.

Zyan can't use MessagePack to encode its communications without BinaryFormatter.

PS. Homepage text is a bit outdated, it's some 8 years old, I'm sorry about that.

[netcorefan1]

Thanks for your response yallie! I was so attracted from all the great features that I missed up the most important thing: support limited to .Net framework and the legacy .Net remoting. This is a big problem!
Do you think it's possible to port the project at least to .Net standard? The new technologies seem to make possible to use MessagePack at transport level.
It's a shame that a such great project is going to dead.

[yallie]

Zyan is so heavily based on Remoting infrastructure that I don't think it's possible to port it.
Decoupling from .NET Remoting is a chance to redesign the APIs, and that means creating another library.

The new technologies seem to make possible to use MessagePack at transport level.

I wish I had found this library when I started JsonServices a few years ago.

[netcorefan1]

Oh, it's really a shame. Your JsonServices project is very nice, I can easily see is made from a talented person!

I spent nearly a full day here on Github trying to find what could the best framework and yours, along with PolyMessage are absolutely the most promising. I am entering into this side of development for the first time and I have no experience at all. Most of time I had to spent was for investigating on the available technologies and only now I had chance to open VS and try and first one has been vs-streamjsonrpc I previously linked. It seemed a bit overkill with too many dependencies, not difficult to use (but not even free from trials and some learning curve), but apart from this there are some things that made me concerned. I am talking with the author of PolyMessage about those and, most of all, about his intention to refactor his project to bring it to a whole new level and this seems very promising.
I would be very glad if you would want to join that thread. Your project dead and the evolution of its project, to me, seems to be the perfect chance happened at the right time for a new cooperation between you and him. PolyMessage and Zyan are the best projects here on Github made from very talented persons. If you both decide to join the efforts I am sure it will born a masterpiece. And most of all the learning and efforts done for a dead project will not be lost because knowledge can be reused to develop something completely new and amazing,

[yallie]

Hi @netcorefan1, thanks for your kind words!

It's all about free time... I haven't got enough time to develop new opensource projects.
BTW, Zyan isn't dead, it's just legacy. It's used in many companies, including the one I work for,
and I have to maintain it. Modern .NET isn't just .NET Core, many companies still use desktop .NET.

Cheers!

[netcorefan1]

Oh yes, free time is something very hard to find when development is involved. I always try to find the best library which saves me time, but most of the time it's more the time spent in searching than the development itself!
If it was for me, I would just stuck with legacy technologies since they works well, but the time where they will force to upgrade, soon or later, will come.
I don't want to further abuse your time and I am going to close the issue. You're very talented and I hope to see soon some new projects in your repo!
Thanks

[yallie]

Thanks @netcorefan1, you're too kind!

[yallie]

Another discussion related to .NET 5: #88