summaryrefslogtreecommitdiff
path: root/src/ipcpd/normal/fmgr.c
Commit message (Collapse)AuthorAgeFilesLines
* lib: Demultiplex the fast pathdimitri staessens2016-10-211-65/+78
| | | | | | | | The fast path will now use an incoming ring buffer per flow per process. This necessitated the development of a new method for the asynchronous io call, which is now based on an event queue system for scalability (fqueue). The ipcpd's and tools have been updated to this API.
* ipcpd: normal: Improve upon the internal designSander Vrijders2016-10-121-235/+356
| | | | | | | | This commit will remove the RMT component from the normal IPCP, as some of its functionality would else be duplicated in the FMGR. Now all reading from flows, either N-1 or N+1 is done in the FMGR, then either passed to the FRCT or a lookup is performed in the PFF (not there yet) and the PDU is forwarded.
* ipcpd: normal: First version of the fast path bootstrapSander Vrijders2016-10-111-53/+150
| | | | | | | This is the first version of the fast path bootstrap in the normal IPCP. It sets up a connection with the other end, and creates the appropriate data structures. N+1 and N-1 SDUs are read and written and passed through the right components.
* lib, ipcp: Revise fast path and flow interfacesdimitri staessens2016-10-041-128/+74
| | | | | | | | | | | | IPCPs can now use ap_init() to initialize the memory. All flows are accessed using flow descriptors, this greatly simplifies IPCP development. Reverts the fast path to a single ap_rbuff per process. Splits lib/ipcp into irmd/ipcp and lib/ipcp-dev. Adds a lib/shim-dev holding tailored functions for shims. Moves the buffer_t to utils.h. Fixes the shim-eth-llc length field. Removes the flow from shared.h. Fixes #4 Fixes #5
* Merged in dstaesse/ouroboros/be-split-fp (pull request #238)Sander Vrijders2016-09-021-2/+2
|\ | | | | | | lib: Add northbound ringbuffers
| * lib: Add northbound ringbuffersdimitri staessens2016-09-021-2/+2
| | | | | | | | Fast path is split in north and southbound paths.
* | lib: ipcp: Decouple flow_deallocdimitri staessens2016-09-021-1/+1
|/ | | | Sending a dealloc to the irmd moved to its own call.
* ipcpd, normal: Safe handling of CDAP requestsdimitri staessens2016-08-251-2/+4
| | | | Destruction of the object in the reply stage was unsafe.
* ipcpd: normal: Fix uninitialized valueSander Vrijders2016-08-251-6/+9
| | | | This removes the ret value which was not being set correctly.
* Merged in dstaesse/ouroboros/be-ipcp-locks (pull request #221)Sander Vrijders2016-08-241-9/+8
|\ | | | | | | ipcpd: Revised locking
| * ipcpd: Revised lockingdimitri staessens2016-08-241-9/+8
| | | | | | | | | | | | 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.
* | ipcpd: normal: Add initial steps for N+1 flow allocationSander Vrijders2016-08-231-15/+358
|/ | | | | | | | | | | This adds the initial framework for flow allocation between two N+1 endpoints. The FMGR will receive flow allocation requests and will create a connection as a result, addressed to the right address, it will also pass a flow allocation message to this address. Upon receipt on the other side, the FMGR will be receive a flow allocation message and a pointer to a new connection. The FMGR can then accept or destroy the connection. This commit also introduces the RMT function, which is needed by the FRCT to forward its SDUs on the right file descriptor.
* irmd, lib: Rebuild the IRMd data modeldimitri staessens2016-08-211-9/+0
| | | | | | | | | | | | | | | | | | | | | | 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.
* ipcpd: Fix bootstrap with api_binddimitri staessens2016-08-121-0/+9
| | | | | Calling api_bind during bootstrap caused the IRMd to lock up. api_bind is now called after the normal completes bootstrapping.
* ipcpd: Add condition variable to IPCP stateSander Vrijders2016-08-111-18/+12
| | | | | | | 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.
* ipcpd: normal: Allow exchange of static DIF informationSander Vrijders2016-08-081-2/+2
| | | | | | 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.
* ipcpd: normal: Allow initiating enrollmentSander Vrijders2016-08-011-16/+26
| | | | | | | 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.
* ipcpd: normal: Provide initial steps for enrollmentSander Vrijders2016-07-271-23/+29
| | | | | | 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.
* ipcpd: normal: Establish N-1 management flowsSander Vrijders2016-07-141-0/+242
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.