TheFramework

Outline

• Multi-user realtime 3d graphics editor.
• Microservice inspired architecture. But use IPC/shared memory when possible.
• Need a local daemon as a gateway/introducer for the services.

• Hash all the things.
• Hierarchy of caches.

Flow

• Look for local gateway service. (IPC/PidFile).
• If found connect to that local gateway service.
• Otherwise spawn local gateway service (Would make sense for this to be a separate binary).

RPC

Big Picture

• Request specific object types 'get_vertices(vid)' or just 'get(id)'?
• Non-specific seems better. Can just use a global async que for all returned things.

Message Format

• Maybe just use Rust structs? Can redefine them separately later...
• Could use codegen... Can go from Rust structs to external format or visa-versa.
• Could keep them in Rust native and provide a C library interface to interact with them.

Capnproto?

• A bit of a pain to integrate into Rust.
• Plays well with other languages.
• Need to find out how to extent the codegenerated types with my own.
• Would need to use capnproto's internal native formats instead of Rusts.
• Good versioning...

JSON?

• I don't like JSON.
• It's fairly well known and supported.

Enums vs "strings"?

• Strings much more waste on the wire. Higher parsing overhead.
• Strings allow for custom types. Could just add a custom type enum that has a string.
• Enums could be 'backwards compatible' if you just ignore anything you don't understand.
• Strings wouldn't have to be predefined. But they would have to be used so defining them would be best anyway.

Categorise messages by type, or one global type for all messages?

• Categories could make it easier to ignore messages that have nothing to do with the service.
• One global type would be much easier to implement.
• Categories might be eaiser for reading documentation. But might be harder too as they might end up spread around.
• Maybe one global type with 'soft categories', ie categorise them based on the name but have one giant enum.

Message Flow

• CL=client
• GS=Gateway Server
• AS=Auth Server

• >>> CLIENT > GATEWAY Request Login: Username XXX, Password XXX, Magic=<RANDOM_BITS> SRC=CC_IP (should client send SRC IP?, it could waste space, but then again they ).
• CLIENT must add the Magic to some local list of magic's to ensure someone else doesn't send a fake response.
• GATEWAY Must ensure SRC is correct (or set it, of course UDP ip sources themselves can be spoofed. Does this need a handshake? Should AUTH or ).
• GATEWAY must forward the request to AS.
• >>> GATEWAY > AS Request Login: Username XXX, Password XXX, SRC=CC_IP.
• AS checks database or something...
• >>> AS > CLIENT Login OK, Magic Token (or signed thing). SRC=CC_IP

• Ensure AUTH can't be DOSed by spoofed IPs.
• Could require a PROOF_OF_IP_CONTROL handshake before doing the username auth stage. Should this be done by the AUTH or from the GATEWAY?
• How do you prevent the PROOF_OF_IP_CONTROL itself from being a DOS attack?

ASync

Look into using tokio for async. getting_started_with_tokio

Daemonization

2 libraries. 2 don't do Windows.

• knsd/daemonize - Docs - No Windows afaik. Recent updates (Oct 15th 2016).
• bozaro/daemon-rs - Docs - Example - Last update a year ago.
• swizard0/unix-daemonize - crates.io - A Year Ago.

• Daemons as plugins? Possible to update daemon's at runtime?
• Separate services provided from 'daemon'. One daemon can support multiple services in a single process. Could act as a proxy/gateway.
• mnds? - For networked services...

Services

• A service to list the services.
• A login service.
• A key/value look up service (needs some kind of security to ensure you can lookup that key).
• A name/value lookup service.
  • Security again.
  • Different people might get different results... Ie... list_of_projects_I_can_edit.
  • Maybe list_of_projects_that_<USERID>_can_edit and use security to limit it to <USERID> (or admins). Could also work with GROUPS. Although If I'm in a group the first one would need to return the results of the 2nd for all the groups I'm in too.
  • Should this return the actual data? Or should it return a hash
    • Any response should probably also send the data (Pipe lining).
    • Or automatically forward the request onto the key/value service and have it sent as a separate response?
    • What about dynamic/lazy evaluation? Don't want to keep all possible values around. Don't want to dump temporary crap in the hash store.
    • Give the client a 'ticket', if the response isn't returned in time, handle that. The ticket can be used with dynamic data returned.
• A service to get a list of projects.
• Runtime, inmemory stuff. For example, "Move <OBJECT_ID> to position <POSITION>". "<AVATAR_ID> is at <POSITION>.". Once again needs security. Other users shouldn't be able to view/modify things they don't have access too such as other users locations. Projects they don't have permissions to view/edit, etc...
• Pub/sub? How can I know when the project I'm working on is modified by another user. What about getting information about only the things I am near? Just have a name that points to a root hash with the project properties that gets updated continuously? Automatically pipeline the update to other users. Dynamic vs stored data?
• Lock/unlock service. For editing.

• Maybe it's just a REQUEST/RESPONSE service. And some of those requests are for KEYS/VALUES. Others are for LOGIN(USERNAME, PASSWORD), etc... Dispatch to the appropriate internal service. Maybe it's really just a request service since the responses will be other services.
• What about p2p?

IPC

• servo/ipc-channel Doesn't do Windows yet. "Servers only accept one client at a time". Would it be possible to pass a channel from one process to another?
• alexcrichton/ipc-rs - Docs - "Warning: This crate is only compatible with libnative currently. Crates taking advantage of libgreen will not be able to use this crate. To work around this, a helper thread may be necessary.". Produces a named semaphore.
• meh/rust-shmem - Examples - Shared memory... Similar to above.

Security

• Client needs some way to know responses coming from other services are from the same central authority.
• Client's should reject requests that don't originate from the central authority (but can come from different IP addresses).
• Client's can't view things they don't have permission to see.
• Client's can't modify things they don't have permission to modify.
• Could use/require digital signatures.
  • Players in a p2p game could be proven to have cheated if other players/the_server disagrees with their messages.
  • Potential timing attack, player could withhold messages from opponent, then send after the fact... Make server check time/ordering?
  • Would their be any possibility of the client suppressing sending messages it doesn't like? Probably not since this would just be like not moving and if it only send it to another player then they could forward it onto the server.
  • Could digital signatures be used for security?
• Some kind of access control lists? For data? For RPC functions? Some kind of dynamic ACLs?
  • I'm <CLIENT_ID: NORMAL_USER>, I need to BE_ALLOWED to see my list of my projects.
  • I'm <CLIENT_ID: HAXOR>, I need to BE_DENIED a list of <CLIENT_ID: NORMAL_USER> projects.
  • I'm <CLIENT_ID: SERVER_ADMIN>, I need to BE_ALLOWED to see a list of <CLIENT_ID: NORMAL_USER>'s projects. Or all projects. I have physical access so I can basically do what I want (unless encryption is used)...
  • I'm <CLIENT_ID: GROUP_ADMIN>, I need to BE_ALLOWED to see a list of <GROUP_ID>'s projects.
  • I'm <CLIENT_ID: GROUP_ADMIN>, I need to BE_DENIED list of <CLIENT_ID: NORMAL_USER>'s projects, even though they are in my group.
  • I'm <CLIENT_ID: GROUP_ADMIN>, I need to BE_ALLOWED to see a list of the group projects <CLIENT_ID: NORMAL_USER> is in.