Comments (5)
Muen uses protocol identifiers to determine the channel protocol. As the channels are unidirectional there are two protocols, a request and a response. Furthermore the Linux module uses a distinct protocol identifier for each channel with the test that uses two channels resulting in the following values:
- request:
0x9570208dca77db19
,0x9570208dca77db20
- response:
0x9851be3282fef0dc
,0x9851be3282fef0dd
Running multiple channels with the same protocol identifier on different channels seems to work.
from gneiss.
As there is currently no convention we use the first protocol id for each protocol.
Also since we can only supply one name per session but need two channels the channels will have a prefix and the supplied session name:
rsp:<session name>
for the response channelreq:<session name>
for the request channel
from gneiss.
To allow session based channel detection each channel name will be further prefixed with a session name abbreviation:
blk:rsp:<channel name>
blk:req:<channel name>
from gneiss.
The dispatching approach fits well with #50. Since it wouldn't make sense to implement a worse approach first that is already deprecated due to a planned feature I'll implement #50 first and continue the dispatcher afterwards.
Explanation:
The dispatcher on Muen is called in each scheduling cycle. But the dispatcher implemented by the component should only be called once the connection state has changed.
The connection state on Muen is detected by the Is_Active
state of both the request and the response channel.
As the client activates the request channel (and probably already sends a request) in its initialization but the response channel has not yet been activated an incoming "connection request" can be detected. If the Server decides to accept this request the response channel will be activated. The same applies to the connection teardown. When the client finalizes it will deactivate the request channel. If the response channel is still active the dispatcher can finalize the server. So state detection can be summarized in the following table:
Request Active | Request Inactive | |
---|---|---|
Response Active | Connection established | Client disconnected |
Response Inactive | Client requested connection | Disconnected |
On both Genode and Muen the dispatcher generates the information for the Session_Request
procedure in the context of its dispatching call. That means that the information is only valid when Dispatch
is called. On Genode this information is stored on the stack and retrieved from it from inside another function. This will most probably generate segmentation faults when those procedures are called from another context. On Muen the Information would be stored in the component global session registry. To retrieve the correct information at least the session registry index needs to be passed to the internal dispatch call. In both cases it would be safer and simpler to use a opaque object that can be used to pass this information while further enforcing the call context.
from gneiss.
The current block channel on Muen uses combined meta data and data inside the channel. While this reduces the implementation complexity it prevents the usage of larger requests or block sizes other than 4096. It also forces the reading end of each channel to either handle the blocks in order or cache them inside the application. Furthermore it requires at least one copy operation on each block.
An alternative approach would consist of two meta data only channels and a third shared memory region for blocks. The meta data channels would be similar to the current channels used but without block data.
The shared memory region would be used to exchange block data. To prevent race conditions the client is solely responsible for allocating and freeing blocks from this region. The client stores the region to be used by the server inside the request sent over the meta data channel. Tracking the allocation and deallocation of blocks in the shared memory region is up to the client and transparent to the server. The server will determine memory to be used for each request solely by the meta data.
A meta data event could have the following elements:
- None, Read, Write, Sync, Size, Count
- None: empty, invalid event, all other fields must be 0
- Read: read request
- Write: write request
- Sync: sync request
- Size: requesting block size from server
- Count: requesting number of blocks from server
- Block Id/Size data/Count data
- Number of blocks
- Shared memory offset
- 16 byte private client data
The None request is an explicitly empty request that indicates an unused field in the shared memory channel. In case of a Read, Write and Sync request the next fields indicate the starting block number and the number of consecutive blocks that should be handled. In case of Read and Write the shared memory offset indicates the position inside the shared memory that should be used to read/write the data. The client needs to allocate enough consecutive memory for the complete request to fit. There are further 16 byte that are free to use for the client.
If the event is a Size or Count request the server will use the block id field to store the return values.
from gneiss.
Related Issues (20)
- Timer session on Linux HOT 1
- Consolidation HOT 1
- Prove tests HOT 9
- Prove broker HOT 1
- Fix file descriptor leaks
- Allow proving, editing and compiling as different commands in cement HOT 1
- Prove globals HOT 4
- Custom parameters for generic operations HOT 3
- GPIO Debug HOT 1
- Update ada-runtime, rename init to core/linux HOT 1
- Add support for different platforms to cement HOT 1
- Matrix Demo
- ICMP Demo HOT 4
- Update README HOT 1
- Global platform state for volatile inputs
- Update to CE 2020 HOT 5
- Update to RecordFlux 0.4.0 HOT 1
- Stream interface HOT 1
- Run checkers on cement
- SPI driver
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 gneiss.