summaryrefslogtreecommitdiff
path: root/src/lib/irmd_messages.proto
diff options
context:
space:
mode:
authordimitri staessens <[email protected]>2016-04-19 19:22:03 +0200
committerdimitri staessens <[email protected]>2016-04-19 21:46:15 +0200
commit38c416988fe7956f377f064e98423d8f0f30eaea (patch)
tree3904929184262d594f7045b57f9a1149b6bb995b /src/lib/irmd_messages.proto
parent468729f048f1cdafa7a83ba388bfe2e26588d776 (diff)
downloadouroboros-38c416988fe7956f377f064e98423d8f0f30eaea.tar.gz
ouroboros-38c416988fe7956f377f064e98423d8f0f30eaea.zip
shim-udp: flow allocation added
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.
Diffstat (limited to 'src/lib/irmd_messages.proto')
-rw-r--r--src/lib/irmd_messages.proto3
1 files changed, 2 insertions, 1 deletions
diff --git a/src/lib/irmd_messages.proto b/src/lib/irmd_messages.proto
index 92ea439e..d484a007 100644
--- a/src/lib/irmd_messages.proto
+++ b/src/lib/irmd_messages.proto
@@ -31,11 +31,12 @@ message irm_msg {
optional uint32 ipcp_type = 5;
repeated string dif_name = 6;
optional int32 fd = 7;
- optional int32 result = 8;
+ optional int32 response = 8;
optional int32 oflags = 9;
optional string dst_ap_name = 10;
optional uint32 port_id = 11;
optional uint32 reg_ap_id = 12;
optional int32 pid = 13;
optional dif_config_msg conf = 14;
+ optional int32 result = 15;
};