Flatbuffers too new for C# gRPC?

I think I may be stymied by the current version of Flatbuffers.   I find it slightly odd that it doesn't support arrays in structs (though I've seen proposals to fix this).   Also you can't set it to mark particular interfaces as private or internal so you can force encapsulation.  However, I get by all this.

My biggest problem is that the gRPC template generator for Flatbuffers doesn't work with C#.   It works with Java and I could probably generate those and then port them over, but I haven't got that kind of interest in messing with it.

Flatbuffers seems like a huge win in performance over everything else (except maybe Capn'Proto -- I'll have to see how it integrates with gRPC).  However, I might switch over to protocol buffers for a while, at least to prototype with.  I might also think about attaching the serialization layer to the rest of the system via a batch of interfaces which might make the serialization layer pluggable.

Next Steps After Emissary Builder - Microservice Stubs

So, have been proceeding with next steps after the Emissary Builder is prototyped.   I've decided that the server/browser communication will proceed with C# .NET Core MicroServices running GRPC utilizing the Flatbuffers serialization layer.  I've been working on figure out how to do this and how to build using these parts.   I'm assuming that the microservices will be ASP.NET Core, but I'm not entirely sure yet. 

So now, I'm starting to break down the functionality so I can start to get a handle on the MicroService boundaries, and how to create the authentication and eventually build all of the Flatbuffers contracts and RPC calls. 

I will need to start working on the emissaries themselves.  I'm thinking of doing that in TypeScript or possibly in Rust or Go in Webassembly (really, WASI).   I really am not sure about the state of C# webassembly, blazor notwithstanding.

I have to restructure my 3DOM library, which is where all my current active code is.  It needs to be strategically split into pieces, but I'm not sure where the edges are yet.  I'm trying to avoid monoliths.

Here's my brainstorm of the various services I know offhand I might need.  I'm sure there are many more, however, these are the main published services.   Each World, Avatar, and Entity can create its own layer of custom gRPC calls to handle the provisioning and operation of each emissary and they must remain dynamic.

I think--Stage 1 Hello World--will consist of all 4 servers working with their Ping servers.   Though that's not really how the use-case goes. 

Ultimately the completed startup is more like this:

• Browser asks Avatar server where Avatar's Kudo Server is
• Browser logs into Avatar and Aspect
• Avatar's Emissary is Marshaled
• Browser connects to world that Avatar wants to materialize in
• Browser asks world's Kudo server to grant permission (based on Visa or open permission)
• World's Emissary is Marshaled
• World then emits the inventory for the scene
• Entities from everywhere begin to Marshal their Emissaries
• World causes the Avatar to materialize in the designated position in the Scene

But, we have to get there incrementally.  Server skeletons first, then ping.   Enough of a microservice that we can get this running in a Kubernetes Cluster, or at least in Docker on one machine. 

Boy, that was ramble...

Tentative Services

Kudo Server

• Ping
• Locate Worlds
• Locate Avatar Service
• Locate Entity Service
• Vouch Self
• Vouch Service
• Vouch CA
• Validate Login Ticket
• Sign [Developer]
• Login from Server [Server]
• Login from Avatar [Avatar]
• Banking Transactions

Kudos:

• Vouch for Kudo
• Generate Kudo
• Transfer Kudo
• Revoke Kudo
• Manipulate Values in Kudo

Standard Kudos:

• Deed
• Lease
• Visa
• Access Grant
• Ban
• World Level
• World Coin

Avatar Server

• Ping
• Locate Kudo Route
• Vouch Self
• Marshal Avatar (As Primary Avatar)
• Marshal Entity (Avatar as Entity)
• Transform Aspect
• Manage Active Inventory
• Transfer Entities Into/From

World Server

• Ping
• Locate Kudo Route
• Vouch Self
• Log Avatar In
• Marshal World
• Unveil Scene Inventory/State
• Marshal Entity (World as Entity)
• Transfer Entities Into/From

Entity Server

• Ping
• Locate Kudo Route
• Vouch Self
• Marshal Entity
• Transfer Entity
• Transfer Entities Into/From
• Instantiate Entity Into

Emissary Builder Prototype Done

I've got the basic emissary builder done in c# in the 3DOM library.

So now, there are a ton of things to do. 

• Start the browser
• Need skeletons and initial functionality for all server types
• Kudo
• Avatar
• Entity
• World

I need to figure out what rules are for putting Unity projects into github.    I know you're not supposed to post Unity code so I've basically got to do it with my own code or with pieces that I download from github, not from unity.  I probably need a really good .gitignore file.

So, the next thing will be to get enough pieces together so that I login to a world, and start loading up the world and then I can marshal all of the emissaries as they come down.   I have envisioned the hello world state for the browser that materialized an invisible avatar in the middle of a scene with a couple of cubes on a plane with all of the particating servers supplying data.

Onward and upward...

Client/Server Protocols

I've been thinking for a while about how server/client communication will need to occur in several different directions.

This front-facing use-cases are the APIs to the various servers (Kudo, World, Entity, Avatar), and have thought that these need to be rather high-performance.   I've been looking to newer alternatives to json and xml and all of the old paradigms for web-api serialization, so I've been looking at things like Protocol Buffers, Cap'n Proto, and FlatBuffers.   The first and third are Google supported.  I'm also interested in the meta level of having an RPC layer like gRpc, and this supposedly can use ProtoBuffs and FlatBuffers.  Cap'n Proto also has an RPC functionality (though not that I can see for c#).

Many of the API calling code will be built into the browser and so interfaces would be totally static (though versioned probably).

The other big client-server interaction is between servers and the Emissaries...   Much of the design of this architecture is inspired by the DDP model in the Meteor Framework.   However, I think the kind of information that gets synchronized between the server and the Emissary is a little different.   Simply doing a two way reactive subscription to a chunk of a Mongo collection isn't the best model for the Emissary.   Reactivity: yes, Synchronization: yes, but the data is more specialized. 

And, for the Emissary, most of these protocols have a schema language and generates classes that you use in the tool-chain to build the emissary.  These can't be compiled into the browser, and so have to run in the Emissary code with probably some high level communication -- perhaps passing the websocket handle down to the code.   So, likely there will be some specific hooks in the APIs for this code.

I'm still looking for a sync model I like, though due to the nature of the way the Emissary is setup, you really can roll your own if you like as long as the API is giving you enough rope for you to pull on.  And this is obviously one of those points where security is vital.  I think the idea was that the browser would set up the secured channel, and then the emissary can do what it needs.

I'm getting to the point where I need Hello-World functionality from all of the basic servers, so I need to get the infrastructure ready to go.   I need some very basic functionality from them as well.  I need World to get me an inventory, then I need to marshal all those entities from an entity server.  I can skip some of the security stuff in the Kudo server, but I'd like the Cert Chain for the Emissaries to be checked (right now, it will simply accept the cert I give it -- it has to be signed, but it makes no checks to verify who signer is and that the cert chain goes back to the Manufacturer Guid (and that the signer is authorized to sign for it)).

I'm also thinking I may need a "Server Common" project.   Simple "Common" might include stuff that the browser doesn't really need.

On Emissaries and Meshes (Idea for Mesh Cache)

So, the original idea for the _payload directory in the Emissary was to allow the initial state of meshes and whatever other assets might be needed for the Entity to operation.  Problem with that is, after the mesh moves from its initial state, that part of the Emissary file now becomes unusable dross, weighing down the file and requiring it to be transferred each time it is cached. 

I'm thinking instead, that what is needed is a separate cache database (probably in sqlite) which contains the various meshes in whichever states are needed, and to have a separate way to download them to the browser.   Basically, you'd have an Entity Id, the Mesh Id, and probably a state id (which might be simply a incrementing integer, or some other form of version).  We need a fast and efficient serialization/deserialization format for meshes.   Maybe there's a standard out there.

_payload is likely still useful for other fixed assets, like audio files or jpeg images.