Opened 6 weeks ago
#886 new enhancement
Multiface Async Ports
| Reported by: | Jiri Svoboda | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | helenos/unspecified | Version: | mainline |
| Keywords: | Cc: | ||
| Blocker for: | Depends on: | ||
| See also: |
Description
Currently each server task can have 1 or more (static) interfaces (i.e. up to 1 of each interface type, interface types are compiled in).
For each interface we can create one or more ports (instances of that interface) using async_create_port(INTERFACE_xxxx, conn, arg, &portid).
loc_service_connect() does not register a service, but, in fact, the entire server. It is possible, though, to register it multiple times under different names.
We connect using loc_service_connect(svc_id, INTERFACE_xxxx, 0).
There is no way to select the port. That means only one port for each interface is really usable!
If we register the server under two service names A, which is supposed to be of type INTERFACE_foo and B, which is supposed to be of INTERFACE_bar, then a client can look up A and connect to INTERFACE_foo and look up B and connect to INTERFACE_bar as expected (good!). They could also look up A and connect to INTERFACE_bar (not what we want!).
There is no way for one server to serve two different instances of INTERFACE_foo and have clients look them up and connect to them.
This architecture is completely reversed from what I originally intended ports to look like. Here's the proposed solution.
Step 1.
A server task can create one or more ports. Each port can understand one or more interfaces (of different types), i.e. multiface port.
Step 2.
What a server task registers with the location service as a service is a PORT. Thus we can provide multiple services. These can understand the same or different protocols (or multiple protocols).
Possible future step (Multiface sessions)
DDF's dispatcher allows a single session to understand multiple interfaces (interface ID is ARG0, method is in ARG1, etc). If we want to replace DDF's dispatcher with async's, we either need to support the same, or work (would be nice) or work around by changing the clients to create one session for each interface (probably quite easy).
This could be implemented by putting the interface ID in the upper half of ARG0 (in the past a little preparation was done by calling it IMETHOD), but that would require fixing all switch (imethod(…)) statements in all servers.
Architecture diagram of current and future ports/interfaces