<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title><![CDATA[My Blog]]></title>
    <link>https://daichangyu.com/en</link>
    <description><![CDATA[Personal Tech Blog]]></description>
    <language>en</language>
    <atom:link href="https://daichangyu.com/api/rss?locale=en" rel="self" type="application/rss+xml" />
    
    <item>
      <title><![CDATA[Fixing Windows 11 resolution in VMware Fusion on macOS]]></title>
      <link>https://daichangyu.com/en/blog/vmware-fusion-win11-resolution-on-macos-zhihu-2030727323260032019</link>
      <guid isPermaLink="true">https://daichangyu.com/en/blog/vmware-fusion-win11-resolution-on-macos-zhihu-2030727323260032019</guid>
      <description><![CDATA[Installed the latest VMware Fusion on macOS today and got Windows 11 up and running without a hitch — but the resolution was stuck at 1024×768. Online tutorials and AI answers were all underwhelming, and I eventually found the fix: you need to install the built-in **VMware Tools**. It took me a while to track it down — it lives under one of the Mac menu-bar entries at the top…

![](/images/zhihu/vmware-fusion-win11fen-bian-l-she-zhimacos-zhihu-2030727323260032019/93a881f50c27.jpg)]]></description>
      
      <author>Admin</author>
      <pubDate>Thu, 23 Apr 2026 11:30:43 GMT</pubDate>
    </item>

    <item>
      <title><![CDATA[What is Cross-Origin? A beginner's guide to CORS]]></title>
      <link>https://daichangyu.com/en/blog/what-is-cors-beginner-guide-zhihu-2030692651218027705</link>
      <guid isPermaLink="true">https://daichangyu.com/en/blog/what-is-cors-beginner-guide-zhihu-2030692651218027705</guid>
      <description><![CDATA[I browsed a few cross-origin explainers on Zhihu today and none read naturally for beginners, so I reworked one with the help of an AI.

Audience: absolute beginners.

* * *

🍪 What is cross-origin? (Beginner speed-run edition)

Since you're new, let's drop the developer jargon and use **"neighborhood relationships"** and **"a building security guard"** as an analogy.

* * *

### 1️⃣ What is cross-origin? (The guard's ID check)

Imagine you live in a residential complex in Beijing called **"Xijiao No. 1"**.

-   **🏠 Your home (the frontend):** You live in **Building A, Apt 101** inside this complex.
-   **🍫 Your snack stash (the backend/server):** Also in this complex, in **Building B, Apt 202**.

Normally, when you're hungry, you walk over to Building B to grab a snack. The security guard recognizes you as a resident — this is called **"same origin"**, and you walk right through.

**One day:** You want something new. You hear that **Building C, Apt 303** in the neighboring complex **"Dongjiao Courtyard"** has great cake. You head over and try to walk in. At the entrance, the **security guard (the browser)** stops you:

> 👮‍♂️ **Guard:** "Hold up! You're from Xijiao No. 1 — what gives you the right to walk in here? This is cross-origin. Not allowed!"

**📝 Key takeaway**

> **Cross-origin**: The browser is like this guard. For safety, the rule is: **unless the other side explicitly agrees, you can't just grab things from another "home" (different domain / protocol / port).**

* * *

### 2️⃣ Why block it? (To keep thieves out)

The guard may feel overbearing — but without him, the internet would be chaos.

Picture this: you just logged into **online banking** (Xijiao No. 1), and then you opened a **phishing site pretending to offer a prize** (Dongjiao Courtyard). Without the guard, that phishing site could sneak into your banking page, steal your login (cookies), impersonate you, and wire your money out.

🛡️ **The guard (the browser) exists to ensure: you can only freely touch things that belong to your own home.**

* * *

### 3️⃣ So how do you fetch things from another home? (Three solutions)

Sometimes you legitimately need to fetch from a different origin (for example, your page needs weather data from a weather-forecast server). Here are the usual options:

### 🛠️ Method A: The host gives the guard a heads-up (CORS — the standard approach)

You (the frontend) want to pick up cake from Dongjiao Courtyard. The host of Dongjiao Courtyard has already told their guard ahead of time: *"Anyone from Xijiao No. 1 is welcome — let them in!"* The guard checks the list, sees you're on it, and waves you through.

-   💡 *Technically: the server adds an `Access-Control-Allow-Origin` response header.*

### 🛵 Method B: Send a courier (Proxy — developers' favorite)

Worried about the guard? Don't go yourself. You send a **courier (the dev server / Nginx)**. The courier visits your home first, then heads to Dongjiao Courtyard and brings the cake back to you. **The trick:** the guard only stops regular neighbors, not professional couriers. Server-to-server conversations aren't checked by the guard.

-   💡 *Technically: the frontend calls its own server, and that server makes the request to the target server.*

### 🕳️ Method C: Sneak through the window (JSONP — legacy)

The windows at Dongjiao Courtyard aren't shut properly. You slip a note saying "I want cake" through the window, and they throw the cake back out the same window. This trick only covers very limited cases and is rarely used today.

-   💡 *Technically: exploits the fact that `<script>` tags aren't restricted by the same-origin policy; only `GET` is supported.*

* * *

### 📌 Summary

-   🤝 **Cross-origin** = your page wants to grab something from **another home** (a different domain).
-   🛡️ **Same-origin policy** = the guard the browser dispatches to stop you grabbing things at random.
-   📏 **The rule** = if any of "protocol / domain / port" doesn't match, the guard treats it as cross-origin.
-   🔑 **Solutions** = either the other side **allows** you in (CORS), or you send **a middleman** (a proxy) to fetch for you.]]></description>
      
      <author>Admin</author>
      <pubDate>Thu, 23 Apr 2026 09:03:00 GMT</pubDate>
    </item>

    <item>
      <title><![CDATA[Differences between IEC 60870-5-102 and IEC 60870-5-104]]></title>
      <link>https://daichangyu.com/en/blog/iec-60870-5-102-vs-104-differences-zhihu-2029936240728995201</link>
      <guid isPermaLink="true">https://daichangyu.com/en/blog/iec-60870-5-102-vs-104-differences-zhihu-2029936240728995201</guid>
      <description><![CDATA[Intended audience: readers who already have a basic understanding of the 104 protocol.

* * *

This is a detailed reference comparing **IEC 60870-5-102** and **IEC 60870-5-104**, covering fundamentals, communication architecture, message interaction, and ASDU details.

* * *

## A deep comparison between IEC 102 and IEC 104

### 1. Core purpose and application scenarios

Dimension

IEC 60870-5-102 (102)

IEC 60870-5-104 (104)

Full name

Companion standard for the transmission of integrated totals in electric power systems

Companion standard for network access using standard transport profiles

Core use

"Metering": dedicated to electric energy billing systems.

"Monitoring": used for SCADA in substations.

Primary data

Historical/real-time accumulated energy (peak/off-peak/flat tariffs).

Four-remotes data (status, measurement, control, setpoint).

Real-time performance

Relatively low — typically minute-level or scheduled daily reads.

Very high — millisecond-resolution Sequence-of-Events (SOE) reporting.

* * *

### 2. Communication architecture and protocol stack

### 2.1 IEC 102: Enhanced Performance Architecture (EPA)

-   **Model:** Follows a three-layer OSI model (physical, data-link, application).
-   **Medium:** Originally designed for serial interfaces (RS-232/485) using asynchronous byte transmission.
-   **Frame format:** Uses the **FT1.2** frame format (start byte `68H` or `10H`, stop byte `16H`, and a checksum).

### 2.2 IEC 104: Network-access architecture

-   **Model:** Maps the application layer directly onto the **TCP/IP** stack.
-   **Medium:** Ethernet (fiber, twisted pair).
-   **Standard port:** TCP **2404**.
-   **Frame format:** Uses an **APDU** structure (starts with `68H`, length-prefixed, no checksum or stop byte — reliability is provided by TCP).

* * *

### 3. Message interaction

### 3.1 Interaction mode

-   **IEC 102 (request/response):**

-   **Unbalanced** (master/slave) transmission.
-   The slave (meter) never speaks unsolicited. The master sends a "call" request and the slave returns the matching response.
-   **Framing logic:** For long payloads, the master issues "request next frame"; the slave toggles its **FCB (Frame Count Bit)** to prevent loss or duplication.



-   **IEC 104 (unsolicited reporting):**

-   **Balanced** (client/server) transmission.
-   **Startup:** After the TCP connection is established, transmission is activated via a **U-frame (STARTDT)**.
-   **Spontaneous reporting:** When a switch changes state or a value crosses a threshold, the slave **immediately sends an I-frame** without waiting to be polled.
-   **Acknowledgement:** A **sliding-window** mechanism — **S-frames** acknowledge received sequence numbers, supporting back-to-back transmission.



### 3.2 Initialization flow

-   **102:** Link request → status response → reset link → begin poll.
-   **104:** TCP three-way handshake → U-frame activation (STARTDT) → general interrogation (Type 100).

* * *

### 4. ASDU (Application Service Data Unit) in depth

ASDU is where the actual business data lives.

### 4.1 Data focus

-   **IEC 102 ASDU:**

-   **Key types:** Type 11 (query accumulated energy for a specific period), Type 7 (accumulated energy with timestamp).
-   **Logic:** Feels like a "database query" — messages include both a start time and an end time.
-   **Tariff handling:** The ASDU carries energy readings across multiple tariffs (peak, shoulder, flat, off-peak).



-   **IEC 104 ASDU:**

-   **Key types:** Type 1 (status), Type 13 (floating-point measurement), Type 45 (control), Type 30 (SOE with millisecond timestamp).
-   **Quality descriptors:** Every data point carries quality bits — IV (invalid), NT (not-topical), SB (substituted), BL (blocked).



### 4.2 Timestamp semantics

-   **102 timestamps** denote a **"settlement point"** — e.g. "this is the energy settled at 14:00 on April 21".
-   **104 timestamps** denote an **"event instant"** — e.g. "the breaker tripped at 14:00:00.123".

* * *

### 5. Summary comparison

Attribute

IEC 60870-5-102

IEC 60870-5-104

Industry nickname

Energy-metering protocol

Network telemetry / dispatch protocol

Transport

Serial link layer (FT1.2)

TCP/IP (port 2404)

Who can initiate

Master-initiated only (request/response)

Bidirectional — slave may spontaneously report

Reliability guarantee

FCB toggling + checksum

TCP retransmission + sliding-window sequence numbers

Payload

Accumulated values, historical period readings

Real-time status, analog measurements, control commands

Frame terminator

Has a stop byte `16H`

No stop byte

Example ASDU

Type 11 (read historical interval)

Type 30 (SOE with millisecond timestamp)

* * *

**Bottom line:**

-   Building an **energy-metering system** or tallying electricity usage? Follow **IEC 102**.
-   Building a **substation monitoring system** with automated dispatch and remote control? Follow **IEC 104**.]]></description>
      
      <author>Admin</author>
      <pubDate>Tue, 21 Apr 2026 06:56:20 GMT</pubDate>
    </item>
  </channel>
</rss>