| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The state lock was reverted to an rwlock to avoid interference of
management functions with the fast path. IPCPs now close without
calling unsafe functions in the signal handler.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The complete data model inside the IRMd has been restructured. The
bind operation was revised to allow binding of AP and AP instances and
register those names with different DIFs (see "irm bind" for details).
Server applications require to call ap_init with a server name
argument, client application that do not the be reachable over any DIF
can call ap_init(NULL). Calling ap_init for a client with a specified
name will not have adverse consequences for the application, but will
consume unnecessary resources in the IRMd.
Application servers can now be started at any point after the IRMd has
been started. Starting servers, binding AP names and registering names in
DIFs can be performed in any order that does not defy temporal logic.
Supports naming instances by their pid. In case of IPCP Instances
created with the IRM tool, the name assigned during "irm ipcp create"
can be used.
All the changes required updates in the tools.
|
| |
|
|
|
| |
Calling api_bind during bootstrap caused the IRMd to lock up.
api_bind is now called after the normal completes bootstrapping.
|
| |
|
|
|
|
|
| |
This adds a condition variable to the IPCP state, so that upon state
changes any listeners to state changes can be notified. It also
replaces the read/write lock with a mutex in order to be able to do
so.
|
| |
|
|
|
|
| |
This adds the functionality of exchanging the static DIF information
between 2 DIF members. After exchange the enrollment is stopped, and
the IPCP that initiated enrollment transitions to the enrolled state.
|
| |
|
|
|
|
|
| |
This will add more functionality for enrolling two normal IPCPs with
each other. Some bugs were fixed in CDAP. Now on enrolling, an IPCP
will send a START message to the other IPCP. Next step is syncing the
RIBs.
|
| |
|
|
|
|
| |
This provides the normal IPCP with bootstrapping and the initial steps
for enrollment. Next step is actually reacting to an enrollment
request and sending the data transfer constants.
|
|
|
This adds the intial implementation of establishing management N-1
flows between normal IPCPs. On calling fmgr_mgmt_flow, a management
flow will be setup to a certain destination IPCP. After flow
allocation, the fd is handed to the RIB manager. The flow manager also
listens for incoming flow requests. In case they are management flows,
they are handed to the RIB manager, otherwise to the FRCT.
|
