Connections

Push and pull#

Every connection has an active side and a passive side. A Generator pushes: it decides when an entity exists and hands it downstream. A Server pulls: it asks its source for work, and once the work is done it pushes the finished entity onward. A Queue is passive — it never acts on its own, it only answers the components attached to it. A Delay is both: it is fed like a queue and pushes onward like a generator. A Router, a Shared Server, an Acquire and a Release are wired the same way as a delay. A Resource Pool has no connections at all: it sits beside the flow, and the Acquires and Releases that use it name it in their settings.

That is why Generator → Queue → Server is the shape everything is built from: an active component on each end, with the passive buffer in the middle absorbing the difference in pace. Connecting two active components directly leaves nowhere for the mismatch to go.

Full queues and waiting#

The two sides of a connection are not equally patient. A pull from an empty queue waits for an entity, for as long as it takes — an idle server loses nothing by waiting. As soon as an entity arrives it is handed straight to the waiting server, without ever being stored.

A push into a full queue depends on the queue's Overflow Policy. Under Overwrite Oldest and Drop Newest nothing ever waits: the queue drops an entity itself and counts it as its own. Under NO_OVERRIDE, the default, the queue holds the arriving entity outside. Waiting entities are admitted in the order they arrived, one each time an entity leaves the queue, or when the capacity is raised. They are not part of the queue's length.

How long an entity waits is the Wait Timeout of the component that sent it. Only the Generator and the Server have one. It is set in the editor, in seconds, from 0 to 3600, and starts at 1. If the timeout passes before room appears, the entity is dropped and counted against its sender — the generator's or the server's Dropped figure. A Wait Timeout of 0 means no waiting at all: the entity is dropped at once. That is the classic loss model, and what the M/M/1/K model in the library uses on its generator.

A generator keeps producing on schedule while its entities wait, and each entity waits on its own timeout. A server is Blocked while its entity waits, and serves nothing else until that entity is admitted or dropped. That is how congestion travels backwards through a model: a full queue holds up the server in front of it, and the queue feeding that server fills in turn.

A Delay, a Router, a Shared Server, an Acquire and a Release do not wait. Faced with a full queue they drop the entity at once and count it against themselves. Nothing ever waits to get into a shared server, or is refused by one: it accepts every entity it is sent. An Acquire accepts every entity too, and holds the ones that find no free unit until one is returned or the pool's Acquire Timeout passes.

Every drop also counts in the model-wide dropped total, whichever component it is counted against. It is the loss that shows up on the entity rate charts and in the dropped figures.

A model that relied on a full queue dropping arrivals immediately now needs a Wait Timeout of 0 on the sender, because new generators and servers start out waiting 1 second.

Multiple connections#

Any component may have several incoming connections. A generator, a server, a delay, a shared server, an Acquire and a Release each have one outgoing connection: drawing a second line from one replaces the first. To divide their traffic, put a Router after them and choose how it splits — round-robin, at random or by weight.

A queue keeps several outgoing connections, because nothing is being divided there: its consumers take from it, and each entity goes to whichever server asks first. That is how a pool of parallel servers behind one queue is built.

A server with several incoming connections polls them round-robin, so a server drawing from two queues alternates between them. Round-robin does not look ahead: a server whose turn has come on an empty queue waits there even if the other queue has work.

When a Server, Delay, Router, Shared Server, Acquire or Release has no outgoing connection at all, entities leaving it are counted as completed and exit the model. That makes the last server in a chain a natural exit point — there is no separate sink component to place. Cycle time is measured at these exits.

Wiring rules#

A model has to be wired up before it can run. The simulator checks these rules when you press play, highlights any component that breaks one, and explains what is missing:

• A Generator must have an outgoing connection — it has nowhere to put entities otherwise.
• A Queue must have an incoming connection — nothing would ever fill it.
• A Server must have an incoming connection — it has nothing to pull from otherwise.
• A Delay must have an incoming connection — nothing would ever pass through it.
• A Shared Server must have an incoming connection — nothing would ever reach it.
• An Acquire and a Release must each have an incoming connection and a pool — the Resource Pool they take a unit from or return it to. A resource pool itself needs nothing.
• Every connection must join an active side to a passive one. Two components that both start transfers — a generator, server, delay, router, shared server, Acquire or Release feeding straight into a server — need a queue between them. Two that both wait to be asked — a queue feeding a queue, a delay, a router, a shared server, an Acquire or a Release — would never move anything.

The simulator enforces the last rule as you draw: while you drag a connection, only the inputs it can legally join are offered.

Outgoing connections are optional. On a server, a delay, a router, a shared server, an Acquire or a Release, an unconnected output is a legitimate exit from the model — entities that leave it count as completed. A queue with no outgoing connection is accepted too, but nothing will ever drain it, so it fills to capacity and stays full.