Skip to main content

Known Limitations

Discord-PXE is experimental systems software. It has hardware-proven milestones, but those milestones do not make it a general-purpose production Discord/TLS/network stack.

Stable vs experimental boundary​

Hardware-proven​

  • legacy BIOS PXE/TFTP boot
  • x86-64 long-mode transition
  • native Realtek network path
  • DNS/TCP to Discord
  • TLS 1.2 / X.509 authentication
  • WebSocket upgrade
  • singleton READY
  • 4 logical CPUs online on the current test machine
  • 128 local shard contexts
  • full 128-shard READY bring-up in stable BSP mode
  • transient shard backoff/reconnect returning to READY

Implemented but not yet fully hardware-proven​

  • AP/SMP shard-state execution
  • shared-crypto serialization under SMP
  • broader live controller/runtime integration

Hardware coverage​

The runtime is intentionally close to hardware.

Behavior can vary with:

  • PXE firmware implementation
  • low-memory layout
  • NIC model/revision
  • BIOS behavior
  • CPU feature set
  • serial interface
  • PCI topology

The current tested machine should not be treated as a universal platform model.

Native NIC scope​

The current hardware path targets supported Realtek hardware.

This is not a generic driver framework for arbitrary NIC vendors.

Stable scheduler is BSP​

All logical processors can be online while the stable shard scheduler still runs protocol state machines on the BSP.

Parallel AP shard execution remains experimental because shared crypto scratch and shared native TX need stronger validation.

Shared crypto scratch​

Some primitives still use global temporary workspaces, including paths involving:

  • SHA-256
  • HMAC / TLS PRF
  • X25519
  • AES-GCM
  • RSA
  • X.509 / DER

Private shard session state does not make those implementation helpers automatically re-entrant.

Single native TX descriptor​

The tested Realtek path uses one native TX descriptor.

Under SMP, TX must be treated as a serialized shared hardware resource.

No runtime /gateway/bot discovery​

The runtime does not yet query Discord's REST API for:

  • recommended shard count
  • session-start total
  • remaining
  • reset interval
  • max concurrency

Local shell plans therefore force Identify concurrency to 1.

Resume lifecycle is incomplete​

Shard contexts contain resume-related state, but the full production-quality Resume/Identify strategy across every close/error case is not complete.

Controller security/integration​

Before external deployment, the controller still needs:

  • authenticated request signing or equivalent authentication
  • TLS
  • persistent per-device identity
  • complete live runtime check-in/renewal integration

Embedded bot credential​

A build can embed the bot token into generated runtime data.

Treat secret-bearing output binaries as credentials.

Gateway intents​

The current Identify payload uses:

intents: 0

Features requiring nonzero or privileged Gateway intents need deliberate implementation and configuration.

Purpose-built TLS​

The runtime uses its own TLS/X.509/crypto path.

Consequences:

  • smaller interoperability surface than a general TLS library
  • trust anchors must be maintained deliberately
  • parser/crypto correctness is project-owned
  • successful Discord operation does not prove general TLS compliance

Legacy BIOS dependency​

The current boot model is legacy BIOS/CSM PXE oriented.

This is not currently a UEFI-native network boot architecture.

What not to infer from the 128-shard result​

The proven 128-shard BSP bring-up does not prove:

  • 128-way SMP execution
  • multi-node controller production readiness
  • general NIC compatibility
  • complete Resume semantics
  • arbitrary Discord feature support
  • general TLS interoperability
Use the proven boundary as a regression ladder

Re-prove PXE → long mode → NIC → DNS → singleton TCP/TLS/WebSocket → small shard pool → 128-shard BSP before blaming later experimental layers.

See Hardware Testing for the current acceptance sequence.