保持 ASIO io_context 无任务时运行

ASIO 的 io_context::run() 如果发现没有 pending 的任务就会返回,对于 server 的监听线程来说这是符合常理的,因为无论如何至少有个 acceptor::async_accept() 在 pending。

Read More

atoi With Overflow Handled

leetcode 上有一题是让你实现一个 atoi(),但是因为函数类型是 32-bit int,所以可以直接内部转换到 64-bit int,避免需要直接处理溢出的情况。

如果要针对 int64 实现一个 atoi() 又该如何做?

Read More

Allow Connections From LAN for Trojan-qt5

因为众所周知的原因,机场的服务商把协议从 SS 切换到了 Trojan。但是之前的 SS windows 客户端只支持 SS 协议,所以切换后只能换 Trojan-qt5 作为客户端。

但是这个客户端做的实在不怎么样,作者似乎是在原来的 ss-qt5 的基础上做的修改,集成了 libtrojan;以至于之前 SS-Windows 用的好好的 Allow Connections From LAN 功能到这里没法用了。

Read More

Randomly Generate Base62 for URL Shortening

Last week I wrote a post about how to design an URL shortening service, like TinyURL, and came up with 2 strategies to encode an URL, and one of which is to randomly generate base64 sequence.

Read More

How To Design a URL Shortening Service

1. Encoding Actual URL

The path part, which we would call it key, of an encoded URL can consist of 6 ~ 8 digits in base62, up to desired uniqueness rate.

Randomly Generated

We can randomly generate those digits each within the range [0, 61].

Then we must check if the generated key is unique by consulting our key storage.

Aside: this checking process can be optimized with data structures like bloom-filter, provided we have to deal hundres of million records.

If we are unlucky, we may have a key collision; in this case, just re-generate another key until its unique.

To make encoding more efficient, we can have a standalone Key Generation Service(KGS) that generates those random key beforehand, and store them.

Read More

CMake 入门指南

这篇文章来自于我在知乎上的这个回答

天知道为什么当初会花时间写一个这么严肃的答案,考虑到国内社区的审查力度保不准哪天我的帐号就GG了,这里特意做一个备份。


作为一个从2018年下半年开始到现在断断续续折腾了一年半 CMake 的人,刚好经历了 CMake 从懵逼到入门阶段。

注:虽然问题是17年提的,但是考虑到 CMake 的频繁迭代和最佳实践的变化,希望以下内容仍有帮助。

Why CMake ?

先回答括号中的问题:被逼的

这三个字是认真的。

不管 CMake 是否是一个优秀的构建工具,不管你是否认同 CMake,都无法否认 CMake 目前是 C++ 的 de facto build system[^1]。

所以在社区以及生态的影响下,使用 CMake 作为构建工具的项目会越来越多。

Read More

SYN Queue and Accept Queue

0x00 A Single Queue or Two Queues

TCP/IP stack has two options to implement the backlog queue for a socket in the LISTEN state.

Door #1: A Single Queue

A single queue can contain connections in two different states:

  • SYN RECEIVED
  • ESTABLISHED

And only connections in ESTABLISHED state can be returned to the application by calling the accept() syscall.

Therefore, the length of this queue is determined by the backlog argument of the listen() syscall.

Door #2: A SYN Queue & An Accept Queue

In this case, connections in state SYN RECEIVED are added to the SYN queue, and later moved to the accept queue when their state changes to ESTABLISHED.

Read More