queueing: generalize DynamicClassifier for pull-based per-class structures

[adamgeorge309]

DynamicClassifier could only build one shape: create a submodule of the configured type in a preexisting submodule vector, and wire it to a submodule literally named multiplexer. This generalizes it along three axes so it can also build pull-based per-class structures.

• Parametric aggregator. The downstream aggregator is named by aggregatorSubmoduleName (still multiplexer by default). If it implements the new IDynamicInputScheduler contract, the runtime-created input gate is registered with it — so the aggregator can be a pull scheduler instead of a push multiplexer.
• Branch splicing. With spliceBranchSubmodules, a compound moduleType forming a linear in -> a -> b -> ... -> out chain is flattened: its inner submodules are reparented into the classifier's parent as vector elements named after them (a[k], b[k]). A downstream matched-pair scheduler can then address them directly, which a compound boundary would prevent.
• Parameter forwarding. forwardMatchingParams() copies same-named parameters from the enclosing module into the created branch before it is finalized.

Branch module initialization is deferred until the whole chain — including the aggregator connection — is wired, since a module that resolves its downstream peer in initialize() would otherwise see a dangling gate. submoduleName becomes optional (unused when splicing), and the missing-vector / missing-aggregator cases now fail with a clear error instead of a null dereference.

Behaviour of existing configurations is unchanged: the defaults reproduce the previous push-multiplexer shape.

This is the enabling change for the per-station airtime-fair 802.11 transmit queue, which is proposed separately on top of this branch.

Test

Builds at every commit. Existing DynamicClassifier users are unaffected by construction (defaults unchanged).

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 2 potential issues.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🔴 Newly created traffic-class branches are never linked to the classifier, so packets of a new class break delivery

The downstream target of a newly added output is looked up (consumer.reference(...) at src/inet/queueing/classifier/DynamicClassifier.cc:56) before the branch is actually attached to that output, so the classifier ends up with no known destination for that class.
Impact: The first packet of every new traffic class either aborts the simulation with a null-reference error or silently falls back to a different delivery path, breaking normal flow control.

Reference resolution happens on a still-unconnected gate

ModuleRefByGate::reference(gate, false) (src/inet/common/ModuleRefByGate.h:80-89) resolves the peer immediately by walking gate->getNextGate() (src/inet/common/ModuleAccess.h:126-134). At DynamicClassifier.cc:55-60 the new out[index] gate has just been created by setGateSize() and is not connected yet -- the connection is only made later inside createModuleBranch() (src/inet/queueing/classifier/DynamicClassifier.cc:98) or spliceBranch() (src/inet/queueing/classifier/DynamicClassifier.cc:140). With mandatory == false the lookup silently yields nullptr, and the references are never re-resolved.

Consequences in PacketClassifierBase:

• canPushSomePacket() / canPushPacket() (src/inet/queueing/base/PacketClassifierBase.cc:86-98) call into consumers[i], whose checkReference() throws "Dereferencing nullptr...".
• pushPacket() uses pushOrSendPacket() (src/inet/queueing/base/PacketProcessorBase.cc:118-126), which falls back to send() when the consumer is null, bypassing the synchronous push API and back-pressure.

The previous implementation connected the gate first and only then created the reference, so it resolved correctly. The fix is to move the outputGates/consumers/collectors bookkeeping after the branch (and aggregator) wiring is done.

Prompt for agents

In DynamicClassifier::createBranch() (src/inet/queueing/classifier/DynamicClassifier.cc), the PassivePacketSinkRef and ActivePacketSinkRef for the new out[index] gate are resolved via reference(gate, false) immediately after setGateSize(), while the gate is still unconnected. ModuleRefByGate::reference() resolves the peer eagerly by following the connection, so with mandatory==false both refs become nullptr permanently. The gate is only connected later, in createModuleBranch()/spliceBranch(). This makes consumers[index] null, which makes PacketClassifierBase::canPushPacket()/canPushSomePacket() throw and makes pushPacket() fall back to send() instead of the push API. Restructure createBranch() so that outputGates/consumers/collectors are populated only after the branch has been created and classifierOutputGate has been connected to the branch input (the previous implementation connected first, then referenced). Note outputGates must stay index-aligned with consumers/collectors.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[adamgeorge309]

Fixed in f03585e — the references are now taken after the branch and the aggregator connection are wired, so reference() resolves against a connected path instead of storing a silent nullptr.

[adamgeorge309]

Fixed in f03585e590 — the sink references are now taken after the branch is wired through to the aggregator. They resolve the far end of the path eagerly, so taking them earlier resolved them against a gate that was not connected yet.

[devin-ai-integration]

🟡 Creating the first per-class branch can delete pre-existing branch modules declared in the network description

The branch container is resized to exactly the new branch position (setSubmoduleVectorSize(submoduleName, index + 1) at src/inet/queueing/classifier/DynamicClassifier.cc:96) instead of only ever growing it, so any pre-existing branches beyond that position are destroyed.
Impact: Statically configured per-class branches can silently disappear at runtime, so traffic that should flow through them is lost or the run aborts.

Removal of the std::max() guard

The previous code deliberately used parentModule->setSubmoduleVectorSize(submoduleName, std::max(origVectorSize, submoduleIndex + 1)) so the vector was never shrunk. The new code passes index + 1 unconditionally. index is the classifier's current out gate count, which is not necessarily >= the NED-declared vector size (e.g. a parent declaring defragmenter[numDefragmenter] whose classifier out gate vector was sized independently). Shrinking an existing submodule vector deletes the elements above the new size. The same unguarded resize is repeated in the splice path at src/inet/queueing/classifier/DynamicClassifier.cc:133.

Suggested change

	parent->setSubmoduleVectorSize(submoduleName, index + 1);
	parent->setSubmoduleVectorSize(submoduleName, std::max(parent->getSubmoduleVectorSize(submoduleName), index + 1));

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[adamgeorge309]

Fixed in 680d9c8, via a grow-only helper at both resize sites. One correction to the premise: setSubmoduleVectorSize() refuses to shrink over a range that still holds submodules rather than deleting them, so the failure mode was an aborted run, not modules silently disappearing.

[adamgeorge309]

Fixed in 680d9c8a13 — growSubmoduleVector() takes the max of the current and required size, so a vector declared larger in NED is never truncated.

[levy]

The IDynamicInputScheduler interface has no implementors, how does this work? What's the point of having this interface?

Why doesn't the module use the signals emitted when a gate gets connected?

[adamgeorge309]

Both fair points — fixed.

The interface is gone. Its only implementor lived in the follow-up airtime-fairness branch, so within this PR it was an orphan contract. And the notification is the better mechanism: an aggregator that needs to notice a runtime-added input now picks it up from the POST_MODEL_CHANGE / cPostPathCreateNotification of the connection itself. The classifier no longer knows anything about the aggregator beyond wiring a gate to it.

Two more, from the bot review:

• The PassivePacketSinkRef/ActivePacketSinkRef of a new branch were resolved right after setGateSize(), while the gate was still unconnected. reference() resolves eagerly, so with mandatory=false it stored a nullptr that nothing ever re-resolved: canPushPacket() threw on it, and pushPacket() quietly degraded to send(), bypassing back-pressure. The references are now taken after the branch and the aggregator connection are wired.
• The branch submodule vector was resized to exactly index + 1, which can shrink a vector declared larger in NED. Both resize sites now go through a grow-only helper.

Pushed as three commits on top.

[adamgeorge309]

A separate defect in the splice path, not covered by any thread above.

Spliced branches record all their vectors under the temporary compound's path, so per-station vectors are indistinguishable. In a 4-station run, all four sub-queues emit the same vector name — four ids, one name:

vector 381 ...channelAccess.pendingQueue.splicetmp.queue queueLength:vector ETV
vector 402 ...channelAccess.pendingQueue.splicetmp.queue queueLength:vector ETV
vector 423 ...channelAccess.pendingQueue.splicetmp.queue queueLength:vector ETV
vector 444 ...channelAccess.pendingQueue.splicetmp.queue queueLength:vector ETV

VectorRecorder::subscribedTo() binds the name once from getComponent()->getFullPath(), and addResultRecorders() runs at the end of cModule::buildInside() — so the path is captured while the module is still a child of splicetmp, before spliceBranch() reparents and renames it into queue[k]/gate[k]. Nothing re-registers afterwards; the handle is only released in the destructor.

Deferring callInitialize() does not help here, since recorders bind strictly earlier, during buildInside(). Scalars are unaffected because they resolve the component at finish() time — which is why the .sca correctly shows queue[0..3]/gate[0..3] while the .vec does not.

A fix needs each branch module to have its final parent and name before buildInside() runs on it, which the throwaway-compound approach cannot give. I have not attempted it yet.