BPRC(5)

📦 version 3.2.1, in ubuntu jammy

💖 BPRC(5) — BP configuration files 💖

okay so bestie, welcome to section 5 of the manual — BP configuration files ✨ this whole page is about <pink>bprc</pink>, the Bundle Protocol management commands file, and ngl it's a chunky one. grab a snack 🍓

🌸 NAME 🌸

bprc — Bundle Protocol management commands file 🫶

✨ DESCRIPTION ✨

So here's the tea ☕ — Bundle Protocol management commands get handed to <cyan>bpadmin</cyan> in one of two ways: either in a file of text lines, or interactively right at bpadmin's command prompt, which is <hotpink>:</hotpink> (yes, literally just a colon, iconic).

Commands are interpreted line by line, and it's exactly one command per line. No stacking, no sneaking two in. The formats and effects of all the Bundle Protocol management commands are described below 👇

👑 GENERAL COMMANDS 👑

  • ? — the help command 💅 It displays a listing of the commands and their formats. It is the same as the h command.
  • # — comment line 🌈 Lines beginning with # are not interpreted. Say whatever you want, nobody's reading it.
  • e { 1 | 0 } — echo control 📣 Setting echo to 1 causes all output printed by bpadmin to be logged as well as sent to stdout. Setting echo to 0 disables this behavior.
  • v — version number ⭐ Prints out the version of ION currently installed and the crypto suite BP was compiled with. HINT: combine with e 1 command to log the version number at startup.
  • 1 — the initialize command 🚀 Until this command is executed, Bundle Protocol is not in operation on the local ION node and most bpadmin commands will fail. so like, do this one first, fr fr.
  • r 'command_text' — the run command 🏃 This command will execute command_text as if it had been typed at a console prompt. It is used to, for example, run another administrative program.
  • s — the start command 🎬 This command starts all schemes and all protocols on the local node.
  • m heapmax max_database_heap_per_acquisition — the manage heap for bundle acquisition command 🧺 This command declares the maximum number of bytes of SDR heap space that will be occupied by any single bundle acquisition activity (nominally the acquisition of a single bundle, but this is at the discretion of the convergence-layer input task). All data acquired in excess of this limit will be written to a temporary file pending extraction and dispatching of the acquired bundle or bundles. Default is the size of a ZCO file reference object, the minimum SDR heap space occupancy in the event that all acquisition is into a file.
  • x — the stop command 🛑 This command stops all schemes and all protocols on the local node.
  • w { 0 | 1 | activity_spec } — the BP watch command 👀 This command enables and disables production of a continuous stream of user-selected Bundle Protocol activity indication characters. A watch parameter of "1" selects all BP activity indication characters; "0" de-selects all BP activity indication characters; any other activity_spec such as "acz~" selects all activity indication characters in the string, de-selecting all others. BP will print each selected activity indication character to stdout every time a processing event of the associated type occurs:
    • a — new bundle is queued for forwarding
    • b — bundle is queued for transmission
    • c — bundle is popped from its transmission queue
    • m — custody acceptance signal is received
    • w — custody of bundle is accepted
    • x — custody of bundle is refused
    • y — bundle is accepted upon arrival
    • z — bundle is queued for delivery to an application
    • ~ — bundle is abandoned (discarded) on attempt to forward it
    • ! — bundle is destroyed due to TTL expiration
    • & — custody refusal signal is received
    • # — bundle is queued for re-forwarding due to CL protocol failure
    • j — bundle is placed in "limbo" for possible future re-forwarding
    • k — bundle is removed from "limbo" and queued for re-forwarding
  • h — the help command 💜 This will display a listing of the commands and their formats. It is the same as the ? command.

🦋 SCHEME COMMANDS 🦋

  • a scheme scheme_name 'forwarder_command' 'admin_app_command' — the add scheme command 🌈 This command declares an endpoint naming "scheme" for use in endpoint IDs, which are structured as URIs: scheme_name:scheme-specific_part. forwarder_command will be executed when the scheme is started on this node, to initiate operation of a forwarding daemon for this scheme. admin_app_command will also be executed when the scheme is started on this node, to initiate operation of a daemon that opens a custodian endpoint identified within this scheme so that it can receive and process custody signals and bundle status reports.
  • c scheme scheme_name 'forwarder_command' 'admin_app_command' — the change scheme command ✏️ This command sets the indicated scheme's forwarder_command and admin_app_command to the strings provided as arguments.
  • d scheme scheme_name — the delete scheme command 💀 This command deletes the scheme identified by scheme_name. The command will fail if any bundles identified in this scheme are pending forwarding, transmission, or delivery.
  • i scheme scheme_name — This command will print information (number and commands) about the endpoint naming scheme identified by scheme_name.
  • l scheme — This command lists all declared endpoint naming schemes 📋
  • s scheme scheme_name — the start scheme command 🎬 This command starts the forwarder and administrative endpoint tasks for the indicated scheme task on the local node.
  • x scheme scheme_name — the stop scheme command 🛑 This command stops the forwarder and administrative endpoint tasks for the indicated scheme task on the local node.

🎀 ENDPOINT COMMANDS 🎀

  • a endpoint endpoint_ID { q | x } ['recv_script'] — the add endpoint command ✨ This command establishes a DTN endpoint named endpoint_ID on the local node. The remaining parameters indicate what is to be done when bundles destined for this endpoint arrive at a time when no application has got the endpoint open for bundle reception. If 'x', then such bundles are to be discarded silently and immediately 🙈 If 'q', then such bundles are to be enqueued for later delivery and, if recv_script is provided, recv_script is to be executed.
  • c endpoint endpoint_ID { q | x } ['recv_script'] — the change endpoint command ✏️ This command changes the action that is to be taken when bundles destined for this endpoint arrive at a time when no application has got the endpoint open for bundle reception, as described above.
  • d endpoint endpoint_ID — the delete endpoint command 💀 This command deletes the endpoint identified by endpoint_ID. The command will fail if any bundles are currently pending delivery to this endpoint.
  • i endpoint endpoint_ID — This command will print information (disposition and script) about the endpoint identified by endpoint_ID.
  • l endpoint — This command lists all local endpoints, regardless of scheme name 📋

🔥 PROTOCOL COMMANDS 🔥

  • a protocol protocol_name payload_bytes_per_frame overhead_bytes_per_frame [nominal_data_rate] — the add protocol command 🚀 This command establishes access to the named convergence layer protocol at the local node. The payload_bytes_per_frame and overhead_bytes_per_frame arguments are used in calculating the estimated transmission capacity consumption of each bundle, to aid in route computation and congestion forecasting.

The optional nominal_data_rate argument overrides the hard-coded default continuous data rate for the indicated protocol, for purposes of rate control. For all CL protocols other than LTP, the protocol's applicable nominal continuous data rate is the data rate that is always used for rate control over links served by that protocol; data rates are not extracted from contact graph information. This is because only the LTP induct and outduct throttles can be dynamically adjusted in response to changes in data rate between the local node and its neighbors, because (currently) there is no mechanism for mapping neighbor node number to the duct name for any other CL protocol. For LTP, duct name is simply LTP engine number which, by convention, is identical to node number. For all other CL protocols, the nominal data rate in each induct and outduct throttle is initially set to the protocol's configured nominal data rate and is never subsequently modified.

  • d protocol protocol_name — the delete protocol command 💀 This command deletes the convergence layer protocol identified by protocol_name. The command will fail if any ducts are still locally declared for this protocol.
  • i protocol protocol_name — This command will print information about the convergence layer protocol identified by protocol_name.
  • l protocol — This command lists all convergence layer protocols that can currently be utilized at the local node 📋
  • s protocol protocol_name — the start protocol command 🎬 This command starts all induct and outduct tasks for inducts and outducts that have been defined for the indicated CL protocol on the local node.
  • x protocol protocol_name — the stop protocol command 🛑 This command stops all induct and outduct tasks for inducts and outducts that have been defined for the indicated CL protocol on the local node.

💜 INDUCT COMMANDS 💜

  • a induct protocol_name duct_name 'CLI_command' — the add induct command 🚀 This command establishes a "duct" for reception of bundles via the indicated CL protocol. The duct's data acquisition structure is used and populated by the "induct" task whose operation is initiated by CLI_command at the time the duct is started.
  • c induct protocol_name duct_name 'CLI_command' — the change induct command ✏️ This command changes the command that is used to initiate operation of the induct task for the indicated duct.
  • d induct protocol_name duct_name — the delete induct command 💀 This command deletes the induct identified by protocol_name and duct_name. The command will fail if any bundles are currently pending acquisition via this induct.
  • i induct protocol_name duct_name — This command will print information (the CLI command) about the induct identified by protocol_name and duct_name.
  • l induct [protocol_name] — If protocol_name is specified, this command lists all inducts established locally for the indicated CL protocol. Otherwise it lists all locally established inducts, regardless of protocol 📋
  • s induct protocol_name duct_name — the start induct command 🎬 This command starts the indicated induct task as defined for the indicated CL protocol on the local node.
  • x induct protocol_name duct_name — the stop induct command 🛑 This command stops the indicated induct task as defined for the indicated CL protocol on the local node.

okay that's part 1 bestie, don't go anywhere 🫶

🌈 OUTDUCT COMMANDS 🌈

okay bestie, this is the outduct era, the part where we send bundles OUT into the world 💌 each one is a little command letter followed by outduct and then the details. let's go:

  • a outduct protocol_name duct_name 'CLO_command' [max_payload_length] — the add outduct command ✨ this one sets up a "duct" for sending bundles through the CL protocol you named. the duct's whole data transmission structure gets serviced by the "outduct" task, and that task starts doing its thing when CLO_command fires at duct-start time. if you set max_payload_length to zero, that means bundles of literally any size are welcome — and zero is the default, no cap 🧢
  • c outduct protocol_name duct_name 'CLO_command' [max_payload_length] — the change outduct command 💅 gives the duct a glow-up: new payload size limit, and a new command for kicking off the outduct task for this duct.
  • d outduct protocol_name duct_name — the delete outduct command 💀 deletes the outduct matching protocol_name and duct_name. > heads up bestie: this one FAILS if any bundles are still pending transmission via this outduct. it's giving "can't leave until the queue is empty" 😭
  • i outduct protocol_name duct_name — prints info about the outduct identified by protocol_name and duct_name, specifically the CLO command 👀
  • l outduct [protocol_name] — if you pass protocol_name, it lists every outduct set up locally for that CL protocol. no protocol_name? then it lists ALL locally established outducts, every protocol, no filter, we're nosy 🌸
  • s outduct protocol_name duct_name — the start outduct command 🚀 starts the indicated outduct task on the local node, exactly as defined for that CL protocol.
  • b outduct protocol_name duct_name — the block outduct command 🚫 turns OFF bundle transmission via this outduct, and reforwards all the non-critical bundles currently queued up for transmission through it.
  • u outduct protocol_name duct_name — the unblock outduct command 🫶 turns transmission back ON for this outduct, and reforwards all the bundles sitting in "limbo" — manifesting that unblocking this outduct lets some of them finally get sent ✨
  • x outduct protocol_name duct_name — the stop outduct command 🛑 stops the indicated outduct task on the local node, as defined for that CL protocol. periodt.

💖 EXAMPLES 💖

real ones, copy-paste energy, no cap:

a scheme ipn 'ipnfw' 'ipnadminep'

declares the "ipn" scheme on the local node 👑

a protocol udp 1400 100 16384

sets up access to the "udp" convergence layer protocol on the local node, estimating the payload bytes per ultimate (lowest-layer) frame as 1400, with 100 bytes of total overhead (BP, UDP, IP, AOS) per lowest-layer frame, and setting the default nominal data rate to 16384 bytes per second ⚡

r 'ipnadmin flyby.ipnrc'

runs the admin program ipnadmin from inside bpadmin 🧚

👑 SEE ALSO 👑

and that's the whole vibe, bestie 🎀 this page is from perl v5.24.1, dated 2016-07-07, and it's BPRC(5) — iconic, historic, and now fully explained. slay 💅✨

📦 where this page comes from