Understanding DHT: Onboarding at a Microsoft Without a Central Directory

You've just joined Microsoft in a parallel universe, where your role is to procure hard drives for the Microsoft 365 data centers.

On your first day, you receive three task tickets: contact the engineer responsible for memory management at Xbox, reach out to the sales representative for Silverlight, and get in touch with the colleague in charge of power supply for the server room air conditioning. Each ticket includes the recipient's employee ID but no phone number.

You open the company directory and find it completely empty.

HR explains that this company has no central directory, no managers dedicated to forwarding messages through the hierarchy, and no permission to send mass emails to the entire company. Each employee maintains only a small personal contact list. How tens of thousands of employees find each other is an onboarding skill every employee is expected to master.

"So I need to know everyone in the company?"

"No. Knowing around a hundred people should be enough."

"And then I can find a completely unfamiliar Xbox engineer?"

"Yes, as long as the company's communication network is well-maintained."

The story illustrates DHT—Distributed Hash Table. More precisely, we are focusing on the Kademlia-style structure used in the BitTorrent mainline DHT: each participant knows only a small number of other participants, yet together they can perform lookups in a massive directory. Not all DHTs use the same algorithm; this article discusses only this one.(BitTorrent)

Now, before diving into the protocol, let's go get our employee badges.

1. This Company's Business Is Entirely Defined in Numbers

Cyber Microsoft has a peculiar habit: every business unit must have a binary address.

Binary is not mysterious. Stand at a fork in the road: take the left path and record a 0; take the right path and record a 1. Make six consecutive choices, and you can select one of sixty-four positions in a complete binary tree.

We have expanded our major product lines—Windows, Xbox, Azure, Microsoft 365, and others—into sixty-four representative business entry points. The names of products, services, and features come from real Microsoft offerings, but the groupings and numbering below are designed for the story. They do not represent Microsoft’s actual organizational structure, nor are they an official “Top 64 Businesses” ranking. Product names can be found in Microsoft’s product catalog, Azure product pages, and game catalogs. (Microsoft)

We have also deliberately retained Silverlight, a legacy business. In the real world, Silverlight reached end of support in 2021; in our parallel world, it still maintains a temporary counter so that later parts of the story have a place to unfold. (Microsoft Learn)

Below is the company’s business address tree. Each fork has only two paths, and the six-digit numbered business entry points total exactly sixty-four.

赛博微软
├── 0 终端、游戏与技术平台
│   ├── 00 个人计算与游戏
│   │   ├── 000 Windows 与终端
│   │   │   ├── 0000 系统与设备
│   │   │   │   ├── 00000 操作系统
│   │   │   │   │   ├── 000000 Windows 客户端
│   │   │   │   │   └── 000001 Windows Server
│   │   │   │   └── 00001 硬件与浏览器
│   │   │   │       ├── 000010 Surface
│   │   │   │       └── 000011 Microsoft Edge
│   │   │   └── 0001 终端管理与安全
│   │   │       ├── 00010 部署与管理
│   │   │       │   ├── 000100 Windows 365
│   │   │       │   └── 000101 Microsoft Intune
│   │   │       └── 00011 终端防护
│   │   │           ├── 000110 Defender for Endpoint
│   │   │           └── 000111 BitLocker
│   │   └── 001 Xbox 与游戏
│   │       ├── 0010 游戏平台与跨端体验
│   │       │   ├── 00100 主机与订阅
│   │       │   │   ├── 001000 Xbox 主机与系统
│   │       │   │   └── 001001 Xbox Game Pass
│   │       │   └── 00101 跨端游戏
│   │       │       ├── 001010 Xbox 云游戏
│   │       │       └── 001011 Minecraft
│   │       └── 0011 游戏内容
│   │           ├── 00110 动作与竞速
│   │           │   ├── 001100 光环
│   │           │   └── 001101 极限竞速
│   │           └── 00111 策略与模拟
│   │               ├── 001110 帝国时代
│   │               └── 001111 微软模拟飞行
│   └── 01 开发与企业技术
│       ├── 010 开发工具与框架
│       │   ├── 0100 编程工具与代码协作
│       │   │   ├── 01000 开发环境
│       │   │   │   ├── 010000 Visual Studio
│       │   │   │   └── 010001 Visual Studio Code
│       │   │   └── 01001 代码协作
│       │   │       ├── 010010 GitHub
│       │   │       └── 010011 GitHub Copilot
│       │   └── 0101 应用开发框架
│       │       ├── 01010 通用与网站框架
│       │       │   ├── 010100 .NET
│       │       │   └── 010101 ASP.NET Core
│       │       └── 01011 桌面与历史框架
│       │           ├── 010110 WPF
│       │           └── 010111 Silverlight
│       └── 011 工程、数据与安全
│           ├── 0110 工程效率与数据
│           │   ├── 01100 开发运维
│           │   │   ├── 011000 Azure DevOps
│           │   │   └── 011001 PowerShell
│           │   └── 01101 数据平台
│           │       ├── 011010 SQL Server
│           │       └── 011011 Microsoft Fabric
│           └── 0111 身份与安全
│               ├── 01110 身份与治理
│               │   ├── 011100 Microsoft Entra
│               │   └── 011101 Microsoft Purview
│               └── 01111 威胁防护
│                   ├── 011110 Microsoft Sentinel
│                   └── 011111 Defender for Cloud
└── 1 云与在线业务
    ├── 10 公共云与互联网
    │   ├── 100 Azure
    │   │   ├── 1000 计算与应用托管
    │   │   │   ├── 10000 虚拟机与容器
    │   │   │   │   ├── 100000 Azure 虚拟机
    │   │   │   │   └── 100001 Azure Kubernetes 服务
    │   │   │   └── 10001 应用与函数
    │   │   │       ├── 100010 Azure App Service
    │   │   │       └── 100011 Azure Functions
    │   │   └── 1001 存储、数据与网络
    │   │       ├── 10010 存储与关系数据
    │   │       │   ├── 100100 Azure Blob 存储
    │   │       │   └── 100101 Azure SQL 数据库
    │   │       └── 10011 分布式数据与网络
    │   │           ├── 100110 Azure Cosmos DB
    │   │           └── 100111 Azure 虚拟网络
    │   └── 101 Bing 与互联网服务
    │       ├── 1010 搜索与人工智能
    │       │   ├── 10100 搜索与广告
    │       │   │   ├── 101000 Bing 搜索
    │       │   │   └── 101001 微软广告
    │       │   └── 10101 助手与设计
    │       │       ├── 101010 Microsoft Copilot
    │       │       └── 101011 Microsoft Designer
    │       └── 1011 资讯与职业服务
    │           ├── 10110 资讯与翻译
    │           │   ├── 101100 MSN
    │           │   └── 101101 微软翻译
    │           └── 10111 职业网络与学习
    │               ├── 101110 LinkedIn
    │               └── 101111 LinkedIn Learning
    └── 11 办公与企业应用
        ├── 110 Microsoft 365
        │   ├── 1100 内容创作
        │   │   ├── 11000 文字与表格
        │   │   │   ├── 110000 Word
        │   │   │   └── 110001 Excel
        │   │   └── 11001 演示与笔记
        │   │       ├── 110010 PowerPoint
        │   │       └── 110011 OneNote
        │   └── 1101 沟通与协作
        │   │   ├── 11010 邮件与会议
        │   │   │   ├── 110100 Outlook / Exchange
        │   │   │   └── 110101 Teams
        │   │   └── 11011 站点与文件
        │   │       ├── 110110 SharePoint
        │   │       └── 110111 OneDrive
        └── 111 Dynamics 与 Power Platform
            ├── 1110 业务管理
            │   ├── 11100 销售与服务
            │   │   ├── 111000 Dynamics 365 Sales
            │   │   └── 111001 Dynamics 365 Customer Service
            │   └── 11101 财务与供应链
            │       ├── 111010 Dynamics 365 Finance
            │       └── 111011 Dynamics 365 Supply Chain Management
            └── 1111 低代码与分析
                ├── 11110 应用与自动化
                │   ├── 111100 Power Apps
                │   └── 111101 Power Automate
                └── 11111 分析与智能体
                    ├── 111110 Power BI
                    └── 111111 Copilot Studio

The last few groups involving identity, security, enterprise applications, and low-code business also have corresponding official Microsoft product documentation; here we are only borrowing their names. The role assignments below remain entirely part of the fictional setting. (Microsoft Learn)

Although this diagram is long, the rule is simple: each step down adds one more digit to the identifier and narrows the scope by one level.

There is another particularly important point: 100 is merely the name of this Azure region; there is no “Azure General Manager” with a three-digit employee ID. The intermediate branches in the tree are categories, not real people.

Real people are further down.

2. Your Employee ID: A Total of 16 Digits

Under each six-digit business address, add the department, responsibilities, and specific seats. To ensure all employees are at the same level, we have standardized employee IDs to be sixteen digits long:

六位业务地址 + 两位部门类别 + 四位具体职责 + 四位席位编号

For example, OneDrive's business address is 110111. It continues to split in half:

110111 OneDrive
├── 1101110 技术建设
│   ├── 11011100 研发
│   └── 11011101 测试
└── 1101111 业务运行
    ├── 11011110 商务与客户
    └── 11011111 运维与保障

The four digits beneath the department further distinguish specific responsibilities. For example, within Operations and Support, we have agreed that 1010 stands for hard disk procurement, 1011 for storage maintenance, 1100 for server power supply, and 1101 for air conditioning power supply. The final four digits distinguish different seats within the same responsibility.

Therefore, the badge you receive is:

110111 11 1010 0001

HR reads the badge aloud: “OneDrive, Operations and Support, Hard Disk Procurement, Seat Number One. Welcome to Microsoft. Your job is to provide others with a place to save their files, but first, you need a place to save your phone numbers yourself.”

Subsequently, several colleagues from the story make their appearances one by one:

At this point, we have untangled an easily confused issue: the employee ID specifies "which address to look up," while the phone number explains "how to contact that location."

Knowing Lao Chen's full employee ID does not mean you already know his phone number. Just because everyone understands how this address scheme is structured does not mean everyone has access to the employee directory. The address scheme can be entirely public, yet the contact details of actual people remain scattered across each individual's personal address book.

A sixteen-bit identifier can accommodate at most 65,536 distinct employee IDs, so this is a scaled-down educational model. Positions and seats under a business unit may be vacant; there is no need to fill every node in the hierarchy. All real individuals occupy leaf-level positions within the sixteen-bit address space; no one automatically becomes a superior simply by occupying an intermediate node in the tree.

3. Company Bylaws: Your Contact List Can't Be All Meal Buddies

HR then handed you a copy of the company bylaws.

It contains no complex management jargon; the core requirement is:

Starting from your own employee ID, trace up the address tree. At every branching point, you must save the contact numbers of a few people on the "other side." If there are people on that side, there should be contacts; if there are few people, try to record all of them; if there are many, keep a small batch of reliable ones.

This statement is the key to the entire company's operation.

You belong to 110111…, so from your perspective, the company can be broken down into the following segments:

These cells were not chosen at random. Each one represents a different path you might have taken when heading to your workstation—a detour you didn't actually follow.

This also explains the precise meaning of "coarse far away, fine up close": a large area far away shares a single contact cell; near you, the same physical range is divided into more cells. It is not that each nearby cell must hold more people, but that the closer you get, the finer the categorization becomes.

For convenience, the story stipulates that each cell holds a maximum of eight people. Under the sixteen-bit model, this division yields at most sixteen cells, and eight times sixteen gives a loose upper limit of 128 people. Small cells close to you may not even fill up to eight, so the actual number is often lower. "Around a hundred people" is a reasonable scale, not a fixed number everyone must memorize.

There is also a simpler aspect here than one might imagine: you do not even need to individually know eight Azure employees and eight Bing employees. You just need to know a small group of people in the entire 10… region. When you reach them, they will further subdivide that area for you.

Similarly, the people you know in the 0… cell can temporarily all be Windows employees. You can still likely find Xbox through them.

Therefore, the company charter is not "know a few people from every product," but "know a few people on the other side at each relevant branch of the address tree." This is far less effort than making friends with every product individually.

4. What to Do on Day One When You Don't Know Anyone?

You look up and ask HR: “I understand the bylaws, but my contact list is currently empty. Who should I call first?”

HR hands you their business card: “Call me first.”

This is the bootstrap node, the role we have consistently referred to as “HR.” Its purpose is not to hold the contact information for the entire company, but to provide the initial entry point for a newcomer who knows absolutely no one. In the real world, DHT bootstrap services also introduce a few known, available nodes to newcomers. (LibTorrent Blog)

You first state your employee ID, and ask HR to introduce you to a few veteran employees whose IDs are numerically close to yours. The people they introduce you to might work on Teams, or perhaps on OneDrive. You then reach out to them, asking them to introduce you to people with IDs even closer to yours.

You have first established a foothold in your immediate vicinity.

Next, you begin filling in the areas where you still lack contacts. For example, if you have no contacts in the 0… range, you pick a target address within that range and send a lookup request to a veteran employee you already know. That veteran introduces some people, who in turn introduce others, and you gradually acquire contact information for that side of the network.

The newcomer borrows the navigation capabilities of the existing network, rather than having to know the entire company on their own first.

These calls also serve a dual purpose: you receive other people’s business cards, and the people who receive your calls now know your employee ID and number. However, knowing you does not necessarily mean they will permanently save your contact; they will decide whether to keep your card based on their own contact list categories, storage capacity, and contact status.

This is not a company-wide broadcast, nor is it HR pushing a notification to every employee saying, “A new disk procurement specialist has joined today.”

Of course, onboarding is not magic. In the first second after a newcomer joins, we cannot expect the entire company to immediately have perfect information about them. Awareness of relationships must propagate gradually through communication and refreshes. The “healthy structure required by the company bylaws” and the “contact lists people actually hold at a given moment” are two different things.

What if HR resigns? Those who already have contact lists can continue working. When you come to work next time, you can also directly contact people you have previously met, without needing to go through HR again. Actual clients can also save the DHT state from the last run, using old contacts to help re-join. (libtorrent)

But a truly new person, if they have neither HR’s number nor any veteran employee’s number, and have no other channel to introduce them, indeed cannot get in. Decentralization does not mean you can magically know who to call first.

5. Day 3: Visiting Old Chen, the Xbox Memory Manager

Your contact list is nearly complete. You pick up the first task slip:

Target Employee ID: 001000 00 0010 0011.

You don't need to ask, "Who in my M365 knows Old Chen?" Instead, you directly scan your entire contact list and select the few contacts whose employee IDs are closest to the target.

Here, "closest" does not mean simple subtraction of employee IDs. We use a comparison rule that all employees agree on:

Take two candidates' employee IDs, scan them from left to right, and find the first position where they differ. The candidate who matches the target at that position is closer to the target.

Leading digits have the highest priority. Trailing digits only determine the outcome if the leading digits cannot distinguish between the candidates. This is a colloquial way of comparing XOR distance. The longer the common prefix, the closer the match is guaranteed to be. If the common prefix is the same length, they are not necessarily equally close, and you can continue comparing the subsequent digits. (BitTorrent)

You realize you know Old Zhou. His employee ID starts with 001010…, placing him already within the Xbox region.

You call him: "I'm looking for 001000 00 0010 0011. Please introduce me to the few people you know whose IDs are closest to this one."

Old Zhou doesn't know Old Chen, but he introduces A-Jie. A-Jie's employee ID is 001000 00 0011 0101. Not only is he in the same Xbox region, but his business unit and department also match.

You ask A-Jie next. A-Jie checks his contact list: "Looking for memory management? I have this employee ID."

So, this leads to the following clue:

你：   110111 11 1010 0001
老周： 001010 00 0100 1001
阿杰： 001000 00 0011 0101
老陈： 001000 00 0010 0011

From matching only the first digit—which is completely different from you—to matching the first four, then the first eleven, and finally a full match. You may only know a small fraction of the company’s people, yet you leverage others’ familiarity with their immediate surroundings.

Note that these calls are typically made by you, one by one. It is not a case where you call Lao Zhou, who then broadcasts to eight people, who in turn each broadcast to another eight. The other party’s main role is to provide contact information; you maintain the current candidate list and decide who to ask next.

Moreover, you would not place all your hopes on Lao Zhou alone. You can query several nearby contacts simultaneously, merge the lists they return, deduplicate and sort them, and then ask those who are closer and have not yet been contacted. If someone does not answer, you continue along other leads; if one lead yields no progress, it does not mean other candidates should be discarded. This approach—where the querier maintains the candidate set and advances queries in parallel—is a key component of Kademlia lookup.(PDOS)

This example may indeed find the person in just a few rounds, but that does not justify promising “any company, always two or three times.” A few rounds of inquiry does not equate to sending just a few messages: each round may involve querying multiple people, and you may encounter unreachable contacts or timeouts.

6. But what if I only know Windows? Doesn't that mean I made a mistake in the first step?

Not necessarily.

Suppose that in your 0… slot, all eight contacts happen to be from Windows, with none from Xbox. The target, however, is Old Chen from Xbox.

This can still be a valid contact list.

Because your own employee ID starts with 1, while Old Chen’s starts with 0. Any contact whose ID starts with 0 is already closer to Old Chen than you are.

You ask a Windows employee. Their address is 000…, and Old Chen’s address is 001…. At the 00… level, they still belong to the same region, but at the next digit, they diverge into Windows and Xbox respectively.

According to company policy, this Windows employee should be in the other branch, i.e., 001…, to save contacts.

So, they can refer you to an employee from Xbox. Once at Xbox, those employees will continue to refer you along finer branches.

The key is not “your first contact must be from the final product,” but rather:

They may not yet have reached the specific sub-region where the target resides, but they must guide you into a more appropriate broader region; subsequently, their contact list will continue to narrow down the scope.

This is precisely why each person only needs to keep a few representatives at each level, rather than needing to know all sixty-four businesses and thousands of job roles.

VII. Now, Finally, We Can Answer the "High Mountains Clamping a Basin" Question

When trying to understand this algorithm, it’s easy to picture a topographic map: people farther from the target employee ID are higher up, and those closer in are lower. The search process is like a ball continuously rolling downhill.

But this metaphor immediately runs into a valid counterexample:

“Suppose the real target is in a basin, while everyone who knows them is on a mountain? What if there’s also a nearby-looking but actually incorrect low point outside? Why wouldn’t the ball stop there?”

Simply answering that “phone calls can cross mountains” is not enough. The real issue is: on what basis do you have that cross-mountain call? If the contact list is truly arbitrary, a false low point could absolutely exist. Even if the entire network is connected and all calls can be made, a search that only explores closer candidates might still miss the target.

Cyber Microsoft solves this problem by relying on the specific contact-list rule mentioned earlier.

First, assume that Old Chen is indeed still employed, and that everyone’s contact list complies with the charter. Now, stand at any position that is not Old Chen’s. Compare your full employee ID with Old Chen’s ID from left to right, and you will always find the first branch where your paths diverge.

Before this branch, you have followed the same path. At this branch, you went one way, and Old Chen went the other.

The company charter specifically requires: you must keep contacts on the other side, as long as there is anyone on the other side.

There is clearly someone on the other side, because Old Chen is there. More importantly, whoever stands on the other side has one more correct step toward the target than you do. You do not need to know Old Chen directly. Knowing any qualified contact on that side already gives you a step closer to the goal.

With the next employee, the same logic continues to hold.

Therefore, for that “false low point” to truly become a dead end, the following situation must occur: the other branch where the target resides clearly has people, yet the contact slot corresponding to the current employee is empty, or it no longer contains any available contacts.

This is not a proof that no arbitrary network can have basins. Rather, it identifies what structure can eliminate such dead ends, and where in the structure a breakdown causes dead ends to reappear.

Thus, “everyone knows a few random people” and “everyone keeps contacts on the other branch at each level” may both look like just a small contact list, but they are actually two completely different networks.

The first relies on chance. The second writes the necessary exits for navigation into the rules.

VIII. Silverlight: Clearly Hanging on Xbox, But Are You Still Finding It Correctly?

Up next is the most storied employee in the company.

Colleagues from the Silverlight team have left one after another, leaving only one veteran engineer. His project has already migrated to Xbox, and he now spends his days only having lunch with Xbox colleagues. Meanwhile, in the WPF team, there is an expert who particularly enjoys giving presentations. He speaks about Silverlight so fluently and convincingly that many people mistakenly believe he is responsible for that part of the business.

If you simply go around asking “who knows Silverlight,” you might indeed end up finding the presentation expert, rather than the unfortunate engineer who is actually maintaining the legacy system.

However, our task ticket cannot simply say “find someone who knows Silverlight.” It must specify the complete employee ID to be looked up.

Here, we need to distinguish between two scenarios.

If the unfortunate engineer has merely changed his desk location or his lunch companion, and his employee ID remains 010111…, then in this communication network, he still belongs to the Silverlight address zone. Where he sits or who he meets with recently does not change his address. He is still required to maintain his contacts according to his own employee ID, and cannot treat his list of business acquaintances as the entire routing table.

If this parallel world has reassigned him an Xbox address, for example 001000 00 1110 0111, then you should use this new employee ID to look him up in the Xbox address zone. You cannot acknowledge that his address has changed while still expecting the old address to automatically locate him. Transferring from an old employee ID to a new one requires separately maintaining a forwarding record.

This reveals a boundary of DHT:

DHT excels at “given an accurate key, where to look,” but it is not responsible for guessing who actually owns a product based on its name.

We embed business names into employee IDs to make the lookup direction visible to readers. However, when navigation is actually executed, what works is always the numbers on the task ticket, not how much an employee resembles an expert during meetings.

9. What Does "Ultimately Correct and Unique" Actually Guarantee?

This sentence must be split, otherwise the entire story will fall back into the original contradiction.

Whether the Employee ID is Unique Is One Thing

We have established that no two active employees use the exact same sixteen-digit employee ID at any given time. Therefore, when searching for a person using Old Chen's complete employee ID, only one employee can be a true match.

If he is not found, do not mistake Ah Jie, whose number is merely "similar," for Old Chen. Nearby employees may continue to help by providing referrals, but proximity does not equate to identity.

Whether the Most Recent Employee Is Unique Is Another Matter

Sometimes, what you are looking for is not an existing employee ID, but an address. For instance, the number of a record might happen to fall on a vacant slot.

In this case, you can sort all active employees according to the comparison rules described earlier to determine who is closest to this address.

As long as employee IDs are unique, this sorting will not have ties. The reasoning is straightforward: two different employee IDs will always have a first position where they differ, and at that position, the target can only be 0 or 1. Among the two candidates, exactly one must match the target at that position.

Therefore, once the set of employees is fixed, the mathematical top rank is determined and unique; the top eight also form a determined set.

However, the top rank is merely "the person closest to this address" and does not necessarily mean that person is actually handling the business described by this address. If no one is assigned to the address, nearest-neighbor search cannot magically produce an assignee.

Whether the first place is always found also depends on the contacts list.

Under ideal conditions—such as satisfied routing coverage, valid contacts, and correct query execution—it can be proven that the lookup finds the truly nearest node. The correctness argument in the original Kademlia paper explicitly relies on a premise: as long as nodes exist within a certain distance range, the corresponding contact bucket contains at least one contact. (PDOS)

This does not mean that every real-world query yields a proof of "zero omissions across the entire organization."

Even if everyone is using incomplete contact lists, and assuming no one has left the organization and the network is as stable as a soldered circuit board, queries may still miss nodes. Network stability does not automatically fill in missing knowledge. A lookup that finds "I have already queried the few nearest nodes I currently know" does not imply that it has checked all nodes globally.

Therefore, the correct conclusion is: the mathematical answer may be unique, and ideal models can guarantee finding it, but real-world operation must rely on maintenance, redundancy, and retries to approximate these conditions as closely as possible. These three statements cannot be merged into a single unconditional claim of "always findable."

Moreover, what is unique is the ranking result, not the path. One person may start from OneDrive, while another starts from Azure; they may traverse entirely different sets of nodes and ultimately converge near the same target.

10. Daily Work: Managing Tasks While Maintaining the Contact List

Once you officially start work, your daily life takes on a slightly strange quality.

In the morning, you genuinely go to negotiate hard drive procurement. At noon, someone calls asking for a PowerShell employee ID; you pick a few people from your contacts whose names are close matches and send the numbers over. In the afternoon, you need to contact Xiao Xia to confirm the air conditioning power supply, and in the process, you happen to meet two colleagues from the data center support team.

The company does not need to organize a large "mutual introduction conference" for all employees every day. The normal act of finding people inherently involves exchanging and updating contact information.

However, relying solely on random conversations is not enough. If a certain area has not been contacted for a long time, the contact management software will proactively select a target address in that area, initiate a lookup to check if the original contact is still valid, and see if new contacts can be added. The BitTorrent DHT specification also includes this kind of refresh mechanism for inactive address ranges.(BitTorrent)

If Lao Zhou leaves the company, you don't have to announce that the entire Xbox team is now unreachable. Keeping multiple contacts in a single slot is precisely to avoid betting the entry point for an entire business area on one person.

Even if all the Xbox employees you know become unreachable, you might still find new Xbox contacts through contacts in Windows, development tools, or other areas. But "possibly repairable" and "unconditionally guaranteed repairable" are still different: if the available leads are missing, refreshing is not a radar that can magically detect unknown numbers out of thin air.

Different employees' contact lists can overlap or be entirely different. The system relies on contact information stored in multiple places. It should not assume these lists are necessarily completely independent, nor should it casually calculate a success rate that looks too perfect to be true.

So, what HR calls "training" is not a central body auditing the contact lists of tens of thousands of people every day. In terms of the program, it corresponds to each node running the same maintenance rules. The ideal structure is a condition for correctness analysis, while daily maintenance is the effort in reality to maintain this condition.

11. We've learned how to find people, but where is the hash table?

At this point, the company is still just a distributed contact list.

The concept of a "table" in DHT starts with a new rule.

The company allows each employee to maintain a second booklet. The first records "who I know," while the second records "who to contact for a specific file."

Suppose you have a software installation package, and its file ID is a 16-digit hexadecimal number. Instead of broadcasting the package to the entire company or notifying everyone you know one by one, you first use the algorithm you just learned to find a group of employees whose employee IDs are closest to this file ID.

In our story, we choose eight.

You tell them: "When someone asks for this file, please give them my phone number." As a result, a new entry is added to their second booklet:

档案编号 → 你的电话号码

The next day, a Bing employee wanted to obtain this installation package. Although he had never met you before, he obtained the same file number.

He also followed the same set of rules to look for the employee near that number. As long as he asked the contact who held your registration, he could get your phone number and then contact you directly to receive the file.

The publisher and the querier do not need to know each other beforehand, because both use the same number and go to the same address area to complete the meeting.

This is where the concept of a “hash table” begins to appear: the number is the key, and the registered contact information is the value. The entire table is not stored on a central server, but distributed among different employees based on addresses.

In the context of BitTorrent, what is registered is not “who owns the file permanently,” but “which participants are in the download swarm for this resource and can be contacted.” The implementation in libtorrent continues to look for nodes near the target and registers its own participant information with the eight nearest nodes found.(libtorrent)

There is deliberately no single unique administrator here. Finding the first one is great; not finding the first one but obtaining usable resource contact information from the third one also completes the task.

These registrations are not permanent records. Seeders need to periodically re-register, and index nodes will eliminate expired records. libtorrent provides a mechanism for periodically re-announcing the seed participation status to the DHT.(libtorrent)

Therefore, being responsible for purchasing hard drives does not mean your booklet only stores hard drive-related resources. As long as a certain resource number falls near you, others may come to register with you. What you store is a “where to find it” clue, not the resource content, and it certainly does not mean that you have downloaded it yourself.

XII. Switching Badges, Phones, and Records Back to the Real World

Now you can put away the Cyber Microsoft props.

The node IDs in the real BitTorrent mainline DHT are 160 bits long, not the sixteen-digit hexadecimal representations we use for readability. The resource identifiers in traditional BitTorrent v1 also occupy an address space of this length. Nodes exchange DHT messages via UDP, and the DHT stores participants' contact information, not the files themselves. (BitTorrent)

We also need to dismantle a piece of scaffolding that was intentionally constructed: real node IDs carry no Microsoft business semantics. 100… does not represent Azure, and 001… does not represent Xbox. Our business addresses make partitioning visible; the actual protocol only requires numbers and their comparison rules. Some security extensions even link the selection of parts of the node ID to external IPs, so it is also inappropriate to generalize all implementations as "simply picking a completely random number." (BitTorrent)

Resource IDs are not derived by arbitrarily converting a name like "latest version of some software" into a number. The infohash in traditional BitTorrent v1 is a hash value calculated from the encoded content of the info section in the torrent metadata. Similar names do not imply similar resource IDs; identical names do not guarantee the same resource. (BitTorrent)

Magnet links are like a task slip with an accurate archive number. Once the client obtains the ID, it can find participants through channels like DHT, request metadata from them, and then exchange file data. Display names, tracker servers, and other information in magnet links can be optional; the accurate resource identifier is the core. (BitTorrent)

Thus, the initially seemingly absurd question finally closes:

How can you, with just a short string of characters, find the people offering a specific software across the vast internet?

It is not that this string contains the IPs of all seeders, nor that computers around the world are listening to your broadcast. Rather, both publishers and queriers adhere to the same rule: using the same key to register and query in the same address space.

13. One Last Glance at the Tree Without a Manager

Looking back at the initial business tree, you'll find that its most interesting aspect isn't the binary structure, but rather the people who don't exist.

There is no 100-numbered Azure General Manager, no 110-numbered M365 Switchboard, and no super-employee occupying the root node who holds the entire company's phone numbers. Those positions are merely address categories. All individuals actually participating in communication stand on leaf addresses of equal length.

However, the equality among employees isn't a magic trick automatically resulting from "employee IDs being the same length." Instead, it's because the protocol assigns the same responsibilities for introduction, query, and maintenance to all ordinary nodes. Addresses can be hierarchical, but participants don't need to form a hierarchy as a result.

The company hasn't eliminated rules either. On the contrary, it replaced the path of "finding the boss's boss" with a strict structural rule: each employee maintains a small piece of necessary contact information, allowing the next employee to continue advancing the query.

The valley model once led people to believe that algorithms were just trying their luck on arbitrary terrain. Now we know that the key isn't whether the ball is smart enough, but what structure the company prescribes for each directory.

One person knowing only about a hundred colleagues doesn't mean their world contains only a hundred people. Those hundred colleagues each hold entries to other regions. As long as these entries are distributed and maintained according to rules, local knowledge can piece together global navigation capability.

No single node knows the entire network, but the entire network can collectively complete a lookup.

Understanding this point, you no longer just know the full name of DHT, but truly see how it works.# Understanding DHT: Welcome to a Microsoft Without a Central Directory

You've started a job at a Microsoft in an alternate universe, tasked with procuring hard drives for Microsoft 365 data centers.

On your first day, you receive three task tickets: contact the Xbox engineer responsible for memory management, contact the Silverlight sales team, and contact the colleague in charge of power supply for the server room air conditioning. All three tickets include the counterpart's employee ID, but no phone number.

You open the company directory and find that it is...个人都没有。

人事解释说，这家公司没有中央通讯录，没有负责层层转发消息的经理，也不允许你给全公司群发邮件。每个人只维护一小本自己的联系人名单。至于几万名员工之间怎么找到彼此，是每位员工都必须掌握的入职技能。

“所以我要认识全公司？”

“不。百来号人就差不多了。”

“然后我就能找到一个完全陌生的 Xbox 工程师？”

“只要公司的通讯网络维护得好，就可以。”

这个故事要解释的，就是 DHT——分布式哈希表。更准确地说，我们要理解的是 BitTorrent 主线 DHT 所采用的 Kademlia 式结构：每个参与者只认识少量其他参与者，却能共同完成一张巨大目录的查询工作。并不是所有 DHT 都使用同一种算法，本文只讨论这一种。(BitTorrent)

现在，先别急着研究协议。我们去领工牌。

一、这家公司的业务，全都写成了数字

赛博微软有一个奇怪的习惯：所有业务都必须拥有一个二进制地址。

二进制并不神秘。站在一条岔路上，往左走记一个 0，往右走记一个 1。连续走六次，就能在一棵完整的二叉树里选中六十四个位置之一。

我们把 Windows、Xbox、Azure、Microsoft 365 等主要产品线，展开成六十四个有代表性的业务入口。**产品、服务和功能的名字来自真实微软，但下面的分组与编号是为故事设计的，不是微软的真实组织架构，也不是一份官方“业务六十四强”排名。**产品名字可以在微软的产品目录、Azure 产品页面及游戏目录中找到。(Microsoft)

其中还特意保留了 Silverlight 这个历史业务。现实中的 Silverlight 已在 2021 年结束支持；在我们的平行世界里，它暂时还留着一个柜台，好让后面的故事有地方发生。(Microsoft Learn)

下面就是公司的业务地址树。每个分叉都只有两条路，六位编号的业务入口正好有六十四个。

赛博微软
├── 0 终端、游戏与技术平台
│   ├── 00 个人计算与游戏
│   │   ├── 000 Windows 与终端
│   │   │   ├── 0000 系统与设备
│   │   │   │   ├── 00000 操作系统
│   │   │   │   │   ├── 000000 Windows 客户端
│   │   │   │   │   └── 000001 Windows Server
│   │   │   │   └── 00001 硬件与浏览器
│   │   │   │       ├── 000010 Surface
│   │   │   │       └── 000011 Microsoft Edge
│   │   │   └── 0001 终端管理与安全
│   │   │       ├── 00010 部署与管理
│   │   │       │   ├── 000100 Windows 365
│   │   │       │   └── 000101 Microsoft Intune
│   │   │       └── 00011 终端防护
│   │   │           ├── 000110 Defender for Endpoint
│   │   │           └── 000111 BitLocker
│   │   └── 001 Xbox 与游戏
│   │       ├── 0010 游戏平台与跨端体验
│   │       │   ├── 00100 主机与订阅
│   │       │   │   ├── 001000 Xbox 主机与系统
│   │       │   │   └── 001001 Xbox Game Pass
│   │       │   └── 00101 跨端游戏
│   │       │       ├── 001010 Xbox 云游戏
│   │       │       └── 001011 Minecraft
│   │       └── 0011 游戏内容
│   │           ├── 00110 动作与竞速
│   │           │   ├── 001100 光环
│   │           │   └── 001101 极限竞速
│   │           └── 00111 策略与模拟
│   │               ├── 001110 帝国时代
│   │               └── 001111 微软模拟飞行
│   └── 01 开发与企业技术
│       ├── 010 开发工具与框架
│       │   ├── 0100 编程工具与代码协作
│       │   │   ├── 01000 开发环境
│       │   │   │   ├── 010000 Visual Studio
│       │   │   │   └── 010001 Visual Studio Code
│       │   │   └── 01001 代码协作
│       │   │       ├── 010010 GitHub
│       │   │       └── 010011 GitHub Copilot
│       │   └── 0101 应用开发框架
│       │       ├── 01010 通用与网站框架
│       │       │   ├── 010100 .NET
│       │       │   └── 010101 ASP.NET Core
│       │       └── 01011 桌面与历史框架
│       │           ├── 010110 WPF
│       │           └── 010111 Silverlight
│       └── 011 工程、数据与安全
│           ├── 0110 工程效率与数据
│           │   ├── 01100 开发运维
│           │   │   ├── 011000 Azure DevOps
│           │   │   └── 011001 PowerShell
│           │   └── 01101 数据平台
│           │       ├── 011010 SQL Server
│           │       └── 011011 Microsoft Fabric
│           └── 0111 身份与安全
│               ├── 01110 身份与治理
│               │   ├── 011100 Microsoft Entra
│               │   └── 011101 Microsoft Purview
│               └── 01111 威胁防护
│                   ├── 011110 Microsoft Sentinel
│                   └── 011111 Defender for Cloud
└── 1 云与在线业务
    ├── 10 公共云与互联网
    │   ├── 100 Azure
    │   │   ├── 1000 计算与应用托管
    │   │   │   ├── 10000 虚拟机与容器
    │   │   │   │   ├── 100000 Azure 虚拟机
    │   │   │   │   └── 100001 Azure Kubernetes 服务
    │   │   │   └── 10001 应用与函数
    │   │   │       ├── 100010 Azure App Service
    │   │   │       └── 100011 Azure Functions
    │   │   └── 1001 存储、数据与网络
    │   │       ├── 10010 存储与关系数据
    │   │       │   ├── 100100 Azure Blob 存储
    │   │       │   └── 100101 Azure SQL 数据库
    │   │       └── 10011 分布式数据与网络
    │   │           ├── 100110 Azure Cosmos DB
    │   │           └── 100111 Azure 虚拟网络
    │   └── 101 Bing 与互联网服务
    │       ├── 1010 搜索与人工智能
    │       │   ├── 10100 搜索与广告
    │       │   │   ├── 101000 Bing 搜索
    │       │   │   └── 101001 微软广告
    │       │   └── 10101 助手与设计
    │       │       ├── 101010 Microsoft Copilot
    │       │       └── 101011 Microsoft Designer
    │       └── 1011 资讯与职业服务
    │           ├── 10110 资讯与翻译
    │           │   ├── 101100 MSN
    │           │   └── 101101 微软翻译
    │           └── 10111 职业网络与学习
    │               ├── 101110 LinkedIn
    │               └── 101111 LinkedIn Learning
    └── 11 办公与企业应用
        ├── 110 Microsoft 365
        │   ├── 1100 内容创作
        │   │   ├── 11000 文字与表格
        │   │   │   ├── 110000 Word
        │   │   │   └── 110001 Excel
        │   │   └── 11001 演示与笔记
        │   │       ├── 110010 PowerPoint
        │   │       └── 110011 OneNote
        │   └── 1101 沟通与协作
        │   │   ├── 11010 邮件与会议
        │   │   │   ├── 110100 Outlook / Exchange
        │   │   │   └── 110101 Teams
        │   │   └── 11011 站点与文件
        │   │       ├── 110110 SharePoint
        │   │       └── 110111 OneDrive
        └── 111 Dynamics 与 Power Platform
            ├── 1110 业务管理
            │   ├── 11100 销售与服务
            │   │   ├── 111000 Dynamics 365 Sales
            │   │   └── 111001 Dynamics 365 Customer Service
            │   └── 11101 财务与供应链
            │       ├── 111010 Dynamics 365 Finance
            │       └── 111011 Dynamics 365 Supply Chain Management
            └── 1111 低代码与分析
                ├── 11110 应用与自动化
                │   ├── 111100 Power Apps
                │   └── 111101 Power Automate
                └── 11111 分析与智能体
                    ├── 111110 Power BI
                    └── 111111 Copilot Studio

最后几组涉及的身份、安全、企业应用和低代码业务，也都有对应的微软官方产品资料；这里仅借用它们的名字，下面的岗位安排仍然全部属于故事设定。(Microsoft Learn)

这张图虽然长，规则却只有一条：每往下走一步，就多确定一位数字，也把范围缩小一层。

还有一个特别重要的地方：100 只是 Azure 这个区域的名称，并没有一个工号只有三位的“Azure 总经理”。树上的中间分叉都是分类，不是真人。

真人还在更下面。

二、你的工牌，一共十六位

每个六位业务地址下面，再接部门、职责和具体席位。为了让所有员工平级，我们规定工号统一为十六位：

六位业务地址 + 两位部门类别 + 四位具体职责 + 四位席位编号

例如，OneDrive 的业务地址是 110111。它下面继续二分：

110111 OneDrive
├── 1101110 技术建设
│   ├── 11011100 研发
│   └── 11011101 测试
└── 1101111 业务运行
    ├── 11011110 商务与客户
    └── 11011111 运维与保障

部门下面的四位数字继续区分职责。比如在运维与保障里，我们约定 1010 是硬盘采购，1011 是存储维护，1100 是服务器供电，1101 是空调供电。最后四位再区分同一职责下的不同席位。

因此，你领到的工牌是：

110111 11 1010 0001

人事指着工牌念了一遍：“OneDrive，运维保障，硬盘采购，一号席位。欢迎加入微软，你的工作是让别人有地方保存文件，而你自己首先得有地方保存电话号码。”

随后，故事里的几位同事陆续登场：

此时，我们已经把一个容易混淆的问题拆开了：工号说明“你要找哪个地址”，电话号码说明“怎么联系到那里”。

你知道老陈的完整工号，不等于你已经知道他的电话。大家都知道这套地址如何划分，也不等于大家都拥有员工花名册。地址规划可以完全公开，活人的联系方式却分散在每个人的小通讯录里。

十六位最多容纳 65,536 个不同工号，所以这是一个缩小的教学模型。业务下面的岗位和席位可以空缺，不需要把整棵树坐满。所有真人都站在十六位地址的位置上，不会有人因为站在树的中间，就自动成了别人的上级。

三、公司章程：你的通讯录不能全是饭搭子

人事接着递给你一本公司章程。

里面没有复杂的管理术语，核心要求是：

从你自己的工号沿着地址树往上看，每遇到一个分叉，都要在“另一边”保存若干位联系人的号码。那一边有人，就应当有联系人；人少就尽量都记下，人多就保留一小批可靠的人。

这句话是整家公司能够运转的关键。

你属于 110111…，所以从你的角度，公司可以被拆成下面几块：

这些格子不是随便选出来的。每一个格子，都是你走向自己工位时，某次没有走进去的另一条岔路。

这也解释了“远处粗，近处细”的准确含义：**远处一大片地址共用一个联系人格子；靠近自己的地方，同样大小的范围会被拆成更多格子。**不是越近的每个格子都必须装越来越多的人，而是越近，分类越细。

为了方便，故事里规定每格最多保存八个人。在十六位模型下，按这种划分最多有十六格，八乘十六给出一个 128 人的宽松上限；贴近自己的小格子可能根本凑不满八个人，所以实际还会更少。“百来号人”是合理的规模感，不是每人必须背熟的固定人数。

这里还有一个比想象中更省事的地方：**你甚至不必分别认识八个 Azure 员工和八个 Bing 员工。**你在整个 10… 区域认识一小批人就行。到了他们那里，对方会继续细分那一片区域。

同样，你在 0… 这一格认识的人，暂时可以全是 Windows 员工。你仍然可能通过他们找到 Xbox。

因此，公司章程不是“每个产品都认识几个人”，而是“在地址树的每个相关分叉，认识另一边的几个人”。这比逐个产品交朋友省事得多。

四、第一天，一个人都不认识怎么办？

你抬头问人事：“章程我理解了，但我的通讯录现在是空的。第一通电话打给谁？”

人事把自己的名片递过来：“先打给我。”

这就是引导节点，也就是我们一直称作“HR”的角色。它的作用不是掌握全公司的联系方式，而是为一个完全不认识任何人的新人提供最初的入口。现实中的 DHT 引导服务，也是把一些已知可用的节点介绍给新人。(LibTorrent Blog)

你先报出自己的工号，请人事介绍几位号码比较接近的老员工。对方介绍给你的人，可能做 Teams，也可能做 OneDrive。你再联系他们，请他们继续介绍更接近你工号的人。

你首先在自己附近站稳了脚跟。

随后，你开始补齐那些尚不熟悉的区域。比如，你在 0… 那一格还没有联系人，就在这一范围内挑一个目标地址，向已经认识的老员工发起一次找人请求。老员工介绍一些人，那些人又介绍一些人，你逐渐获得那一侧的联系方式。

新人借用的是老网络已有的导航能力，而不是自己先认识全公司。

这些电话还有双向作用：你得到别人的名片，接到你电话的人也知道了你的工号和号码。不过，知道你不等于一定永久保存你；对方会按照自己通讯录的分类、容量和联系人状态决定是否留下这张名片。

这不是一次全公司广播，更不是人事向每个员工推送“今天新来了一位硬盘采购”。

当然，培训也没有魔法。新人刚加入的第一秒，不能要求全公司立刻拥有关于他的完美信息。认识关系需要通过通信和刷新逐步传播。“公司章程要求的健康结构”，与“某一时刻大家实际拿着的通讯录”，是两回事。

如果人事离职了呢？已经拥有联系人名单的人可以继续工作。你下次上班也可以直接联系以前认识的人，不必重新经过人事。实际客户端也可以保存上次运行时的 DHT 状态，用旧联系人帮助重新接入。(libtorrent)

但一个真正的新人，如果既没有人事电话，也没有任何老员工的号码，没有其他渠道能介绍他进来，那确实进不去。去中心化不等于能凭空知道第一通电话该打给谁。

五、第三天：去找 Xbox 管内存的老陈

通讯录建立得差不多了，你拿起第一张任务单：

目标工号：001000 00 0010 0011。

你不需要先问“我所在的 M365 里，谁认识老陈”。你直接翻自己的整本通讯录，挑出工号最接近目标的几个联系人。

这里的“接近”不是普通的工号相减。我们使用一条所有员工都认同的比较规则：

拿两个候选人的工号，从左往右看，找到两人第一次不同的位置；这一位谁和目标相同，谁就更接近目标。

前面的数字优先级最高，后面的数字只有在前面无法区分时才有机会决定胜负。这就是异或距离的口语化比较方式。共同前缀越长，一定越近；共同前缀一样长，却不一定一样近，还能继续比较后面的数字。(BitTorrent)

你发现自己认识老周，他的工号以 001010… 开头，已经在 Xbox 区域里。

你打电话过去：“我要找 001000 00 0010 0011，请把你认识的人里，最接近这个工号的几位介绍给我。”

老周不认识老陈，但介绍了阿杰。阿杰的工号是 001000 00 0011 0101，不仅同属 Xbox，连前面的业务和部门都已经对上了。

你再问阿杰，阿杰翻了一下通讯录：“找内存管理？这个工号我有。”

于是这条线索是：

你：   110111 11 1010 0001
老周： 001010 00 0100 1001
阿杰： 001000 00 0011 0101
老陈： 001000 00 0010 0011

从与你完全不同的第一位，到匹配前四位，再到匹配前十一位，最后完整匹配。你只认识公司的一小部分人，却借用了其他人对自己周围区域的熟悉程度。

注意，这些电话通常是你自己一通通打出去的。不是你打给老周，老周再群发八个人，那八个人再各自群发八个人。对方主要负责给你联系方式，你掌握着当前候选名单，决定接下来问谁。

而且，你不会把全部希望押在老周一个人身上。你可以同时问几位较近的联系人，把他们返回的名单合并，去重、排序，再问其中较近且尚未询问的人。某个人不接电话，就先沿其他线索继续；某条线索没有进展，也不意味着其他候选要被丢掉。这种由查询者维护候选集合、并行推进的方式，是 Kademlia 查找的重要组成部分。(PDOS)

这个例子确实可能几轮就找到人，但不能据此承诺“任何规模的公司，永远两三次”。几轮询问也不等于只发了几个消息：每轮可能问了多个人，还可能遇到失联和超时。

六、可我只认识 Windows 的人，第一步不就错了吗？

不一定。

假设你的 0… 格子里，八位联系人碰巧都来自 Windows，没有一个来自 Xbox。目标却是 Xbox 的老陈。

这仍然可以是一份合格的通讯录。

因为你自己的工号以 1 开头，老陈以 0 开头。任何一位以 0 开头的联系人，都已经比你更接近老陈。

你问到一位 Windows 员工。他的地址是 000…，老陈的地址是 001…。两人在 00… 这一层仍属于同一区域，但到了下一位，分别走向了 Windows 和 Xbox。

按照公司的章程，这位 Windows 员工应当在另一边，也就是 001…，保存联系人。

于是，他可以把你介绍给 Xbox 的某位员工。到了 Xbox，那里的员工又会在更细的分叉上继续介绍。

关键不是“你的第一位联系人必须来自最终那个产品”，而是：

他可以还没有到达目标所在的小区域，但必须把你带进一个更合适的大区域；接下来，他的通讯录会继续把范围缩小。

这正是为什么每个人只需要保存各层的少数代表，不必把六十四个业务、几千种职责全都认识一遍。

七、现在，终于可以回答“高山夹盆地”了

理解这套算法时，很容易想象出一张地形图：离目标工号越远的人越高，越接近的人越低。查找过程就像小球不断向低处滚。

但这个比喻马上会遇到一个合理的反例：

“假如真正的目标在一个盆地里，而认识他的人全是高山呢？外面还有一个看起来很接近、其实不正确的低谷。小球为什么不会停在那里？”

**仅仅回答“电话可以跨过高山”是不够的。**问题恰恰是：你凭什么拥有那通跨山电话？如果通讯录真的任意组成，假低谷完全可能存在。哪怕整个网络连通，所有电话都打得通，某种只探索较近候选的查找也可能漏掉目标。

赛博微软解决这个问题，靠的是前面那条具体的通讯录规则。

先假设老陈确实在职，而且大家的通讯录都满足章程。现在，你站在任意一个不是老陈的位置，把你的完整工号和老陈的工号从左往右比较，一定能找到双方第一次走向不同方向的那个分叉。

在这个分叉以前，你们走过的路一样；在这个分叉上，你走了一边，老陈走了另一边。

公司章程恰好要求：你必须在另一边保存联系人，只要另一边有人。

另一边显然有人，因为老陈就在那里。更重要的是，另一边不管站着谁，都比你多走对了这一层。你并不需要直接认识老陈，认识那边的任何一个合格联系人，就已经有了更接近目标的一步。

到了下一位员工那里，同样的道理继续成立。

因此，那个“假低谷”要想真的成为死路，就必须出现这样的情形：目标所在的另一支明明有人，当前员工对应的联系人格子却是空的，或者里面已经没有可用联系人。

这不是我们证明了任意网络都不会有盆地，而是我们找出了什么结构能排除这种死路，以及结构坏在哪里时死路会重新出现。

所以，“大家随便认识几个人”和“大家按每层另一支保存联系人”，看起来都只是一本小通讯录，实际上是两种完全不同的网络。

前一种靠缘分。后一种把导航所需要的出口写进了规则。

八、Silverlight 惨哥明明挂在 Xbox，你还找得对吗？

接下来登场的是公司里最有故事的一位员工。

Silverlight 的同事陆续离开，最后剩下一个老工程师。他的项目已经搬到 Xbox，自己每天也只和 Xbox 的同事吃饭。与此同时，WPF 里有一位特别喜欢演讲的专家，讲 Silverlight 讲得头头是道，很多人都误以为那部分业务归他负责。

如果你只是到处问“谁懂 Silverlight”，确实可能最后找到演讲专家，而不是这位真正维护遗留系统的惨哥。

但我们的任务单不能只写“找一个懂 Silverlight 的人”。它必须给出要找的完整工号。

这里需要把两种情况分清。

**如果惨哥只是换了工位、换了饭搭子，工号仍然是 010111…，那么在这张通讯网络里，他仍然属于 Silverlight 地址区。**座位在哪里、最近和谁开会，都不改变他的地址。他也仍然需要按自己的工号维护联系人，不能把业务上的熟人名单直接当成全部路由表。

**如果这个平行世界给他重新分配了 Xbox 地址，例如 001000 00 1110 0111，那你就应当拿着这个新工号，向 Xbox 地址区查找。**不能一边承认他的地址已经变了，一边仍然要求旧地址自动找到他。旧工号转到新工号，需要另行维护一条转址记录。

这揭示了 DHT 的一个边界：

DHT 擅长“给定准确的键，去哪里找”，不负责凭产品名字猜出谁现在实际负责它。

我们把业务名字写进工号，是为了让读者看得见查找方向。真正执行导航时，起作用的始终是任务单上的数字，而不是员工在会议上表现得多像专家。

九、“最终正确而且唯一”，到底保证了什么？

这句话必须拆开，否则整个故事又会回到最初的矛盾里。

工号是否唯一，是一回事

我们已经约定同一时刻没有两位在职员工使用完全相同的十六位工号。因此，拿着老陈的完整工号找人，真正匹配的员工只能有一位。

如果没找到他，不能把“号码比较像”的阿杰冒充成老陈。附近员工可以继续帮忙转介绍，但附近不等于本人。

最近的员工是否唯一，是另一回事

有时，你寻找的不是某个已经存在的员工工号，而是一个地址。例如，一份档案的编号可能正好落在空席位上。

这时可以把所有在职员工按照前面的比较规则排个序，找出谁最接近这个地址。

只要工号不重复，这个排序没有并列。道理也不难：两个不同的工号总有第一次不同的位置，而目标在那一位只能是 0 或 1，两位候选人里必然有且只有一位与它相同。

因此，固定员工集合后，数学上的第一名是确定且唯一的；前八名也形成一个确定的集合。

但第一名只是“离这个地址最近的人”，不一定真的在做这个地址所描述的业务。地址上没有人，就不能靠最近邻搜索凭空变出一位任职者。

查询是否一定找到第一名，还取决于通讯录

在路由覆盖条件成立、联系人有效、查询正确执行等理想条件下，可以证明查找找到真正最近的节点。原始 Kademlia 论文的正确性论证明确使用了一个前提：某个距离范围内只要存在节点，对应的联系人桶就至少有一个联系人。(PDOS)

这不是说现实中的每次查询，都拿到了一个“全公司绝无遗漏”的证明。

如果大家拿着残缺通讯录，即使所有人都没有离职、网络稳得像焊死的电路板，查询仍然可能漏找。**网络稳定不会自动补全缺失的知识。**一次查找发现“我目前知道的最近几个人都问过了”，也不等于它已经检查过全球所有节点。

因此，正确的结论是：数学答案可以唯一，理想模型可以保证找到它，但现实运行需要靠维护、冗余和重试尽量接近这个条件。三句话不能合并成一句没有前提的“永远找得到”。

而且，唯一的是排序结果，不是路线。你从 OneDrive 出发，另一个人从 Azure 出发，可以经过完全不同的员工，最后汇合到同一片目标附近。

十、日常工作：一边办事，一边维护通讯录

你正式开始上班以后，日常生活变得有些奇怪。

上午你真的去谈硬盘采购。中午有人打电话来，问一个 PowerShell 工号，你从通讯录里挑出几位比较接近的人，把号码发过去。下午你要找小夏确认空调供电，又顺便认识了两位机房保障同事。

公司不需要安排所有员工每天举行一次大型“互相认识大会”。正常的找人活动本身，就在交换和更新联系人信息。

不过，纯靠随机聊天不够。某个区域很久没有联系过，通讯录软件就会主动挑一个落在那一区域的目标地址，发起一次查找，看看原来的联系人还在不在，能否补充新的联系人。BitTorrent 的 DHT 规范也包含这种针对不活跃地址范围的刷新机制。(BitTorrent)

如果老周离职了，你不必宣布整个 Xbox 从此失联。一个格子里保留多位联系人，正是为了避免把整片业务的入口押在一个人身上。

即使你认识的几位 Xbox 员工都失联了，也可能通过 Windows、开发工具或其他区域的联系人，重新找到新的 Xbox 联系人。但“可能修复”和“无条件必然修复”仍然不同：如果可探索的线索已经缺失，刷新也不是能凭空看见陌生号码的雷达。

不同员工的通讯录可以重叠，也可以不同。系统依靠的是多处保留的联系信息，不应假定这些名单必然完全独立，更不能据此随手算出一个漂亮到不真实的成功率。

所以，人事所谓的“培训”，并不是中央机构每天审核几万个人的通讯录。真正对应到程序，是每个节点运行相同的维护规则。理想结构是正确性分析的条件，日常维护则是在现实中努力保持这个条件。

十一、我们已经学会找人了，可哈希表在哪里？

到这里，这家公司还只是一套分布式通讯录。

DHT 中的“表”，要从一个新规定开始。

公司允许每位员工维护第二本小册子。第一本记录“我认识谁”，第二本记录“某个档案可以去找谁拿”。

假设你手里有一份软件安装包，档案编号是一个十六位数字。你不把安装包广播给全公司，也不把自己认识的人挨个通知一遍，而是先使用刚刚学会的算法，找到工号最接近这个档案编号的一批员工。

在故事里，我们选八位。

你告诉他们：“有人问这份档案时，请把我的电话号码给他。”于是，他们的第二本小册子里多出一行：

档案编号 → 你的电话号码

第二天，一位 Bing 员工想拿这份安装包。他虽然完全不认识你，却拿到了同一个档案编号。

他也按照同一套规则寻找那个编号附近的员工。只要问到保存着你这条登记的联系人，就能得到你的电话，随后直接联系你拿文件。

发布者和查询者不需要先认识彼此，因为双方使用相同的编号，前往相同的地址区域完成会合。

这就是“哈希表”开始出现的地方：编号是键，登记的联系方式是值。整张表没有存放在一台中央服务器上，而是按地址分散在不同员工手里。

对应到 BitTorrent，登记的不是“文件归谁永久所有”，而是“有哪些参与者在这个资源的下载群体里，可以尝试联系”。libtorrent 的实现会继续寻找目标附近的节点，并向找到的最近八个节点登记自己的参与者信息。(libtorrent)

这里故意不是一位唯一管理员。你找到第一名很好，没找到第一名，但从第三名那里拿到了可用的资源联系方式，也已经完成了任务。

这些登记也不是永久档案。做种者需要周期性重新登记，索引节点会淘汰过期记录。libtorrent 就提供了周期性向 DHT 重新宣告种子参与状态的机制。(libtorrent)

因此，你负责硬盘采购，不代表你的小册子只保存硬盘相关资源。只要某个资源编号落在你附近，别人就可能来向你登记。你保存的是一条“去哪找”的线索，不是资源内容，更不意味着你自己下载过它。

十二、把工牌、电话和档案换回真实世界

现在可以把赛博微软的道具收起来了。

真实 BitTorrent 主线 DHT 的节点 ID 是 160 位，不是我们为了阅读方便使用的十六位。我们讨论的传统 BitTorrent v1 资源标识也占用这个长度的地址空间。节点通过 UDP 交换 DHT 消息，而 DHT 保存的是参与者的联系信息，不是文件本身。(BitTorrent)

还要拆掉一块特意搭建的脚手架：真实节点的编号没有微软业务语义。100… 不表示 Azure，001… 也不表示 Xbox。我们的业务地址让分区变得可视化；实际协议只需要数字及其比较规则。一些安全扩展还会把节点 ID 的部分选择与外部 IP 联系起来，因此也不宜把所有实现概括成“完全随意挑一个随机数”。(BitTorrent)

资源编号也不是把“某软件最新版”这个名字随便转换成数字。传统 BitTorrent v1 的 infohash，是对种子元数据中 info 部分的编码内容计算出的哈希值。名字相似，不代表资源编号相近；名字相同，也不保证是同一个资源。(BitTorrent)

磁力链接则像那张写着准确档案编号的任务单。客户端拿到编号后，可以通过 DHT 等渠道找到参与者，再向参与者索取元数据，随后交换文件数据。磁力链接中的显示名称、追踪服务器等信息可以是可选的，准确的资源标识才是核心。(BitTorrent)

于是，最初那个看似离谱的问题终于闭合了：

你为什么能拿着一小串字符，就从茫茫互联网里找到正在提供某个软件的人？

不是这串字符藏着所有做种者的 IP，也不是全世界电脑听到了你的广播。而是发布者和查询者都遵守同一条规则：拿着同一个键，去同一片地址区域登记和查询。

十三、最后再看一眼那棵没有经理的树

现在回头看最开始的业务树，会发现它最有意思的地方并不是二进制，而是那些不存在的人。

没有 100 号 Azure 总经理，没有 110 号 M365 总机，也没有一个占据根节点、掌握全公司电话号码的超级员工。那些位置都是地址分类。所有真正参与通信的人，都站在同样长度的叶子地址上。

不过，员工平级并不是“工号一样长”自动带来的魔法，而是协议把相同的介绍、查询和维护职责分给了所有普通节点。地址可以分层，参与者不需要因此形成上下级。

公司也没有消灭规则。恰恰相反，它用一条严格的结构规则，取代了“找老板的老板”这条路径：每位员工都维护一小块必要的联系信息，让下一位员工能够把查询继续推进。

山谷模型曾经让人以为，算法是在任意地形上碰碰运气。现在我们知道，关键不在小球够不够聪明，而在公司究竟给每本通讯录规定了什么结构。

一个人只知道百来位同事，并不意味着他的世界只有百来个人。那百来位同事各自又掌握着其他区域的入口。只要这些入口按规则分布并得到维护，局部知识就能拼出全局的导航能力。

没有任何一个节点知道整个网络，但整个网络可以共同完成一次查找。

理解了这一点，你就不再只是知道 DHT 的全称，而是真正看见了它如何工作。