summaryrefslogtreecommitdiff
path: root/src/lib/irmd_messages.proto
Commit message (Collapse)AuthorAgeFilesLines
* shim-udp: flow allocation addeddimitri staessens2016-04-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the API for flow allocation. The shims currently does the following. The shim IPCP binds to an interface (IP address) and listens for flow allocation requests on UDP port 0x0D1F (3359), referenced as the listen port (lp). It will treat any datagram received on lp as a flow allocation request. Upon receiving an allocation request IRM_MSG_CODE__IPCP_FLOW_ALLOC from the IRMd, the shim IPCP will bind a UDP socket to a port (cp) allocated by the host OS. From that port it will send a UDP packet containing the destination ap_name to server_host:lp and wait for a response. Upon reception of a packet on server_host:lp, the shim_IPCP creates a UDP socket for the flow with a port set by the host os (sp), binds to it and echoes the received datagram back from server_host:sp to client_host:cp. It will also notify the IRMd of an incoming flow allocation request IRM_MSG_CODE__IPCP_FLOW_REQ_ARR, with as src_ap_name ("John Day"). It will get the port_id as a return value of that message and create a flow with status FLOW_PENDING with that port_id. If the server responds negatively to the flow allocation request (i.e. the shim IPCP on the server side receives a IRM_MSG_CODE__IPCP_FLOW_ALLOC_RESPONSE with a response != 0, it will delete the pending flow. If response == 0, it will set the status to FLOW_ALLOCATED. On the client machine the IPCP will learn sp upon reception of the echoed datagram. It will then create a flow with the port_id it received with the message from the IRMd and set it to ALLOCATED. Pending implementation: DNS support, this PR only supports local flows on the loopback adapter 127.0.0.1. A thread to listen for the echoed message, to avoid the entire IPCP to block when the echoed message is lost. This PR compiles but is untested pending necessary implementations elsewhere in the stack.
* ipcpd: initial IPC processesdimitri staessens2016-04-181-13/+14
| | | | | | | | | | | Basic functions for implementation of IPC processes, and implementation of core functions of the shim IPCP over UDP. Updates to the build system to compile these IPC processes, as well as some fixes in the irmd (rudimentary capturing exit signals) and some fixes in the library, mainly relating to the messaging. Basic implementation of creation / bootstrapping / deletion of the shim UDP. Placeholders for other functions.
* lib, irmd, irm: Add dif_configSander Vrijders2016-04-081-10/+11
| | | | | | | | | This adds dif_config to the prototype, in which one is able to specify the parameters a DIF should have. The bootstrap operation of an IPCP takes this as parameter and is oblivious to whether it is a shim or a normal IPCP. The dif_config struct is also correctly serialized and deserialized and passed opaquely to the correct IPCP. This IPCP is in charge of deserializing it correctly.
* lib: Implementation of flow related opsSander Vrijders2016-03-311-1/+6
| | | | | | This adds the messages that are sent to the IPCPs related to flows. Some messages are also sent to the IRMd (e.g. when a new flow arrives).
* lib, irmd: Update communication with IRMdSander Vrijders2016-03-301-13/+10
| | | | | All messages sent to the IRMd now also get a reply back with the result of the operation.
* build: Add protobuf-c commands for cmakeSander Vrijders2016-03-251-0/+37
This adds a cmake file so that the build can ask to generate protobuf-c files from .proto files. The messages between the IRM and the library are compiled into the library.