ipc/notes/allocation-request.tid

created: 20240302172215000
creator: jds
modified: 20240302172259000
modifier: jds
tags: 
title: allocation-request
type: text/vnd.tiddlywiki

! allocation request

I want to

* ~~create a unix socket~~,
* ~~listen for a connection~~,
* ~~accept an "alloc" request~~,
* respond with success or failure.

Success entails

* searching for the requested AP/APinst/APM/APMinst
* creating a new instance of communication (EFCP/IAP)
* requesting an exchange with the app (IAP)
* receiving and processing a response (IAP)
* perform allocations for mem mgmt/queueing strategy
* provisioning a new EFCP instance for the new flow (EFCP)
* provide the client a port for the new instance of comm

~~A dedicated goroutine, locked to an isolated OS thread,
should run each mux (tx and rx).~~ Not quite. This is
wasteful if the client has not requested a service cube that
requires this measure. Such service cubes include realtime
(minimum latency, small SDUs), voice (minimum jitter, small
SDUs), and wire speed (max volume). All three involve
strict processor scheduling (order and rate of queue
servicing), and the third additionally requires possibly
enormous queue lengths (memory management), especially for
reliable transfer (sequence recovery).

For very large PDUs, it may be necessary to exclusively
employ FEC, even though link latencies will tend to be
lowest at large aggregation points. Is it reasonable to use
something like FEC at the top layer? I suppose it depends.
If reliable datagrams are requested, the network is liable
for ensuring reliable delivery. By comparison, TCP-style
streams make endpoints solely responsible for reliability,
which may use rather slow sequence recovery mechanisms at
the top layer, where round-trip delays are longest.

Success assumes the application process requesting
allocation of resources is already
[[registered|registration]].