Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 6 years ago

Last modified 6 years ago

#392 new enhancement

Async per-port connection handlers

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone:
Component: helenos/unspecified Version: mainline
Keywords: Cc:
Blocker for: Depends on: #393
See also:

Description

Currently a server can set a single handler for all incoming connections using async_set_client_connection(). This makes it problematic to accommodate differt types of connections in a single server.

We have libraries/frameworks/APIs (e.g. libdrv, loc API) that register with a naming service and want to accept connections made via that naming service. We cannot have a server that would be a DDF driver and loc service provider, for example, because of this (each API wants to usurp the connection handler).

Currently a service is basically identified using a task ID. If we extend this identification with a port number and make services be identified with task ID:port number, we can easily compose multiple servers in a single task.

Port numbers would be assigned dynamically by the async framework and would be transparent to the user code. Port numbers would be transmitted as the first argument of a connect call.

Proposed changes:

  • add function to allocate async port
  • add function to register connection handler for a port (as an alternative to a catch-all connection handler)
  • where desired, change the naming registration functions so that port where the service resides can be specified

Change History (1)

comment:1 Changed 6 years ago by Jiri Svoboda

Depends on: #393

Without single connection per session (#393) the client stub needs to be aware of the transformation a naming service performs on the arguments when forwarding a connection request (currently just shifting them) in order to be able to create additional connections for a session (arguments passed to async_sess_args_set()).

After this change the naming service also fills in port number, thus the client would need to be aware of the port number as well. This is rather cumbersome. It can be solved by fixing #393 first.

Note: See TracTickets for help on using tickets.