DEV Community: Thuangf45

I Got Tired of Maintaining Frontend Code. So I Built a Declarative UI Runtime.

Thuangf45 — Fri, 10 Jul 2026 06:15:15 +0000

Here is a question that sounds simple until you've actually shipped a UI: how many files does it take before nobody on the team, including you, can confidently say what happens when you click a button?

For me, the answer turned out to be somewhere around two hundred. Not because the logic was complicated. Because nothing in those two hundred files agreed with anything else about how a button should be built.

This is the story of how I got there, what it cost me, and the engine I eventually built to make sure it wouldn't happen to me again. LuciaCore is a prototype, not a finished framework, but it already does the one thing I set out to make it do: let me describe a working, interactive web page as data, instead of assembling it by hand every time.

Where I came from

My background is systems programming: operating systems, networking, CPU scheduling, architecture, API performance. That's the layer where I'm comfortable, because the problems there tend to be well-defined. You can usually name the bottleneck, measure it, and know whether your fix actually worked.

Nothing runs in isolation forever, though. At some point, whatever gets built needs a face, a web app, a mobile client, a desktop tool, something a person actually clicks on. So I picked up frontend development, assuming it would be the easy detour before getting back to the interesting work. HTML, CSS, and JS took a day or two to understand conceptually. A few more days of tutorials and small exercises, and I felt ready.

I was wrong about the "easy" part, but not in the way I expected. The syntax was never the problem.

What a growing frontend project actually costs you

I started with a portfolio site. Small in scope, on paper. In practice, it took an entire month, and almost none of that month went into deciding what the site should say or look like. It went into everything that sits between an idea and a working page.

CSS was the first tax I paid. Every button needed its alignment decided by hand. Every new class needed a naming convention, one I was inventing as I went, and every new page tempted me to bend that convention slightly rather than follow it. That's how a project quietly ends up with three different ways of writing what is functionally the same button, none of them wrong exactly, just uncoordinated.

The second tax was file count. I split the project into small modules for the sake of organization, dozens of files at first, then hundreds of HTML, CSS, and JS files. That solved readability at the file level and created a loading problem at the page level, since every page pulled in far more separate requests than it needed. So I bundled everything down: one JS file, one CSS file, a handful of HTML files per page. That fixed load time and quietly made the next problem worse.

Roughly, the shape of that change looked like this:

Before (hundreds of small files)          After (bundled)
portfolio/                                 portfolio/
├── header.html                            ├── index.html
├── header.css                             ├── about.html
├── header.js                              ├── contact.html
├── footer.html                            ├── bundle.js
├── footer.css                             └── bundle.css
├── footer.js
├── button-primary.html
├── button-primary.css
├── button-primary.js
├── button-secondary.html
├── button-secondary.css
├── button-secondary.js
└── ... 190+ more files like this

Fewer requests, same underlying problem: every one of those original files still had to be found, opened, and understood by hand whenever something needed to change.

The real cost showed up during maintenance. Every UI tweak or visual bug turned into a search, going file by file, trying to find whichever one was actually responsible for what I was looking at on screen. Nothing pointed back to its source in an obvious way, because nothing had been built to a consistent shape to begin with. Each component reflected whatever I happened to think looked right that day, with no shared structure connecting one to the next. That's the part that's hard to explain to someone who hasn't lived through it: no single file was bad. The problem was that holding an entire project's accumulated inconsistency in your head at once had become its own full-time job.

Around then I looked at Tailwind, React, and TypeScript, assuming a proper framework would make the problem go away. It moved the problem instead of removing it. I still needed npm, a build pipeline, and configuration files, and I still ended up with hundreds of files, just organized under someone else's conventions instead of mine. The portfolio project sat unfinished for a long time after that. Not because I didn't know how to write the UI. Because the overhead of keeping it consistent had outpaced my patience for it.

The realization

For a while I kept framing the problem as "which tool solves this," which meant I kept evaluating frameworks against each other and finding the same shape of overhead underneath all of them: files to organize, conventions to enforce by hand, a build step standing between the source and the running page.

The actual shift happened when I stopped asking which framework, and started asking a more uncomfortable question: what if the problem wasn't the framework at all? What if it was the fact that I was hand-assembling HTML, CSS, and JS every single time, regardless of which tool I used to do it? Frameworks were giving me better ways to organize that assembly work. None of them were removing the requirement to do it.

That's the moment LuciaCore actually started, not as a search for a better framework, but as an attempt to eliminate the manual assembly step entirely. If a browser can already run HTML, CSS, and JS natively, the real question was whether something could sit on top of that and generate the markup and behavior on my behalf, driven by nothing more than a description of what I wanted, rather than a hand-written implementation of it.

Why JSON

HTML describes structure. CSS describes appearance. JavaScript describes behavior.

LuciaCore doesn't try to replace any of those three. It sits one level above them, describing what a developer intends the interface to be, rather than the implementation of any single layer. All three of HTML, CSS, and JS are still implementation underneath it, and implementation is exactly where the inconsistency I'd been fighting kept creeping in, because implementation has to be redone by hand every single time, and hand-done work drifts.

What I wanted instead was a way to describe intent: this is a button, it says this, it does that when clicked, place it here. Not how to construct that button node by node, but what the button is supposed to be. JSON turned out to be a good fit for that, not because it's a clever format, but because it's just data. It has no execution model of its own, so there's nowhere for implementation detail to sneak back in. The engine, not the author, is left responsible for turning that description into an actual DOM node, actual scoped styles, and an actual event listener, the same way, every time, regardless of who wrote the JSON or when.

Written out, that description looks like this:

{
  "type": "button",
  "label": "Get started",
  "action": "navigate::to::signup",
  "style": "background: #2563eb; color: white; padding: 12px 20px; border-radius: 8px;"
}

and the engine turns it into this, every time, regardless of who wrote the JSON:

<button
  class="lucia-button"
  style="background:#2563eb; color:#fff; padding:12px 20px; border-radius:8px;"
  data-action="navigate::to::signup">
  Get started
</button>

Nothing in the JSON describes how the DOM node gets built, how the click listener gets attached, or how the style gets scoped so it doesn't leak into the next button on the page. All of that is the engine's responsibility, and it's handled the same way for every node, which is exactly the property I didn't have before.

That's the core distinction LuciaCore is built around. It isn't a component library with a different syntax. It's closer to a declarative UI runtime, something that sits in the browser and interprets a description of an interface, rather than a framework you configure and build against. JSON just happens to be the serialization format that description is written in, it isn't the interesting part on its own, it's a convenient, unambiguous way to write down intent. I'm avoiding the word "framework" deliberately here, because a framework usually still expects you to write the implementation, just inside its rules. LuciaCore is asking for the description instead, and handling the implementation itself.

Designing the vocabulary

Once I'd committed to describing UI as data, I needed to decide what the smallest usable vocabulary looked like. I split interfaces into two categories:

Layouts, row, column, grid, card, which control how children are arranged.
Primitives, button, text, input, image, loading,... the actual leaf elements a user sees and touches.

In practice, a small piece of UI is just those two categories nested inside each other:

row
 └─ column
     ├─ text    "Welcome back"
     └─ button  "Sign in"  →  action: navigate::to::home

Nothing in that tree is a special case. A column doesn't know or care whether its children are more layouts or primitives, it just arranges whatever it's given, which is what makes the two categories composable instead of a fixed set of page templates.

I chose JavaScript to build the engine itself for an unglamorous reason: the browser already runs HTML, CSS, and JS natively, so if the engine is just JS, the only thing a project needs on top of it is one JSON file. No npm install, no build step, no compiler stage between the source and the running page.

Once the layout and primitive split existed, a few more concepts fell out of it almost on their own:

type declares what to render, a layout, a primitive, a component defined elsewhere in the file, or a standalone module, as long as it resolves to a valid name.
style is raw CSS that the engine injects and scopes automatically, so any layout or primitive can be visually overridden without touching engine internals.
action is a string describing a system call I defined myself, and this one deserves its own explanation.

The action DSL

I didn't want click handlers scattered across the codebase the way I'd had them before, each one a small, differently-shaped piece of imperative logic. What I wanted was for behavior to be describable the same way structure already was: as intent, not as a sequence of steps.

That's why actions in LuciaCore are plain strings like navigate::to::home, alert::message, api::call, or storage::set::key::value. Each one reads roughly like a sentence: verb, then target, then argument. navigate::to::home doesn't tell the engine how to swap pages, tear down the old DOM, or restore scroll position. It says where the user intends to go, and the engine owns the how. The same is true for api::call, which describes that a request should happen, not the fetch boilerplate underneath it.

A button wired to one of these needs nothing else attached to it:

{
  "type": "button",
  "label": "Save changes",
  "action": "api::call |> alert::Saved!"
}

On click, the engine reads that string and does two things in order: it fires the request described by the action, then shows the confirmation, once the first step resolves. Nothing about the fetch call, the loading state, or the sequencing between the two steps was written by hand for this button. It's declared once, in the string, and interpreted the same way for every button that uses it.

The distinction that matters here is the same one as everywhere else in the engine: the action string says what should happen, not how to implement it. navigate::to::home and api::call |> alert::Saved! are declarations of intent, not procedures. The engine still has to write the actual imperative code somewhere, the fetch call, the DOM swap, the event binding, but that code lives in one place, inside the engine, instead of being reinvented slightly differently in every click handler across a project.

This mirrors the same trade I made with layouts and primitives. A hand-written onClick handler is implementation, and implementation is where inconsistency and one-off bugs like to live. A declarative action string is intent, interpreted the same way everywhere it appears.

For anything genuinely too custom for this vocabulary, I defined a resolution contract instead of extending the DSL indefinitely. A type like button::buy::shop::item::0 resolves to /button/buy/shop/item/0.js. If it's a render module, the contract is a render function. If it's an action module, the contract is an execute function. Same naming convention, same resolution logic, whether you're extending rendering or behavior. The engine doesn't need to know the difference until it actually opens the file.

It also became clear early on that putting every piece of UI directly into a page's JSON would just recreate the sprawl I was trying to escape, in a new format. So I introduced components, reusable UI definitions referenced by type, with data flowing into them through props: and item: tokens. The rule I settled on is simple, and I think it's the right default: the node being called always has final say over its own values. The caller supplies defaults, the callee can override them. That keeps composition predictable. You can reason about a component in isolation, without tracing every possible caller that might feed it data.

Here's what that looks like end to end. The component defines its own shape once:

{
  "type": "custom_cta_button",
  "layout": {
    "type": "button",
    "label": "props:label",
    "action": "props:action",
    "style": "background:#16a34a; color:white; padding:10px 18px; border-radius:6px; props:style;"
  }
}

and any page can call it, supplying only the values that differ:

{
  "type": "custom_cta_button",
  "props": {
    "label": "Start free trial",
    "action": "navigate::to::signup",
    "style": ""
  }
}

The component owns its structure and styling defaults. The page calling it only ever supplies data. Neither side needs to know the other's internals to work correctly together.

Looking back, this is roughly the point where the project stopped being just a JSON schema and started being something closer to a small declarative language: types, layouts, actions, tokens, and a resolution contract for extending all three. JSON is still just the syntax that language happens to be written in. I don't want to overstate this, it's a small language with a narrow purpose, not a general-purpose one, but it's more accurate to describe it that way than to call it a data format with some conventions attached.

Two files, then one

The engine split naturally along its two responsibilities: action.js for parsing and dispatching behavior, render.js for reading JSON and generating HTML and CSS. Getting each into a shape that actually held together took an unglamorous number of iterations, implement, break, fix, repeat. Nothing about that part was clever. It was just work.

Along the way I refactored harder than I expected to. Early on, out of sheer file-splitting habit left over from the portfolio project, I'd broken every primitive into its own file, row.js, button.js, one file per concept. Once the engine's behavior stabilized, I noticed that split was pure overhead: layouts and primitives share roughly 99% of the same rendering logic, just with different tag names and default styles. I folded it all back into the engine's core instead of scattering it across files, the same instinct that had caused the original mess, now working in the opposite direction.

I added main.js to wire action.js and render.js together, and to read the system block of content.json, versioning, and registering a Service Worker for offline caching when one is configured. After that refactor, the whole engine was down to three lean files, which I bundled and obfuscated into a single luciacore.engine.js, the only script a project needs to load.

The first real feedback

After running it myself for a few days, I showed it to another engineer I know. Their reaction was direct: it was easy to pick up, specifically because there's now one standardized way to describe UI, generated consistently by the engine, instead of everyone inventing their own structure the way I had. You can still customize anything, the engine just compiles it down to the same consistent shape every time, regardless of who wrote it.

I also handed it to someone with no engineering background, and they hesitated, not because the underlying idea was wrong, but because I hadn't separated concerns cleanly enough yet. Layout and content lived in the same JSON, which meant editing a headline required understanding row, column, and props first. That's what led me to split components from contents:

components define how something looks, built from layouts and primitives, the part that requires understanding structure.
contents define what it says, the actual text and data values, the part a non-technical collaborator should be the only thing they need to touch.

That split opened a door I hadn't planned for originally: components as shareable, drop-in pieces. Instead of asking "can I get your HTML, CSS, and JS," you ask "can I get your component," paste the JSON into your own content.json, and it works, no framework version to match, no build config to reconcile. It's a smaller, more contained unit to hand off than a chunk of markup or React code you'd otherwise hesitate to touch without fully understanding it first.

What this means for working with AI tools

There's a side effect of this structure worth mentioning, but I want to be careful about how, because it's easy to overstate. It isn't that a language model becomes smarter when it reads LuciaCore's JSON. It's that a small, bounded, consistently-shaped schema is simply less for any reader, human or model, to hold in working memory at once, compared to hundreds of loosely related HTML, CSS, and JS files with no shared structure connecting them.

A model reasoning about a UI written as scattered markup has to reconstruct the relationships between files first: which class affects which element, which script wires up which button, before it can reason about the actual change being asked for. A content.json file skips that reconstruction step, because the structure is explicit and uniform by construction. A page is a tree of typed nodes. Styles are locally scoped. Actions are declared inline, next to the node they belong to. Ten lines of that schema is a smaller, more predictable context than five hundred lines of implementation detail, not because the model got better at reading code, but because there's less ambiguity to resolve before it can start reasoning about intent.

Making it fast: an optimization story

Getting the vocabulary right didn't make it fast, and I want to be specific about why, because the failure mode here is an ordinary one for anything doing recursive tree rendering on a single thread.

The engine renders a page by recursively walking the JSON tree and building HTML and CSS from it. JavaScript in the browser is single-threaded, so that recursive rendering work and the logic and network work, fetching data, running actions, were competing for the same thread. The practical result was contention: the UI couldn't paint until rendering finished, and rendering was sharing time with whatever network or logic work happened to be in flight at the same moment. On pages with a lot of nodes, that meant three to five seconds to open on a laptop, and ten to fifteen seconds on a phone. Slow enough to notice immediately, not a rounding error.

Roughly, the before and after looked like this:

Before — everything blocks the same thread
main thread: |--- walk JSON tree ---|--- fetch data ---|--- run actions ---|
             |                                                             |
             page load starts                                    first paint (3–5s desktop, 10–15s mobile)

After — UI paints first, work continues in the background
main thread: |--- paint skeleton ---|
             |                      |
             page load starts       first paint (near-immediate)
                                    |--- fetch data ---|--- hydrate nodes ---|  (background)

Two changes addressed most of it, in this order.

The first was letting the main thread yield to the browser's paint cycle before doing anything else. Rather than running the render walk and the logic and network work back-to-back on the same thread, I restructured the flow so the UI could paint a skeleton immediately, yielding execution back to the browser so it could actually draw, before continuing with data fetching and action logic in the background. The scheduling change didn't make any individual piece of work faster. It just stopped forcing the user to wait for all of it to finish before seeing anything at all.

The second was caching compiled pages, keyed by a hash of the content. Recompiling the entire JSON tree into HTML and CSS on every visit is wasted work if nothing has changed since the last one. LuciaCore now hashes content.json and only recompiles a page when that hash actually changes, storing the compiled result for reuse. Cache invalidation here is simple by design: the hash either matches or it doesn't, so there's no separate invalidation logic to keep correct over time. Repeat visits, laptop or mobile, became noticeably faster once recompilation stopped happening on every load.

Neither change altered what the engine renders, only when and how often it does the expensive part of the work. That's usually where the real performance win is hiding in a system shaped like this: not in a faster algorithm, but in not redoing work you already did.

What building with LuciaCore looks like today

The whole setup is two files.

index.html, scaffolded with ! and Tab in VS Code, then one script tag added:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My App powered by Lucia</title>
    <script defer src="https://cdn.jsdelivr.net/gh/thuangf45/luciacore.assets@master/luciacore.engine.js"></script>
</head>
<body>
</body>
</html>

content.json, the actual workspace, with four sections:

{
  "system": { "version": "1.0.0", "debug": true },
  "pages": [
    {
      "name": "home",
      "layout": {
        "type": "column",
        "style": "padding: 40px; gap: 16px; align-items: center;",
        "children": [
          { "type": "text", "level": "h1", "label": "Hello LuciaCore" },
          { "type": "button", "label": "Click me", "action": "alert::It works!" }
        ]
      }
    }
  ],
  "contents": [],
  "components": []
}

system, engine configuration: debug mode, versioning, offline caching.
pages, the routes of the app, reached with navigate::to::pageName.
contents, the editable text and data a non-technical collaborator should touch.
components, reusable UI templates built from layouts and primitives, referenced by type and fed data through props: and item: tokens.

That's the entire mental model needed to start. No package manager, no build step. The engine does that work in the browser, at the moment the page loads.

Where it stands, and why I built it this way

I want to be direct about the current state: LuciaCore is a prototype. It hasn't been through years of production edge cases the way an established framework has, and I'm not claiming it should replace one, or that it renders faster than the tools people already reach for. What I can say is narrower, and I think more honest: it's a genuinely usable engine, today, for building real interactive, multi-page UIs, buttons that do things, pages that navigate, data loaded from an API, described entirely as data rather than code.

I wasn't trying to replace the browser. The browser already does its job well. I was trying to reduce the amount of frontend complexity I personally had to manage by hand, the naming conventions, the file sprawl, the one-off click handlers, the accumulated inconsistency that made a small portfolio site take a month to finish. Describing structure, behavior, and content as three separate, explicit things, instead of one undifferentiated pile of markup and script, is the trade LuciaCore is built around, and it's a trade I'd make again.

Every framework I've used represents a different set of trade-offs, and none of them is free. React, Vue, and Angular each trade differently between flexibility and structure, and each is better suited to some problems than others. LuciaCore isn't an attempt to beat any of them at what they do. It's an exploration of a different trade: developers describe intent, and the runtime owns the implementation, in exchange for less flexibility at the edges than a general-purpose framework would give you.

If you've run into the same wall, or if you look at this and immediately see where it would break under your own workload, I'd rather hear about it than not. The code and docs are on GitHub.

Github: LuciaCore Engine
Gitbook: Luciacore Docs

LuciferCore: The Redemption Arc — From a Naive Prototype to a Battle-Tested .NET Framework

Thuangf45 — Fri, 03 Jul 2026 13:52:42 +0000

Every software engineer has that one project.

The project that keeps you up at 3 AM.

The project where you look at your code from a few months ago and physically cringe.

For me, that project is LuciferCore.

This is the third time I am sharing this framework on Dev.to. But this time, everything is different. I am not here just to show you another update. I am here to share a story of mistakes, learning, and engineering maturity.

The Journey: Three Versions, Three Lessons

November 2025: The First Step

I was filled with pride. I launched my very first open-source package.

In reality, the architecture was shaky.
The code was rough and chaotic.
It was a naive prototype, but it was a start.

March 2026: The Slap in the Face

I came back for the second time. The architecture finally had a clear shape, but it was far from ready.

The code quality was poor.
There were no unit tests.
There were no benchmarks or performance tests.
The documentation was missing, and the internal logic was unstable under real heavy load.
I practically had to slap my younger self in the face for being careless.

Today: The Serious Return

Today, I am back with a completely different mindset. I spent the last few months doing intense self-DDoS tests, fixing core logic, and polishing the system.

LuciferCore is no longer a toy. It is a stable, mature, and serious event-driven framework built for high-performance Modulith architectures on .NET.

What Makes LuciferCore Different Now?

We focused heavily on Performance, Architecture, and Developer Experience (DX).

The Buffer Model: Built around a Data-Oriented Buffer Model. It reduces memory allocations and optimizes CPU cache patterns.
Minimal API Surface: The philosophy is simple: Decorate ➜ Implement ➜ Run.
True Modulith Design: Your components are just plain DLLs. The engine automatically discovers them using clean attributes like [Server], [Manager], [Middleware], [Handler], and [Route].

Cold, Hard Data: The Benchmarks

We do not guess performance anymore. We verified it.

We ran a 60-second local stress test using Bombardier with 600 concurrent connections.

Most benchmarks use clean, isolated Linux servers. We did the exact opposite. We chose a brutal, messy, real-world setup:

The Machine: A standard 8-core Intel i5 laptop.
The OS: Windows (notorious for higher networking overhead).
The Stress: Both the server and the heavy load generator (Bombardier) ran on this single laptop at the same time.
The Chaos: Normal daily background Windows applications were kept running during the test.

This means LuciferCore had to fight for every single hardware resource. Yet, the results were extreme:

Static Files: ~160,000 requests per second (req/s).
Pipeline Overhead: Only ~1% to 3% total framework overhead from the raw network layer all the way to the final response handler.
Resource Stability: CPU ran at ~99% (fully saturating the remaining hardware power). Memory stayed stable at 100–300 MB.
GC Pressure: Garbage Collection pressure was virtually zero (Gen0: 1321, Gen1: 34, Gen2: 0).

Even when choked by a standard OS and running side-by-side with its own attacker, the framework refused to drop under pressure.

Production Ready & Commercial Growth

I want this project to be highly professional. That is why I fixed the two biggest mistakes from my past:

1. Excellent Documentation

You do not need to guess how the code works. We now have a clear, step-by-step guide. If you follow the official documentation, you can get a high-performance system running in 1 to 5 minutes.

Read the Guides: LuciferCore Official GitBook Docs

2. Dual Licensing

LuciferCore is now ready for business. It uses the AGPL-3.0 license for open-source projects. If you are building a commercial or closed-source system, a Commercial License is now available for purchase to support the project.

Connect and Support

This framework is a living ecosystem. I want to make it even better, and I cannot do it alone.

I sincerely look forward to your honest feedback, code reviews, and suggestions. Pull the package, follow the 5-minute guide in the docs, and test its limits.

NuGet Package: Get LuciferCore on NuGet
Official Docs: Read the GitBook Docs
Author Profile: Nguyen Minh Thuan on Github

If this framework helps your workflow or adds value to your business, please consider supporting the project by purchasing a commercial license.

Let's build a faster, cleaner .NET ecosystem together.

Stop Thinking of HTTP as Request/Response. It's a Universal Data Layout — and It's Faster Than Binary Protocol.

Thuangf45 — Sun, 12 Apr 2026 01:33:18 +0000

Everyone "knows" binary protocol is faster than HTTP.

I used to believe that too. Until I stopped looking at HTTP as a wire protocol and started looking at it as what it actually is — a layout engine for the CPU.

That reframe changed everything.

0. The Mental Model That's Costing You Performance

The industry standard narrative goes like this:

"Binary protocols are fast because they're compact and machine-readable. HTTP is slow because it's human-readable text."

On the surface, it sounds reasonable. So engineers reach for Protocol Buffers, MessagePack, custom binary frames — anything to "get away from HTTP overhead."

But here's the question nobody asks: What exactly is the CPU doing when it parses your binary protocol?

Let's answer that honestly.

1. How Your CPU Actually Reads Data

Modern CPUs don't read byte by byte. They don't read int by int. They read 128 to 512 bits at a time — thanks to SIMD (Single Instruction, Multiple Data) registers. AVX2 can scan 256 bits per instruction. AVX-512 does 512 bits. The hardware wants to eat data in large chunks and run fast.

Now look at what a typical binary protocol demands:

// Hypothetical fixed binary protocol — 20 fields
[offset 0,  size 4]  = MessageType
[offset 4,  size 4]  = SequenceId
[offset 8,  size 2]  = Version
[offset 10, size 2]  = Flags
[offset 12, size 4]  = Timestamp
[offset 16, size 8]  = UserId
// ... 14 more fields

To read this, the CPU must:

Go to offset 0, read 4 bytes → MessageType
Go to offset 4, read 4 bytes → SequenceId
Go to offset 8, read 2 bytes → Version
...repeat 17 more times

That's 20 sequential reads, each guided by hardcoded human-defined offsets. The CPU is operating at human speed — one field at a time, exactly as the programmer specified.

And if those 20 fields are pointers rather than inline values? The CPU reads a pointer at offset N, then jumps to a completely different memory location to fetch the actual value. Minimum 40 memory operations — each with potential cache misses. The pipeline stalls. Performance collapses.

Binary protocol is forcing a 512-bit-capable CPU to act like a human reading a checklist.

2. What HttpModel Does Instead

HttpModel is not HTTP/1.1. Let me be clear about this upfront.

RequestModel and ResponseModel are just two specific instances of HttpModel. The model itself is general. Its structure is:

[Token1] [Token2] [Token3]\r\n
[Key]: [Value] \r\n
[Key]: [Value] \r\n
\r\n
[Body]

That's it. A start-line with three tokens, an arbitrary number of key-value header pairs, and a body. Nothing is fixed. Nothing is locked.

For HTTP requests, the three tokens happen to be Method, URL, Protocol. For HTTP responses, they're Protocol, StatusCode, StatusPhrase. For a game server? They could be Hp, Atk, Def. For a custom RPC? They could be ServiceName, MethodName, RequestId. The layout is yours to fill.

This is what I mean by HttpModel as a universal data layout.

3. The Parse That Runs at Machine Speed

Now here's where it gets interesting. When HttpModel receives bytes, this is what happens:

// From ReceiveHeader() in HttpModel.cs
var headerEnd = Lucifer.IndexOf(span, CrLfCrLf);      // One SIMD scan
var firstLineEnd = Lucifer.IndexOf(span, CrLf);         // One SIMD scan

// Split start-line into three tokens
Lucifer.TrySplitAt(startLine, Space, out var first, out var rest1);
Lucifer.TrySplitAt(rest1, Space, out var second, out var third);

// Mark positions — no allocation
_first  = new Position(offset, length);
_second = new Position(offset, length);
_third  = new Position(offset, length);

The CPU runs IndexOf on the full buffer using SIMD. It doesn't inspect each byte individually — it sweeps 256 or 512 bits at a time looking for \r\n. The delimiter pattern is simple enough that the hardware can detect it at maximum throughput.

What does "marking positions" mean? It means storing an (offset, size) pair — two integers — pointing into the existing buffer. No string is created. No object is allocated. No copy happens. The data lives where it landed in the receive buffer.

// Position is just two ints
private Position _first;   // (Offset: 0, Size: 3)   → "GET"
private Position _second;  // (Offset: 4, Size: 1)   → "/"
private Position _third;   // (Offset: 6, Size: 8)   → "HTTP/1.1"

Accessing any field is a ReadOnlySpan<byte> slice — zero cost, zero allocation:

public ReadOnlySpan<byte> FirstSpan
{
    get => Cache.AsSpan(_first.Offset, _first.Size);  // span slice, no copy
}

4. Binary Protocol vs. HttpModel — The Real Comparison

Let me make this concrete.

Binary protocol, 20 fixed fields:

CPU reads field 1 at offset 0
CPU reads field 2 at offset 4
...
CPU reads field 20 at offset N
20 sequential operations, pace set by the programmer

Binary protocol, 20 pointer fields:

CPU reads pointer at offset 0, jumps to memory address X to get value
CPU reads pointer at offset 8, jumps to memory address Y to get value
...
40+ operations, many with cache misses, pipeline stalls

HttpModel, 20 headers:

CPU sweeps the entire buffer in one SIMD pass
\r\n delimiters are found; positions are marked
One fast scan, pace set by the hardware

Then the human reads:

// You asked for 3 specific headers. You jump to exactly those positions.
// You read zero-copy span slices. The other 17 headers? Never touched.
model.TryGetHeader(0, out var contentType, out var ctValue);
model.TryGetHeader(5, out var userId, out var userIdValue);
model.TryGetHeader(11, out var requestId, out var reqIdValue);

This is the key insight:

Parse is the machine's job. Read is the human's job. Don't mix them.

Binary protocol conflates the two. The programmer decides what to read, and that decision dictates how the CPU must parse. The machine works at human pace.

HttpModel separates them. The machine scans everything at full hardware speed — SIMD, no branching, no tiny offset math. The programmer then reads only what they need, from marked positions, with zero allocation.

5. Zero Allocation by Architecture

Most parsers produce objects. You send bytes in, you get a ParsedMessage struct out — with strings, arrays, boxed values, GC pressure.

HttpModel produces nothing. The parsed "result" is just a set of (offset, size) pairs sitting in the same memory as the received bytes.

// No alloc. Just two ints per token/header, pointing into Cache.
internal List<(Position, Position)> _headers = [];

// Reading is a span slice — no heap involved
public bool TryGetHeader(int i, out ReadOnlySpan<byte> key, out ReadOnlySpan<byte> value)
{
    key   = _headers[i].Item1.GetData(Cache);   // span slice
    value = _headers[i].Item2.GetData(Cache);   // span slice
    return true;
}

This is what Buffer-Model Architecture means. The buffer is the source of truth. The model is a set of rules — offsets and sizes — layered on top. No materialization. No copying. Virtualized access to the same memory region.

Even the Clone() operation is clean:

// Clone copies the cache bytes once, then shares position metadata
clone.Cache.Append(Cache.AsSpan());   // one memcpy
clone._first   = _first;              // two ints
clone._second  = _second;             // two ints
clone._headers = [.. _headers];       // list of int pairs

6. Unlimited Extensibility — The Part Binary Protocol Can Never Match

Here's the thing about a fixed binary schema: it's fixed. If you need a new field, you version the protocol, update all clients, deploy everywhere, handle backward compatibility. It's an engineering project just to add a field.

HttpModel has no schema. Adding a header is one line:

model.SetHeader("X-Game-Season"u8, "3"u8);
model.SetHeader("X-Player-Guild"u8, "ShadowBlade"u8);
model.SetHeader("X-Latency-Budget-Ms"u8, "50"u8);

These headers exist if present. If absent, they're absent. No version bump. No migration. No client update. The layout is infinitely extensible because it is not a schema — it's a pattern.

The same parser handles all of it. One function. ReceiveHeader() doesn't care how many headers you have or what they're called. It scans, marks, returns.

7. Nested Models — One Parser for Everything

Here's a capability that surprises people: HttpModel supports nesting.

The body of any HttpModel can itself contain one or more HttpModel instances. Each sub-model follows the same structure — start-line, headers, body. The body of a sub-model can contain further sub-models.

[Root Model]
  Token1: BatchRequest
  Token2: /api/game/sync
  Token3: v2
  Content-Type: multipart/model
  Model-Count: 3
  \r\n
  [Sub-Model 1]
    Hp: 80
    Atk: 120
    Def: 60
    \r\n
    [body data]
  [Sub-Model 2]
    ...
  [Sub-Model 3]
    ...

The same ReceiveHeader() / position-marking logic applies at every level. You don't write a new parser per payload type. You write one parser and reuse it recursively.

This means: one TCP connection, one buffer, one parse pass, heterogeneous payload types, multiplexed — and zero allocation on the parse side.

8. Real-World Demo: RequestModel and ResponseModel

The two most familiar instances of HttpModel are RequestModel and ResponseModel. Here's how they work in practice:

Building a request:

using var req = Lucifer.Rent<RequestModel>();

req.SetBegin("POST"u8, "/api/score/submit"u8)
   .SetHeader("X-Player-Id"u8, "player_98421"u8)
   .SetHeader("X-Season"u8, "3"u8)
   .SetBody("{\"score\":9800,\"level\":42}"u8);

// req.Cache is now the complete HTTP-formatted bytes
// ready to send over the wire — no serialization, no allocation

Building a response:

using var res = Lucifer.Rent<ResponseModel>();

res.SetBegin(200)
   .SetHeader("X-Request-Id"u8, requestId)
   .SetBody("{\"accepted\":true}"u8);

Parsing incoming bytes — the zero-alloc path:

// Incoming raw bytes land in a receive buffer
// ReceiveHeader() does one SIMD scan, marks positions, returns
bool headersDone = model.ReceiveHeader(buffer, offset, size);

// Now read only what you need — zero copy, zero alloc
var method  = model.MethodSpan;    // span slice into receive buffer
var url     = model.UrlSpan;       // span slice
var body    = model.BodySpan;      // span slice

// Need a specific header?
model.TryGetHeader(i, out var key, out var value);  // span slices

The tokens can be anything. This is what makes HttpModel general:

// For a game server session protocol:
model.SetBegin("CONNECT"u8, "room_44"u8, "GameProto/1"u8);

// For a pub/sub event stream:
model.SetBegin("PUBLISH"u8, "topic/sensor/temp"u8, "EventStream/2"u8);

// For a custom RPC:
model.SetBegin("CALL"u8, "UserService.GetProfile"u8, "RPC/1"u8);

Same model. Same parser. Same zero-alloc path. Different semantics — yours.

9. The Truth Nobody Says Out Loud: HttpModel IS a Binary Protocol

Here's the reframe that changes everything.

People draw a sharp line: "HTTP is text. Binary protocols are bytes."

That line is wrong.

HttpModel is all bytes. The receive buffer is raw bytes. The Position struct is two integers pointing into raw bytes. ReadOnlySpan<byte> accesses raw bytes. There is no string, no text, no Unicode anywhere in the hot path. HttpModel is a binary protocol.

The only difference from a "traditional" binary protocol is this:

	Traditional Binary	HttpModel
Offset	Hardcoded constant	Computed dynamically by SIMD scan
Size	Hardcoded constant	Computed dynamically by delimiter
Schema	Fixed at compile time	None — unlimited headers
Fields	N fixed fields	Infinite

Traditional binary protocol: Offset = constant. Carved into the code at design time.

HttpModel: Offset = variable. Computed by the CPU at maximum hardware speed via delimiter scanning.

Same concept. Dynamic execution. Zero schema constraint.

This is the real definition of HttpModel: a binary protocol with variable offset/size, where the CPU computes the layout at runtime instead of the programmer hardcoding it at compile time.

10. Why HTTP Got a Bad Reputation — and Who's Actually Responsible

If HttpModel is this fast and this flexible, why does everyone say HTTP is slow?

Because the world turned it into an OOP nightmare.

Look at what a standard framework does when an HTTP request arrives:

// The OOP way — what most frameworks actually do
HttpContext context = new HttpContext(request);         // heap allocation
HttpRequest req     = new HttpRequest(context);         // heap allocation
Dictionary<string, string> headers = new();             // heap allocation
foreach (var header in rawHeaders)
{
    string key   = Encoding.UTF8.GetString(keyBytes);   // heap allocation
    string value = Encoding.UTF8.GetString(valueBytes); // heap allocation
    headers[key] = value;                               // heap allocation
}
string body = await new StreamReader(req.Body).ReadToEndAsync(); // heap allocation
MyDto dto   = JsonSerializer.Deserialize<MyDto>(body);           // heap allocation

Every single line allocates on the heap. One HTTP request → dozens of objects → GC pressure → slowdown.

Then engineers benchmark this and conclude: "HTTP is slow. Binary protocol is faster."

That conclusion is comparing the wrong things. They are not comparing HTTP vs. binary protocol. They are comparing OOP HTTP vs. DOD binary protocol. The variable being changed is not the wire format — it is the programming paradigm.

Flip it. Implement the binary protocol in OOP style:

// Binary protocol, OOP style — equally slow
var message = new Message();
message.Type      = BitConverter.ToInt32(buffer, 0);
message.UserId    = BitConverter.ToInt64(buffer, 4);
message.Timestamp = BitConverter.ToInt64(buffer, 12);
message.Name      = Encoding.UTF8.GetString(buffer, 20, nameLen); // heap
// ...20 more fields, all materialized into object properties

Same allocation pattern. Same GC pressure. Same performance collapse. Because the bottleneck was never the wire format. The bottleneck was object allocation.

Now implement HttpModel in DOD style — which is exactly what LuciferCore does — and the allocation count drops to zero. No strings. No dictionaries. No objects. Just two integers per field, pointing into a buffer that already exists.

HTTP was never slow. The OOP wrapper around it was slow. Those are not the same thing.

The binary protocol community earned its performance reputation by adopting DOD early — no alloc, no copy, span-based access. HttpModel takes that same DOD discipline and applies it to a layout that is infinitely more extensible. You get the speed of DOD binary protocol. You get the freedom of an unlimited schema. You get both, simultaneously.

11. Layout Is Not Just a Frontend Concept

We talk about "layout" in UI all the time — flex, grid, constraints, templates.

Backend engineers rarely use that word. But a data layout is precisely what HttpModel provides. It's a template with named slots: three start-line tokens, N key-value pairs, a body. Your job is to fill the slots. The model handles everything else — parsing, position tracking, span access, memory management.

Frontend has layout engines. Backend has binary protocols. HttpModel brings layout thinking to the backend — and that's why it parses at machine speed.

The layout doesn't constrain you. It liberates you. You define what the three tokens mean. You define what headers exist. You define the body format. The infrastructure never changes — only the semantics you layer on top.

12. Summary: Let the Machine Do Machine Work

Binary protocols make the programmer define exactly how the CPU reads memory. This is the CPU working at human speed — structured by human decisions, capped by human granularity.

HttpModel inverts this. The CPU scans at full hardware throughput, guided only by delimiters. The programmer reads from marked positions, on demand, touching only what they need.

	OOP HTTP (frameworks)	DOD Binary Protocol	HttpModel (DOD)
Parse unit	Deserialize to object	Per field (fixed offset)	Per delimiter (SIMD scan)
Parse speed	Slow (alloc-bound)	Fast	Machine-paced
Allocation	Massive (string, dict, object)	Low	Zero by architecture
Extensibility	Limited by object model	Schema change required	Add a header, done
Nesting	Framework-dependent	Requires new parser	Recursive, one parser
Universality	HTTP semantics only	Fixed per protocol	Tokens are yours to define
Offset/Size	Object properties	Hardcoded constants	Dynamically computed at runtime

The core philosophy:

HttpModel is a binary protocol. The offset and size are not hardcoded by the programmer — they are computed by the CPU at full SIMD speed. That is the only difference. And that difference gives you infinite extensibility for free.

Parse is the CPU's job. Do it at CPU speed — all at once, no human-defined order.
Read is the programmer's job. Do it at human speed — lazily, only what you need.

Binary protocol merges these two jobs. OOP HTTP drowns both of them in allocation. HttpModel keeps them separate and lets each run at its natural speed.

Implementation

Everything described here is implemented in LuciferCore — HttpModel, RequestModel, ResponseModel, Buffer, Position, and the full Buffer-Model Architecture.

"Let the machine scan. Let the human choose."

Hot take: JWTs were never real security. Change my mind.

Thuangf45 — Tue, 17 Mar 2026 17:17:16 +0000

Thuangf45

Mar 17

Tokens Can Be Copied. Sockets Cannot. This Changes Everything.

#dotnet #performance #security #networking

10 min read

A kid with zero IT knowledge just cracked Netflix using AI. Not a joke. Here's why it worked — and the actual fix.

Thuangf45 — Tue, 17 Mar 2026 03:41:35 +0000

Thuangf45

Mar 17

Tokens Can Be Copied. Sockets Cannot. This Changes Everything.

#dotnet #performance #security #networking

10 min read

Tokens Can Be Copied. Sockets Cannot. This Changes Everything.

Thuangf45 — Tue, 17 Mar 2026 03:38:49 +0000

Most web developers today live in a world of abstractions. The Network is a black box that delivers JSON. The OS is a mysterious entity that runs their code. And when it comes to security, the industry has a "standard" answer: JWT or Cookies.

The fundamental flaw? These solutions are logic-based, not physical.

A JWT can be copied. A Cookie can be hijacked. Netflix and Disney+ spend millions fighting account sharing because a Token is just a string—it has no idea where it came from, or who is actually holding it.

LuciferCore takes a different stance: stop trusting what the client holds (a Token), and start trusting where the client stands (a physical Socket).

0. This Is Not Theory — I Watched It Happen

Before we go into the architecture, let me tell you something that shook me.

I watched a child — with zero IT knowledge — use AI to build a working web tool. Not a junior developer. Not a security researcher. A kid who couldn't tell you what HTTP stands for. The target? Netflix Premium accounts.

The tool worked by stealing the session Cookie/Token from an active browser session, manipulating it, and replaying it from a different client to unlock Premium access. No password. No brute force. Just a copied string. Within seconds, they were watching Premium content on an account that wasn't theirs.

I verified this myself. It worked.

"The only vulnerability was the token. The only defense Netflix had was 'hope nobody copies it.'"

Think about what that means. A billion-dollar security team. Hundreds of engineers. Years of iteration on auth systems. And it was bypassed in an afternoon by someone who didn't even know what a token was before that day — someone who learned everything they needed from an AI.

This isn't a sophisticated attack. There is no CVE for it. There is no patch that fixes it. It is a fundamental design flaw baked into the entire model of using a copyable string as proof of identity.

This is the moment I knew that token-based security wasn't just "imperfect" — it was the wrong mental model entirely.

1. Physical Binding: The Uncopyable Key

In a traditional web app, the server checks a Token. In LuciferCore, we bind the Identity directly to the Physical Transport Session.

When a user authenticates, SessionService maps their UserIdentity to a specific Socket ID—a File Descriptor living in the OS's memory. Not a string in a header. Not a claim in a payload. A physical pipe.

"A hacker can steal your token. They cannot steal the physical socket residing in the server's RAM."

If a stolen Session ID is replayed from a different connection, the system rejects it immediately—not because the "token" is wrong, but because the "pipe" is wrong. No RSA math. No HMAC verification. Just a Socket ID check.

The Netflix attack I described above? It would not work against SessionService. The moment the stolen cookie is used from a different physical connection, the Socket ID mismatch is detected and the session is invalidated — instantly, at the OS level, before a single byte of business logic runs.

2. Zero-Math, Zero-Allocation Authorization

Traditional JWT validation is a multi-step CPU tax:

Parse Base64
Compute HMAC/RSA Signature
Deserialize JSON
Validate claims

In LuciferCore, because we understand Data-Oriented Design (DOD) and memory layout, authorization is a single O(1) lookup in RAM:

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public bool Authorization(SessionTransport session, out ByteString userId, out UserRole role)
{
    if (!_sessions.TryGetValue(session.Id, out var entry)) return false;
    if (Lucifer.Time > entry.ExpireAt) return false;

    userId = entry.UserId;
    role = entry.Role;
    return true;
}

This executes in ~20 nanoseconds. While a JWT-based framework is still decrypting the header, LuciferCore has already finished authorization and is executing your business logic.

The speed isn't a trick — it's the natural result of trusting the OS instead of fighting it.

3. Hybrid Cleanup — Lazy on the Hot Path, Scheduled Off It

Most frameworks run a "Janitor Thread" that wakes up every second to scan and purge expired sessions — even when nothing has changed. This causes CPU Jitter, wastes energy, and worst of all, competes with your actual request traffic on the hot path.

LuciferCore's SessionService takes a different approach: two cleanup strategies working together, each in its own domain.

On the hot path — during Authentication and Authorization — cleanup is lazy and on-demand. If an identity has expired at the moment of interaction, it gets removed right then. No background scan needed for the common case.

Off the hot path — SessionService extends ServiceBase, which gives it a scheduled Update() cycle running every 6 hours. This periodic pass handles the long tail: ghost sessions from clients that disconnected silently, inactive sessions that never explicitly logged out, users whose identity expired between interactions.

protected override void Setup()
{
    Interval = TimeSpan.FromHours(6); // Scheduled maintenance — off the hot path
}

protected override void Update()
{
    Maintenance(); // Sweep expired identities and inactive sessions
    Workload = _sessions.Count; // Report current load
}

The Maintenance() sweep is also smarter than a naive expiry check. It tracks LastActiveAt per SessionEntry — so a session idle for more than 10 minutes is reclaimed automatically, even if the identity itself hasn't expired yet. Expired users are collected into a batch first, then removed after the iteration completes — avoiding the classic mistake of mutating a dictionary while walking it.

Additionally, the expiry check inside Authentication is now done inside the lock on userEntry.Sessions — eliminating the race condition where two concurrent logins could both pass the expiry check before either writes the new session.

"Lazy cleanup keeps the hot path clean. Scheduled cleanup keeps the system honest. Neither one blocks the other."

The result: zero interference with live traffic, zero stale sessions accumulating in RAM overnight, and a live Workload metric that tells you exactly how many sessions the system is carrying at any moment.

4. Forced Admin Protection — Single-Session Enforcement

The most dangerous attack vector is a compromised Admin account. LuciferCore solves this by enforcing a Physical Single-Session Policy:

if (entry.Role == UserRole.Admin)
{
    // New Admin login? Kick the old physical socket immediately.
    ForceDisconnectSessions(session, entry);

    // Reduce Admin lifespan to 2 hours for maximum security.
    entry.ExpireAt = Lucifer.Now.Ticks + TimeSpan.FromHours(2).Ticks;
}

If a hacker logs in as Admin, the real Admin gets disconnected immediately. They know something is wrong, log back in, and the hacker is physically ejected from the server. No session token to juggle. No race condition to exploit. This is Active Defense.

Compare this to the Netflix scenario: their token has a long lifespan, carries no binding to a physical connection, and can be silently replayed for hours without triggering any alarm. Two flaws, working together — a long-lived token and a session with no physical anchor — and that's all it takes.

5. Why Network & OS Knowledge Changes Everything

I built LuciferCore because I was frustrated by the gap between two worlds:

Network engineers understand packets but don't know how to structure business logic.
Application developers understand logic but don't know how a Socket File Descriptor works.

By merging these two disciplines, we stop building "black box" applications and start building hardware-optimized engines. We don't just learn to code — we learn to choreograph the hardware to serve our ideas.

Security at the physics layer isn't about being clever. It's about certainty. When you understand what the OS actually guarantees, you stop hoping your tokens are safe and start knowing your connections are bound.

That child with an AI assistant didn't find a sophisticated exploit. They found the logical conclusion of an entire industry building security on top of copyable strings. The fix isn't a better hashing algorithm or a shorter expiration window. The fix is to anchor identity to something that cannot be copied — the physical socket.

Implementation Blueprint (LuciferCore Snippets)

This demo is written in .NET / C# as a reference implementation of the concepts above. It is here for anyone who wants to study, experiment, or adapt the pattern.

One Important Thing Before You Read the Code

SessionService is authentication-method agnostic.

This is worth saying explicitly, because people often conflate "how you identify a user the first time" with "how you keep them trusted across requests." These are two completely separate problems — and LuciferCore only solves the second one.

The first handshake — figuring out who is on the other end of the connection — is your business logic. You can use whatever mechanism makes sense for your product:

A traditional username + password lookup against your database
A JWT or OAuth token from a third-party provider
A Cookie from an existing session
A hardware key, a QR code, a magic link — anything at all

SessionService doesn't care. Once you've confirmed the identity through whatever method you trust, you call Authentication(session, userId) — and from that point forward, the identity is bound to the physical socket. The token, cookie, or credential that got them in the door is no longer the source of truth. The OS-level connection is.

"Use any credential to answer 'who are you?' once. After that, the wire answers for them."

This means you can layer SessionService on top of your existing auth without replacing it — or use it as the entire security layer if you're building a socket-first system from scratch.

The Full `SessionService` Implementation

using System.Collections.Concurrent;
using System.Runtime.CompilerServices;

using LuciferCore.Main;
using LuciferCore.NetCoreServer.Transport.Core;
using LuciferCore.Pool;
using LuciferCore.Utf8;

namespace LuciferCore.Service;

/// <summary> Service responsible for managing user sessions, including authentication, authorization, and session maintenance. </summary>
internal class SessionService : ServiceBase
{
    // Active sessions keyed by Socket ID (OS File Descriptor) — the physical anchor
    private readonly ConcurrentDictionary<long, SessionEntry> _sessions = new();

    // Persistent user identity store — survives individual socket connections
    private readonly Utf8Map<UserEntry> _users = [];

    // ─── Lifecycle: Scheduled maintenance runs off the hot path ───

    protected override void Setup()
    {
        Interval = TimeSpan.FromHours(6); // Full sweep every 6 hours — no CPU jitter on live traffic
    }

    protected override void Update()
    {
        Maintenance();               // Sweep expired identities + inactive sessions
        Workload = _sessions.Count;  // Live load metric — no extra cost
    }

    // ─── Step 1: Register a user identity ───
    // Call once when the user is first created in your system.

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public bool CreateIdentity<T>(ReadOnlySpan<T> userId, out UserEntry userEntry) where T : unmanaged
    {
        userEntry = _users.GetOrAdd(userId, (uid) => new UserEntry
        {
            Role     = UserRole.User,
            ExpireAt = Lucifer.Now.Ticks + TimeSpan.FromDays(14).Ticks,
            UserId   = ByteString.CopyFrom(uid),
        });
        return true;
    }

    // ─── Step 2: Authenticate — bind a verified identity to a physical socket ───
    // Call this after YOU have verified who the user is (password, JWT, cookie, OAuth — anything).

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public bool Authentication<T>(SessionTransport session, ReadOnlySpan<T> userId) where T : unmanaged
    {
        // Clean up any stale session on this socket first
        Deauthorize(session.Id);

        // Ensure identity exists (auto-create if first login)
        CreateIdentity(userId, out var userEntry);

        var now = Lucifer.Now.Ticks;

        lock (userEntry.Sessions)
        {
            // Expiry check inside the lock — no race between check and session creation
            if (now > userEntry.ExpireAt) return false;

            // Admin single-session policy — new login physically ejects all old sockets
            if (userEntry.Role == UserRole.Admin)
            {
                RemoveSessionsUnsafe(userEntry, force: true); // already inside lock
                userEntry.ExpireAt = now + TimeSpan.FromHours(2).Ticks;
            }

            var sessionId    = session.Id;
            var sessionEntry = Lucifer.Rent<SessionEntry>();
            sessionEntry.SessionId    = sessionId;
            sessionEntry.LastActiveAt = now;
            sessionEntry.Server       = session.Server;
            sessionEntry.UserId       = userEntry.UserId;

            if (_sessions.TryAdd(sessionId, sessionEntry))
            {
                userEntry.Sessions.Add(sessionEntry);
                return true;
            }

            Lucifer.Return(sessionEntry);
            return false;
        }
    }

    // ─── Step 3: Authorize — every request checks the socket, not a token ───

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public bool Authorization(long sessionId, out ByteString userId, out UserRole role)
    {
        role   = UserRole.Guest;
        userId = default;

        if (!_sessions.TryGetValue(sessionId, out var sessionEntry)) return false;
        if (!_users.TryGetValue(sessionEntry.UserId.AsReadOnlySpan(), out var userEntry)) return false;

        var now = Lucifer.Now.Ticks;

        lock (userEntry.Sessions)
        {
            if (now <= userEntry.ExpireAt)
            {
                sessionEntry.LastActiveAt = now; // Refresh activity timestamp
                userId = sessionEntry.UserId;
                role   = userEntry.Role;
                return true;
            }
        }

        // Cleanup outside lock to avoid deadlock
        RemoveIdentity<byte>(userEntry.UserId);
        return false;
    }

    // ─── Elevation: Upgrade role mid-session (e.g. after 2FA) ───

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public bool ElevateRole(long sessionId, UserRole newRole)
    {
        if (!_sessions.TryGetValue(sessionId, out var sessionEntry)) return false;
        return ElevateRole<byte>(sessionEntry.UserId, newRole);
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public bool ElevateRole<T>(ReadOnlySpan<T> userId, UserRole newRole) where T : unmanaged
    {
        if (!_users.TryGetValue(userId, out var userEntry)) return false;
        lock (userEntry.Sessions)
        {
            userEntry.Role = newRole;
            return true;
        }
    }

    // ─── Logout ───

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public bool Deauthorize(long sessionId)
    {
        if (_sessions.TryRemove(sessionId, out var sessionEntry))
        {
            if (_users.TryGetValue(sessionEntry.UserId.AsReadOnlySpan(), out var userEntry))
                lock (userEntry.Sessions) userEntry.Sessions.Remove(sessionEntry);

            Lucifer.Return(sessionEntry);
            return true;
        }
        return false;
    }

    // ─── Remove identity and all its sessions ───

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void RemoveIdentity<T>(ReadOnlySpan<T> userId) where T : unmanaged
    {
        if (_users.TryRemove(userId, out var userEntry))
            RemoveSessions(userEntry);
    }

    // ─── Scheduled maintenance (runs every 6 hours via ServiceBase) ───
    // Collects expired users into a batch first, then removes — avoids mutating
    // the dictionary while iterating over it.

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public int Maintenance()
    {
        var now          = Lucifer.Now.Ticks;
        var removedCount = 0;

        List<ByteString>? expiredUsers = null;

        foreach (var kv in _users)
        {
            var entry = kv.Value;

            if (now > entry.ExpireAt)
            {
                // Batch expired users — don't mutate dict during iteration
                expiredUsers ??= new List<ByteString>(64);
                expiredUsers.Add(entry.UserId);
                continue;
            }

            lock (entry.Sessions)
            {
                // Reclaim sessions idle for more than 10 minutes
                for (var i = entry.Sessions.Count - 1; i >= 0; i--)
                {
                    var ss = entry.Sessions[i];
                    if (now > ss.LastActiveAt + TimeSpan.FromMinutes(10).Ticks)
                    {
                        if (RemoveSession(ss.SessionId))
                        {
                            entry.Sessions.RemoveAt(i);
                            removedCount++;
                        }
                    }
                }
            }
        }

        // Bulk remove expired identities after iteration is complete
        if (expiredUsers != null)
        {
            foreach (var uid in expiredUsers)
            {
                RemoveIdentity<byte>(uid);
                removedCount++;
            }
        }

        return removedCount;
    }

    // ─── Internals ───

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    private void RemoveSessions(UserEntry userEntry, bool force = false)
    {
        lock (userEntry.Sessions) RemoveSessionsUnsafe(userEntry, force);
    }

    // Call only when already holding userEntry.Sessions lock
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    private void RemoveSessionsUnsafe(UserEntry userEntry, bool force = false)
    {
        if (userEntry.Sessions.Count == 0) return;
        foreach (var ss in userEntry.Sessions) RemoveSession(ss.SessionId, force);
        userEntry.Sessions.Clear();
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    private bool RemoveSession(long sessionId, bool force = false)
    {
        if (_sessions.TryRemove(sessionId, out var sessionEntry))
        {
            if (force) sessionEntry.Server?.FindSession(sessionEntry.SessionId)?.Disconnect();
            Lucifer.Return(sessionEntry);
            return true;
        }
        return false;
    }

    // ─── Nested Types ───

    internal class UserEntry
    {
        public ByteString         UserId   = ByteString.Empty;
        public List<SessionEntry> Sessions = [];
        public UserRole           Role     = UserRole.Guest;
        public long               ExpireAt = 0;
    }

    internal class SessionEntry : PooledObject
    {
        public long             SessionId    = 0;
        public ByteString       UserId       = ByteString.Empty;
        public long             LastActiveAt = 0;
        public ServerTransport? Server       = null;

        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        protected internal override void Reset()
        {
            SessionId    = -1;
            LastActiveAt = -1;
            Server       = null;
            UserId       = ByteString.Empty;
        }
    }
}

public enum UserRole
{
    Guest = 0,
    User  = 1,
    Admin = 2
}

How to Wire It Into Your Auth Flow

The pattern is a clean two-step handshake. Step 1 is yours. Step 2 is SessionService's.

// ── Your login handler ──────────────────────────────────────────────────────
// Step 1: Verify identity using WHATEVER mechanism your business uses.
//         JWT, password, OAuth, cookie, magic link — SessionService doesn't care.
//         It only needs to know the answer to "who is this?" after YOU confirm it.

var userId = await _db.VerifyCredentials(username, password);
if (userId == null) return Unauthorized();

// Step 2: Hand the verified identity to SessionService.
//         From this point forward, the physical socket IS the credential.
//         Nothing is sent to the client. Nothing can be copied or replayed.

var ok = Lucifer.Sessions.Authentication(session, userId.AsSpan());
if (!ok) return Unauthorized();

// ── Every subsequent request ────────────────────────────────────────────────
// No token header. No cookie lookup. No signature verification.
// Just one question: "Is the socket this request arrived on bound to a valid identity?"

if (!Lucifer.Sessions.Authorization(session.Id, out var userId, out var role))
    return Forbidden();

// Done. Identity confirmed at the OS level in ~20 nanoseconds.

You keep your existing login logic. SessionService replaces the part that comes after — the part that was always broken.

Join the Journey

I don't invite you to use a "perfect" product. I invite you to join an evolving standard of excellence. Let’s build the fastest .NET community together, one buffer at a time.

Docs: LuciferCore
NuGet: LuciferCore on NuGet
GitHub: LuciferCore on GitHub
Author: Nguyen Minh Thuan

"Automating the infrastructure. Unleashing the logic."

From Imperfection to Extremes: The Rise of LuciferCore

Thuangf45 — Tue, 10 Mar 2026 03:21:08 +0000

Thuangf45

Mar 10

LuciferCore: A Journey of Engineering, Learning, and High‑Performance .NET

#showdev #dotnet #performance #architecture

6 min read

LuciferCore: A Journey of Engineering, Learning, and High‑Performance .NET

Thuangf45 — Tue, 10 Mar 2026 02:58:30 +0000

The Evolution of LuciferCore: Born from Imperfection, Engineered for Extremes

LuciferCore didn’t begin as a perfect framework. It began with a simple belief: great systems are not created from perfection—they are forged through continuous imperfection and relentless iteration. When the first prototype appeared in November 2025 (you can see how it looked back then here), it was rough, limited, and far from what it is today. But that early imperfection became the fuel for a journey of constant refinement.

Today, LuciferCore has evolved into a high‑performance .NET infrastructure engine—lock‑free, zero‑allocation, hardware‑saturating, and purpose‑built to eliminate the “plumbing” that slows developers down. Not because it reached perfection, but because it never stopped improving.

Why LuciferCore? The Problem of Modern Infrastructure

In the world of high-throughput systems, developers often find themselves trapped in "Plumbing." You spend 70% of your time managing socket states, fighting the Garbage Collector (GC), and agonizing over thread synchronization, leaving only 30% for the actual Business Logic.

LuciferCore changes the equation. We provide a high-performance, automated ecosystem that "occupies" the hardware, so you can focus 100% on the core logic of your idea. Whether you are building a professional game server, a high-speed security tool, or a massive event-driven system, LuciferCore handles the bytes while you handle the brainpower.

The Engineering Core: Buffer-Model & DOD

The secret to LuciferCore’s "god-tier" throughput lies in its architectural DNA:

1. Data-Oriented Design (DOD)

We shifted our focus from "Objects" to "Data Streams." By minimizing pointer chasing and memory fragmentation, we ensure that the CPU spends its time computing, not waiting for RAM.

2. Buffer-Model Architecture

This is our crown jewel. Instead of scattered allocations, we treat memory as a contiguous, virtualized pool. This ensures Democratic Cache Access, keeping data "hot" in L1/L2/L3 caches and virtually eliminating the "Memory Wall" bottleneck.

3. Hardware-Scale Parallelism

LuciferCore is Fully Asynchronous and Lock-Free. It is designed to saturate every available core of your silicon without the overhead of context switching or thread contention.

If you want to see how the ecosystem works in practice, here is the full quick‑start example used in the official repository.

🛠 Quick Start: From Zero to High-Performance in Minutes

Don't just take my word for it. Look at how LuciferCore automates the infrastructure, leaving you with pure logic.

1. Define your High-Performance Server & Static Mapping

Simply decorate your class with the [Server] attribute to initialize a specialized server instance.

[Server("ChatServer", 8443)]
public class ChatServer : WssServer
{
    /// <summary>Initializes a new instance of the ChatServer class with specified SSL context, IP address, and port.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public ChatServer(SslContext context, IPAddress address, int port) : base(context, address, port)
    {
        AddStaticContent(_staticContentPath);
        Cache.Freeze();

        Mapping = new(true)
        {
            { "/","/index.html" },
            { "/404", "/404.html" },
            { "/home", "/home.html" },
            { "/login", "/login.html" },
            { "/register", "/register.html" },
            { "/dashboard", "/dashboard.html" },
            { "/search", "/search.html" }
        };
        Mapping.Freeze();
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public ChatServer(int port) : this(CreateSslContext(), IPAddress.Any, port) { }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    protected override ChatSession CreateSession() => new(this);

    [Config("WWW", "assets/client/dev")]
    private static string _staticContentPath { get; set; } = string.Empty;

    [Config("CERTIFICATE", "assets/tools/certificates/server.pfx")]
    private static string s_certPath { get; set; } = string.Empty;

    [Config("CERT_PASSWORD", "RootCA!SecureKey@Example2025Strong")]
    private static string s_certPassword { get; set; } = string.Empty;

    /// <summary>Creates an SSL context by loading a certificate from a specified path with a password.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static SslContext CreateSslContext()
    {
#if DEBUG
        return SslContext.CreateDevelopmentContext();
#else
        var cert = X509CertificateLoader.LoadPkcs12FromFile(s_certPath, s_certPassword);
        return new(SslProtocols.Tls12, cert);
#endif
    }
}

2. Configure Session & Automatic Dispatching

Apply session-level rate limiting and Apply session-level rate limiting and automatic dispatching to handlers.

[RateLimiter(10, 1)]
public partial class ChatSession : WssSession
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public ChatSession(ChatServer server) : base(server) { }

    /// <summary>Handles incoming WebSocket binary messages by dispatching them to the Lucifer dispatcher.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    protected override void OnWsReceived(byte[] buffer, long offset, long size)
        => Lucifer.Dispatch(this, buffer, offset, size);

    /// <summary>Handles incoming HTTP requests by dispatching them to the Lucifer dispatcher.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    protected override void OnReceivedRequest(RequestModel request)
        => Lucifer.Dispatch(this, request);
}

3. Implement a Secured WebSocket and Http Handler

Use Attributes to handle messaging, security roles, and rate limiting automatically.

// WebSocket 
[Handler("v1", "wss")]
internal class WssHandler : WssHandlerBase
{
    public ConcurrentQueue<(byte[], long, long)> Messages = new();

    [WsMessage("GetMessage")]
    [Safe("")]
    [RateLimiter(10, 1)]
    [Authorize(UserRole.Guest)]
    public void GetMessage([Session] ChatSession session, [Data] PacketModel data)
    {
        foreach (var (buffer, offset, length) in Messages)
        {
            session.SendBinaryAsync(buffer.AsSpan((int)offset, (int)length));
        }
    }

    [WsMessage("ChatMessage")]
    [Safe("")]
    [RateLimiter(20, 1)]
    [Authorize(UserRole.Guest)]
    public void SendChat([Session] ChatSession session, [Data] PacketModel data)
    {
        using var _ = data;
        ((WssServer)session.Server).MulticastBinary(data.Buffer);
    }

    [WsMessage("Default")]
    [Safe("")]
    [RateLimiter(20, 1)]
    [Authorize(UserRole.Guest)]
    public void Default([Session] ChatSession session, [Data] PacketModel data)
        => throw new NotImplementedException();
}

// HTTP

[Handler("v1", "/api/user")]
internal class HttpsHandler : HttpsHandlerBase
{
    [Safe("")]
    [Authorize(UserRole.Guest)]
    [RateLimiter(100, 1)]
    [HttpHead("")]
    protected void HeadHandle([Data] RequestModel request, [Session] HttpsSession session)
        => throw new NotImplementedException();

    [Safe("")]
    [Authorize(UserRole.Guest)]
    [RateLimiter(100, 1)]
    [HttpGet("")]
    protected void GetHandle([Data] RequestModel request, [Session] HttpsSession session)
        => throw new NotImplementedException();

    [Safe("")]
    [Authorize(UserRole.Guest)]
    [RateLimiter(100, 1)]
    [HttpPost("")]
    protected void PostHandle([Data] RequestModel request, [Session] HttpsSession session)
          => throw new NotImplementedException();

    [Safe("")]
    [Authorize(UserRole.Guest)]
    [RateLimiter(100, 1)]
    [HttpPut("")]
    protected void PutHandle([Data] RequestModel request, [Session] HttpsSession session)
          => throw new NotImplementedException();

    [Safe("")]
    [Authorize(UserRole.Guest)]
    [RateLimiter(100, 1)]
    [HttpDelete("")]
    protected void DeleteHandle([Data] RequestModel request, [Session] HttpsSession session)
        => throw new NotImplementedException();

    [Safe("")]
    [Authorize(UserRole.Guest)]
    [RateLimiter(100, 1)]
    [HttpTrace("")]
    protected void TraceHandle([Data] RequestModel request, [Session] HttpsSession session)
        => throw new NotImplementedException();

    [Safe("")]
    [Authorize(UserRole.Guest)]
    [RateLimiter(100, 1)]
    [HttpOptions("")]
    protected void OptionsHandle([Data] RequestModel request, [Session] HttpsSession session)
        => throw new NotImplementedException();

}

4. Manage System Logic with Managers

Extend ManagerBase for automated background tasks and system updates.

 [Manager("MasterManager")]
 public class ManagerMaster : ManagerBase
 {
     protected override void Setup()
     {
         TimeDelay = 1000;
         ErrorDelay = 1000;
     }

     protected override void Update()
     {
         Lucifer.Log(this, "Master is running....");
     }

     protected override void Dispose(bool disposing)
     {
         base.Dispose(disposing);
     }
 }

5. The Optimized Entry Point

One line to rule them all.

In Program.cs:

using LuciferCore.Main;

// Auto-discover and start all decorated Servers/Handlers and run console host
Lucifer.Run();

This runs a console host. Extend with [ConsoleCommand] attributes for interactive commands, such as:

/start host – Start host (system)
/stop host – Stop host (system)
/restart host – Restart host (system)
/start servers – Start all servers decorated with [Server(name, port)]
/stop servers – Stop all servers decorated with [Server(name, port)]
/restart servers – Restart all servers decorated with [Server(name, port)]
/start managers – Start all managers decorated with [Manager(name)]
/stop managers – Stop all managers decorated with [Manager(name)]
/restart managers – Restart all managers decorated with [Manager(name)]

Alternatively, you can also define your own command as follows:

/// <summary>Console command to start proxy.</summary>
[ConsoleCommand("/start proxy", "Start proxy")]
[MethodImpl(MethodImplOptions.AggressiveInlining)]
private static void CmdStartProxy() => Start();

/// <summary>Console command to stop proxy.</summary>
[ConsoleCommand("/stop proxy", "Stop proxy")]
[MethodImpl(MethodImplOptions.AggressiveInlining)]
private static void CmdStopProxy() => Stop();

📦 Choosing Your Path: Performance vs. Convenience

LuciferCore is designed for extreme efficiency, which means its core APIs lean heavily on Generics and ReadOnlySpan<T>.

The Core Path: If you are a performance purist aiming for zero-allocation and full control over memory, the core framework provides everything you need to handle raw data streams with surgical precision.
The Toolkit Path: We understand that not everyone wants to fight with Span or complex generics daily. If you find the core APIs too restrictive or difficult to implement, we recommend using LuciferCore.Toolkit.

LuciferCore.Toolkit provides a collection of high-level abstractions, SIMD-accelerated helpers, and simplified wrappers that maintain high performance while offering a much smoother developer experience.

“Choose the Core for raw power. Choose the Toolkit for rapid, high-performance development.”

A Commitment to Excellence (and You)

Security threats evolve. Bottlenecks hide in plain sight. Technologies shift.

My commitment to the community is this: LuciferCore will never stagnate. I pledge to address security vulnerabilities, performance bottlenecks, or bugs within the shortest possible timeframes. This is not just a library; it is a living ecosystem that adapts to the newest .NET innovations (currently pushing the limits of .NET 9).

If it doesn't work right, we fix it. If it can be faster, we optimize it. We don't wait for perfection; we build it, one update at a time.

Join the Journey

I don't invite you to use a "perfect" product. I invite you to join an evolving standard of excellence. Let’s build the fastest .NET community together, one buffer at a time.

Docs: LuciferCore
NuGet: LuciferCore on NuGet
GitHub: LuciferCore on GitHub
Author: Nguyen Minh Thuan

"Automating the infrastructure. Unleashing the logic."

I’ve replaced POCOs with Stateless Models. Am I crazy or is this the future of #performance?

Thuangf45 — Sat, 28 Feb 2026 05:17:53 +0000

Thuangf45

Feb 26

Breaking the Memory Wall in .NET: The Buffer–Model Architecture

#dotnet #csharp #architecture #performance

9 min read

I’d love to hear how you’re approaching high-performance memory design in .NET. Feel free to share your thoughts or challenges.

Thuangf45 — Thu, 26 Feb 2026 14:37:39 +0000

Thuangf45

Feb 26

Breaking the Memory Wall in .NET: The Buffer–Model Architecture

#dotnet #csharp #architecture #performance

9 min read

Breaking the Memory Wall in .NET: The Buffer–Model Architecture

Thuangf45 — Thu, 26 Feb 2026 14:28:43 +0000

The Invisible Performance Killer: The "Memory Wall"

Modern hardware has a secret: Your CPU is a Ferrari, but your RAM is a crowded city street. The gap between CPU cycles and Memory latency is the "Memory Wall". In high-throughput systems, the fastest code isn't the one with the best algorithm—it's the one that never lets the CPU wait for RAM.

Traditional Object-Oriented Programming (OOP) hides this reality behind layers of abstraction, leading to fragmented memory, constant Cache Misses, and exhausting Garbage Collection (GC). It’s time to move toward Data-Oriented Design (DOD).

1. The "Buffer": A Physical Masterpiece

The Buffer in LuciferCore isn't just a wrapper; it's a high-performance virtualization of raw byte[]. It is designed to be the "Matter" that stays contiguous and "hot" in the CPU Cache.

Core Technical Pillars:

Integrated Hybrid Pooling: Instead of renting and returning raw byte[] thousands of times—which incurs significant overhead—the Buffer stays "attached" to its memory. It leverages a custom Object Pool for the Buffer itself and the System.Buffers.ArrayPool for the underlying bytes. This double-pooling strategy eliminates the heavy cost of frequent array allocations.
Spatial Locality & SIMD: By keeping data in a flat array, we ensure Spatial Locality. We use SIMD-accelerated copies (Vectorized Span.CopyTo, FastCopy, and Unsafe memory manipulation) to move data at the theoretical limit of the hardware.
Static Cache & Thresholds: Each Thread maintains a Static Local Cache (32 Buffers / ~8MB). This specific size is tuned to fit within the L3 Cache, ensuring that "renting" a Buffer happens in nanoseconds without any lock contention.
Smart Trimming: Buffers exceeding the MaxRetainedCapacity (e.g., 256KB) are automatically evicted to prevent Cache Pollution, keeping only the most efficient "hot" data for the CPU.

2. The "Model": Stateless Rule Engines

The Model is the "Spirit" or the "Intelligence". Unlike traditional POCOs or Classes, the LuciferCore Model is Stateless.

How it Reinvents Logic:

Zero-Field Architecture: A Model has zero fields. It only contains Methods (Rules). This means 100,000 requests can technically be processed by a single "Model" instance because the machine code stays permanently in the Instruction Cache (I-Cache).
Non-Blocking Attachment: A Model is rented from its own Object Pool, "attaches" to a Buffer to interpret its bytes, and immediately releases the Buffer once the rule is applied. This ensures that Buffers are recycled instantly across different layers of the system.
Zero-Copy Views: By using Span<byte> and ReadOnlySpan<byte>, the Model provides a "view" into the Buffer. It never copies data. If you need a String or an Integer, the Model reads it directly from the raw bytes using Bit-manipulation and MemoryMarshal.

3. Why This Is the "Final Tier" of Optimization

When you combine these two, you get a system where Data is a Stream and Logic is a Lens.

Zero GC Pressure: Since everything—the Buffer and the Model—is pooled and recycled, the Garbage Collector has nothing to do. Your RAM usage stays as a flat line, even under millions of requests per second.
Mechanical Sympathy: You aren't just writing code; you are choreographing electrons. The Buffer stays in the Data Cache, the Model stays in the Instruction Cache. The CPU execution pipeline never stalls.

Implementation Blueprint (LuciferCore Snippets)

The Lock-Free Pool Mechanism

We use [ThreadStatic] to achieve zero-lock contention for the most frequent operations.

using System.Collections.Concurrent;
using System.Runtime.CompilerServices;

namespace LuciferCore.Pool;

public static class Pool<T> where T : PooledObject, new()
{
    [ThreadStatic]
    private static Stack<T>? _localStack;

    private static readonly ConcurrentStack<T> _globalStack = new();

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static T Rent()
    {
        _localStack ??= new Stack<T>(32);

        if (_localStack.TryPop(out var obj))
        {
            obj.SetRefCount(1);
            return obj;
        }

        if (_globalStack.TryPop(out var globalObj))
        {
            globalObj.SetRefCount(1);
            return globalObj;
        }

        var newObj = new T();
        newObj.SetRefCount(1);
        return newObj;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static void Return(T obj)
    {
        if (obj == null) return;
        if (obj.DecrementRef() != 0) return;

        obj.Reset();

        _localStack ??= new Stack<T>(32);

        if (_localStack.Count < 32)
        {
            _localStack.Push(obj);
        }
        else
        {
            _globalStack.Push(obj);
        }
    }
}

The High-Performance Buffer

Notice the use of MethodImplOptions.AggressiveInlining and SIMD optimization.

using System.Buffers.Text;
using System.Diagnostics;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.Text;
using LuciferCore.Core;
using LuciferCore.Main;
using LuciferCore.Pool;

namespace LuciferCore.Storage;

public class Buffer : PooledObject, IDisposable
{
    #region Constructors
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Buffer() => Attach();

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Buffer(long capacity) => Attach(capacity);

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Buffer(byte[] data) => Attach(data);

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Buffer(byte[] data, long offset) => Attach(data, offset);

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Buffer(byte[] data, long size, long offset) => Attach(data, size, offset);

    #endregion

    #region Private fields and constants

    private byte[] _data = Array.Empty<byte>();
    private long _size;
    private long _offset;

    public const long MaxBufferCapacity = int.MaxValue; // 2,147,483,647 bytes

    private const int DefaultCapacity = 256;
    private const int MaxRetainedCapacity = 1024 * 256;

    #endregion

    #region Public properties

    public bool IsEmpty => _data == null || _size == 0;
    public bool IsValid => _data != null && _size >= 0 && _offset >= 0 && _offset <= _size && _size <= _data.Length;

    public byte[] Data => _data;
    public long Capacity => _data.Length;
    public long Size => _size;
    public long Offset => _offset;
    public static long MaxSupportedCapacity => MaxBufferCapacity;

    public byte this[long index]
    {
        get
        {
            ValidateIndex(index, nameof(index));
            return _data[index];
        }
    }

    public byte[] this[Range range]
    {
        get
        {
            var (offset, length) = range.GetOffsetAndLength(_data.Length);

            ValidateRange(offset, length);
            return _data.AsSpan(offset, length).ToArray();
        }
    }

    #endregion

    #region Memory buffer methods
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Span<byte> AsSpan()
    {
        Debug.Assert(_size - _offset <= int.MaxValue, "Span size exceeds int.MaxValue");
        return new Span<byte>(_data, SafeToInt32(_offset), SafeToInt32(_size - _offset));
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Span<byte> AsSpan(long start, long length)
    {
        Debug.Assert(start >= 0 && length >= 0, "Invalid slice parameters");
        Debug.Assert(start + length <= _size, "Invalid slice range!");

        if (start < 0 || length < 0)
            throw new ArgumentOutOfRangeException("Start and length must be non-negative");

        if (start + length > _size)
            throw new ArgumentException("Invalid slice range!", nameof(start));

        return new Span<byte>(_data, SafeToInt32(start), SafeToInt32(length));
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Memory<byte> AsMemory()
    {
        var start = SafeToInt32(_offset);
        var length = SafeToInt32(_size - _offset);

        return new Memory<byte>(_data, start, length);
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public Memory<byte> AsMemory(long start, long length)
    {
        return new Memory<byte>(_data, SafeToInt32(start), SafeToInt32(length));
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public ArraySegment<byte> AsSegment()
    {
        return new ArraySegment<byte>(_data, SafeToInt32(_offset), SafeToInt32(_size - _offset));
    }

    public ReadOnlySpan<byte> Slice(long start, long length)
    {
        Debug.Assert(start >= 0 && length >= 0, "Invalid slice parameters");
        Debug.Assert(start + length <= _size, "Invalid slice range!");

        if (start < 0 || length < 0)
            throw new ArgumentOutOfRangeException("Start and length must be non-negative");

        if (start + length > _size)
            throw new ArgumentException("Invalid slice range!", nameof(start));

        return new ReadOnlySpan<byte>(_data, SafeToInt32(start), SafeToInt32(length));
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public override string ToString() => ExtractString(0, SafeToInt32(_size));

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public string ExtractString(long offset, long size)
    {
        Debug.Assert(offset >= 0 && size >= 0, "Invalid parameters");
        Debug.Assert(offset + size <= _size, "Invalid offset & size!");

        if (offset < 0 || size < 0)
            throw new ArgumentOutOfRangeException("Offset and size must be non-negative");

        if (offset + size > _size)
            throw new ArgumentException("Invalid offset & size!", nameof(offset));

        return Encoding.UTF8.GetString(_data, SafeToInt32(offset), SafeToInt32(size));
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Remove(long offset, long size)
    {
        Debug.Assert(offset >= 0 && size >= 0, "Invalid parameters");
        Debug.Assert(offset + size <= _size, "Invalid offset & size!");

        if (offset < 0 || size < 0)
            throw new ArgumentOutOfRangeException("Offset and size must be non-negative");

        if (offset + size > _size)
            throw new ArgumentException("Invalid offset & size!", nameof(offset));

        var remaining = _size - offset - size;
        if (remaining > 0)
        {
            // Same array, overlapping → use safe Copy()
            FastCopy.Copy(
                _data.AsSpan(SafeToInt32(offset + size), SafeToInt32(remaining)),
                _data.AsSpan(SafeToInt32(offset))
            );
        }

        _size -= size;

        if (_offset >= offset + size)
            _offset -= size;
        else if (_offset >= offset)
            _offset = offset;
    }


    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Reserve(long capacity)
    {
        ValidateCapacity(capacity, nameof(capacity));

        if (capacity > Capacity)
        {
            var newCapacity = Math.Max(capacity, Math.Min(2L * Capacity, MaxBufferCapacity));
            var newData = Lucifer.Rent(SafeToInt32(newCapacity));

            // Copy all used data [0, _size)
            if (_size > 0)
            {
                // Different arrays → no overlap
                FastCopy.CopySimd(
                    _data.AsSpan(0, SafeToInt32(_size)),
                    newData.AsSpan(0, SafeToInt32(_size))
                );
            }

            if (_data != null && _data.Length != 0)
                Lucifer.Return(_data);

            _data = newData;
        }
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Resize(long size)
    {
        ValidateCapacity(size, nameof(size));

        Reserve(size);
        _size = size;

        if (_offset > _size)
            _offset = _size;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Shift(long offset)
    {
        var newOffset = _offset + offset;

        Debug.Assert(newOffset >= 0 && newOffset <= _size, "Invalid shift");

        if (newOffset < 0 || newOffset > _size)
            throw new ArgumentOutOfRangeException(nameof(offset),
                $"Shift would move offset to {newOffset}, valid range is [0, {_size}]");

        _offset = newOffset;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Unshift(long offset)
    {
        var newOffset = _offset - offset;

        Debug.Assert(newOffset >= 0, "Unshift would create negative offset");

        if (newOffset < 0)
            throw new ArgumentOutOfRangeException(nameof(offset),
                "Unshift would create negative offset");

        _offset = newOffset;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    protected internal override void Reset()
    {
        if (_data != null && _data.Length > MaxRetainedCapacity)
        {
            Detach();
            _data = Lucifer.Rent(DefaultCapacity);
        }

        _size = 0;
        _offset = 0;
    }

    public void Dispose()
    {
        Lucifer.Return(this);
    }

    #endregion

    #region Attach/Detach methods

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    private void Detach()
    {
        if (_data != null && _data.Length != 0)
            Lucifer.Return(_data);

        _data = Array.Empty<byte>();
        _size = 0;
        _offset = 0;
    }


    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Attach() { Detach(); }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Attach(long capacity)
    {
        ValidateCapacity(capacity, nameof(capacity));
        Detach();
        _data = Lucifer.Rent(SafeToInt32(capacity));
        _size = 0;
        _offset = 0;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Attach(byte[] buffer)
    {
        if (buffer == null)
            throw new ArgumentNullException(nameof(buffer));

        Detach();
        _data = buffer;
        _size = buffer.Length;
        _offset = 0;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Attach(byte[] buffer, long offset)
    {
        if (buffer == null)
            throw new ArgumentNullException(nameof(buffer));

        ValidateOffset(offset, buffer.Length, nameof(offset));

        Detach();
        _data = buffer;
        _size = buffer.Length;
        _offset = offset;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Attach(byte[] buffer, long size, long offset)
    {
        if (buffer == null)
            throw new ArgumentNullException(nameof(buffer));

        ValidateSize(size, buffer.Length, nameof(size));
        ValidateOffset(offset, size, nameof(offset));

        Detach();
        _data = buffer;
        _size = size;
        _offset = offset;
    }

    #endregion

    #region Buffer I/O methods

    #region Append binary basic overloads
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public long Append(byte[] buffer) => Append(buffer.AsSpan(0, buffer.Length));

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public long Append(byte[] buffer, long offset, long size) => Append(buffer.AsSpan(SafeToInt32(offset), SafeToInt32(size)));

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public long Append(Buffer buffer) => Append(buffer.AsSpan());

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public long Append(string text) => Append(text.AsSpan());

    #endregion

    #region Append binary number overloads
    ...
    #endregion

    #region Read binary number overloads
    ...
    #endregion

    #endregion    

    #region Validation helpers
    ...
    #endregion
}

The Stateless Packet Model

The rule engine that attaches to the buffer without overhead.

using System.Buffers.Binary;
using System.Runtime.CompilerServices;
using System.Text.Json;
using LuciferCore.Main;
using LuciferCore.Pool;
using LuciferCore.Utf8;

namespace LuciferCore.Model;

/// <summary>Zero-copy packet wrapper with URL and body.</summary>
public class PacketModel : PooledObject
{
    /// <summary>Attached buffer for packet data.</summary>
    public Buffer? Buffer { get; private set; }

    /// <summary>Packet magic constant.</summary>
    public const int MAGIC = 0x4643554C;
    /// <summary>Default URL when invalid.</summary>
    public static ByteString UrlDefault = ByteString.CopyFromAscii("/v1/wss/Default"u8);
    /// <summary>Magic header length.</summary>
    public const int MagicLength = 4;
    /// <summary>URL length field size.</summary>
    public const int UrlLengthFieldSize = 4;
    /// <summary>URL offset in packet.</summary>
    public const int UrlOffset = MagicLength + UrlLengthFieldSize; // = 8

    /// <summary>Checks whether packet header is valid.</summary>
    public bool IsValid
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        get
        {
            if (Buffer == null || Buffer.Size < UrlOffset) return false;

            var span = Buffer.AsSpan();

            if (BinaryPrimitives.ReadInt32LittleEndian(span) != MAGIC) return false;

            var urlLen = BinaryPrimitives.ReadInt32LittleEndian(span.Slice(4));

            return urlLen >= 0 && (UrlOffset + urlLen <= Buffer.Size);
        }
    }

    /// <summary>Gets raw URL length from header.</summary>
    private int UrlLengthRaw
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        get
        {
            if (Buffer == null || Buffer.Size < UrlOffset) return 0;

            return BinaryPrimitives.ReadInt32LittleEndian(Buffer.Data.AsSpan((int)(Buffer.Offset + 4), 4));
        }
    }

    /// <summary>Gets URL as ByteString view.</summary>
    public ByteString UrlView
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        get
        {
            if (Buffer == null || !IsValid) return PacketModel.UrlDefault;

            var len = UrlLengthRaw;
            return len <= 0
                ? ByteString.Empty
                : new ByteString(Buffer.Data, (int)(Buffer.Offset + UrlOffset), len);
        }
    }

    /// <summary>Gets body span.</summary>
    public ReadOnlySpan<byte> Body
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        get
        {
            if (Buffer == null) return ReadOnlySpan<byte>.Empty;

            if (!IsValid) return Buffer.AsSpan();

            var urlLen = UrlLengthRaw;
            var bodyOffset = UrlOffset + urlLen;

            return Buffer.Data.AsSpan((int)(Buffer.Offset + bodyOffset), (int)(Buffer.Size - bodyOffset));
        }
    }

    /// <summary>Cached deserialized body.</summary>
    private object? _cachedBody;
    /// <summary>Whether body cache is set.</summary>
    private bool _bodyCached;

    /// <summary>Deserializes body as type T.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public T? BodyAs<T>() where T : class
    {
        if (_bodyCached && _cachedBody is T cached) return cached;

        var bodySpan = Body;
        if (bodySpan.IsEmpty) return null;

        var result = Lucifer.DeserializeFromBuffer<T>(bodySpan);
        _cachedBody = result!;
        _bodyCached = true;
        return result;
    }

    public static Buffer ToBufferWithMagic(byte[] buffer, long offset, long size, ByteString url)
        => ToBufferWithMagic(buffer.AsSpan((int)offset, (int)size), url);

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static Buffer ToBufferWithMagic(ReadOnlySpan<char> buffer, ByteString url)
    {
        var buf = Lucifer.Rent<Buffer>();
        buf.Reset();

        // 1. MAGIC
        buf.Append(PacketModel.MAGIC);
        // 2. UrlLength
        buf.Append(url.Length);
        // 3. Url bytes
        buf.Append(url.AsSpan());
        // 4. Body bytes
        buf.Append(buffer);
        return buf;
    }

    /// <summary>Builds packet buffer from byte span.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static Buffer ToBufferWithMagic(ReadOnlySpan<byte> buffer, ByteString url)
    {
        var buf = Lucifer.Rent<Buffer>();
        buf.Reset();

        // 1. MAGIC
        buf.Append(PacketModel.MAGIC);
        // 2. UrlLength
        buf.Append(url.Length);
        // 3. Url bytes
        buf.Append(url.AsSpan());
        // 4. Body bytes
        buf.Append(buffer);
        return buf;
    }

    /// <summary>Converts object to byte array.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static byte[] GetBytes(object data)
        => data switch
        {
            byte[] bytes => bytes,
            null => Array.Empty<byte>(),
            _ => JsonSerializer.SerializeToUtf8Bytes(data)
        };

    /// <summary>Attaches buffer and clears cache.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Attach(Buffer newBuffer)
    {
        if (Buffer != null && Buffer != newBuffer) Lucifer.Return(Buffer);

        Buffer = newBuffer;
        _cachedBody = null;
        _bodyCached = false;
    }

    /// <summary>Returns buffer to pool and clears cache.</summary>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    protected internal override void Reset()
    {
        if (Buffer != null)
        {
            Lucifer.Return(Buffer);
            Buffer = null;
        }
        _cachedBody = null;
        _bodyCached = false;
    }
}

Final Thoughts & Contribution

The Buffer-Model architecture is the core philosophy of LuciferCore. It bridges the gap between high-level C# productivity and low-level C++ performance. By moving from "Object-thinking" to "Data-thinking," we can build backends that are prepared for the next decade of hardware evolution.

Author & Copyright

This architecture and the LuciferCore framework are authored by Nguyễn Minh Thuận (thuangf45).

License Notice

The LuciferCore framework and all code snippets in this article are licensed under the MIT License (see GitHub repository for full text).

Copyright © 2026 Nguyễn Minh Thuận (thuangf45).

Feedback & Collaboration

This is my biggest passion project. I believe this DOD framework can become a new standard for high-performance .NET development. I am eager to hear your technical critiques, contributions, or suggestions to push this even further.

GitHub: https://github.com/thuangf45
Contact: kingnemacc@gmail.com

Thank you for reading and for your interest in extreme performance!

Introducing LuciferCore: A High-Performance .NET Server Framework with CLI Support

Thuangf45 — Sun, 02 Nov 2025 05:55:22 +0000

If you're building server-side applications in .NET and want a framework that’s fast, flexible, and developer-friendly — meet LuciferCore.

LuciferCore is a powerful .NET library designed for building high-performance servers, managing sessions, and streamlining development workflows. Paired with Lucifer.CLI, it offers a complete toolkit for bootstrapping and managing your projects with ease.

What Is LuciferCore?
LuciferCore is built for developers who want:

Fast and reliable server setup
Session management out of the box.
A clean CLI to scaffold templates and manage resources.
Simple integration with dotnet workflows.

Whether you're building a console-based host or a scalable backend service, LuciferCore gives you the tools to get started quickly — and stay productive.

Quick Installation
Install the core library:

dotnet add package LuciferCore

Install the CLI globally:

dotnet tool install --global Lucifer.CLI

CLI Commands You’ll Actually Use
Initialize your project:

lucifer init

Generate templates:

lucifer create Server
lucifer create Session
lucifer create Handler

Update all components:

lucifer update --all

Clear generated files:

lucifer clear --all

Quick Example
Run a basic server:

using LuciferCore.Main;
using static LuciferCore.Core.Simulation;

GetModel<HostServer>().Run();

Define interactive console commands:

[ConsoleCommand("/start host", "Start host")].
[ConsoleCommand("/stop host", "Stop host")].
[ConsoleCommand("/restart host", "Restart host")].
[ConsoleCommand("/start service", "Start services")].
[ConsoleCommand("/stop service", "Stop services")].
[ConsoleCommand("/restart service", "Restart services")].

Then run your app:

dotnet run

NuGet Packages

Final Thought
"It doesn't matter who you are — believe in who you are." LuciferCore is built on that spirit. Try it out, and let me know what you think.

A Personal Note
This is my very first product — built with limited experience and a lot of learning along the way. I know it’s not perfect, and there may be flaws in the source code. But I truly hope you’ll give it a try, contribute, and interact with me so I can improve it and grow as a developer.
Your feedback means everything.

Contact
If you'd like to contribute, report issues, or just say hi — feel free to reach out:

DEV Community: Thuangf45

I Got Tired of Maintaining Frontend Code. So I Built a Declarative UI Runtime.

Where I came from

What a growing frontend project actually costs you

The realization

Why JSON

Designing the vocabulary

The action DSL

Two files, then one

The first real feedback

What this means for working with AI tools

Making it fast: an optimization story

What building with LuciaCore looks like today

Where it stands, and why I built it this way

LuciferCore: The Redemption Arc — From a Naive Prototype to a Battle-Tested .NET Framework

The Journey: Three Versions, Three Lessons

November 2025: The First Step

March 2026: The Slap in the Face

Today: The Serious Return

What Makes LuciferCore Different Now?

Cold, Hard Data: The Benchmarks

Production Ready & Commercial Growth

1. Excellent Documentation

2. Dual Licensing

Connect and Support

Stop Thinking of HTTP as Request/Response. It's a Universal Data Layout — and It's Faster Than Binary Protocol.

0. The Mental Model That's Costing You Performance

1. How Your CPU Actually Reads Data

2. What HttpModel Does Instead

3. The Parse That Runs at Machine Speed

4. Binary Protocol vs. HttpModel — The Real Comparison

5. Zero Allocation by Architecture

6. Unlimited Extensibility — The Part Binary Protocol Can Never Match

7. Nested Models — One Parser for Everything

8. Real-World Demo: RequestModel and ResponseModel

9. The Truth Nobody Says Out Loud: HttpModel IS a Binary Protocol

10. Why HTTP Got a Bad Reputation — and Who's Actually Responsible

11. Layout Is Not Just a Frontend Concept

12. Summary: Let the Machine Do Machine Work

Implementation

Hot take: JWTs were never real security. Change my mind.

Tokens Can Be Copied. Sockets Cannot. This Changes Everything.

A kid with zero IT knowledge just cracked Netflix using AI. Not a joke. Here's why it worked — and the actual fix.

Tokens Can Be Copied. Sockets Cannot. This Changes Everything.

Tokens Can Be Copied. Sockets Cannot. This Changes Everything.

0. This Is Not Theory — I Watched It Happen

1. Physical Binding: The Uncopyable Key

2. Zero-Math, Zero-Allocation Authorization

3. Hybrid Cleanup — Lazy on the Hot Path, Scheduled Off It

4. Forced Admin Protection — Single-Session Enforcement

5. Why Network & OS Knowledge Changes Everything

Implementation Blueprint (LuciferCore Snippets)

One Important Thing Before You Read the Code

The Full SessionService Implementation

How to Wire It Into Your Auth Flow

Join the Journey

From Imperfection to Extremes: The Rise of LuciferCore

LuciferCore: A Journey of Engineering, Learning, and High‑Performance .NET

LuciferCore: A Journey of Engineering, Learning, and High‑Performance .NET

The Evolution of LuciferCore: Born from Imperfection, Engineered for Extremes

Why LuciferCore? The Problem of Modern Infrastructure

The Engineering Core: Buffer-Model & DOD

1. Data-Oriented Design (DOD)

2. Buffer-Model Architecture

3. Hardware-Scale Parallelism

🛠 Quick Start: From Zero to High-Performance in Minutes

1. Define your High-Performance Server & Static Mapping

2. Configure Session & Automatic Dispatching

3. Implement a Secured WebSocket and Http Handler

4. Manage System Logic with Managers

5. The Optimized Entry Point

📦 Choosing Your Path: Performance vs. Convenience

A Commitment to Excellence (and You)

Join the Journey

I’ve replaced POCOs with Stateless Models. Am I crazy or is this the future of #performance?

Breaking the Memory Wall in .NET: The Buffer–Model Architecture

I’d love to hear how you’re approaching high-performance memory design in .NET. Feel free to share your thoughts or challenges.

Breaking the Memory Wall in .NET: The Buffer–Model Architecture

Breaking the Memory Wall in .NET: The Buffer–Model Architecture

The Invisible Performance Killer: The "Memory Wall"

The Full `SessionService` Implementation