Đánh giá mã nguồn Quake 3: Mô hình mạng (2012)

Mô hình mạng

• Mô hình mạng của Quake 3 là phần thanh lịch nhất của engine, nhấn mạnh rằng trong môi trường tốc độ cao, thông tin không được nhận ở lần truyền đầu tiên thì không đáng để gửi lại.
• Sử dụng UDP/IP và không dùng truyền tải tin cậy của TCP/IP vì nó gây ra độ trễ.
• Ngăn xếp mạng được mở rộng thành hai lớp loại trừ lẫn nhau: mã hóa dùng khóa chia sẻ trước và nén dùng khóa Huffman được tính toán trước.
• Hệ thống ở phía máy chủ nổi bật ở chỗ vừa giảm thiểu kích thước của datagram UDP vừa bù đắp cho sự thiếu tin cậy của UDP.

Kiến trúc

• Phía client khá đơn giản: ở mỗi frame, nó gửi lệnh lên server và nhận cập nhật trạng thái trò chơi.
• Server phải truyền bá trạng thái trò chơi tổng thể đến từng client và phải tính đến việc mất gói UDP.
• Ba thành phần chính: trạng thái trò chơi tổng thể, việc truyền lệnh của client qua Netchannel, và snapshot lưu 32 trạng thái trò chơi gần nhất trong một mảng vòng.

Hệ thống snapshot

• Khi server gửi bản cập nhật cho client, nó luôn sao chép trạng thái trò chơi tổng thể vào slot lịch sử tiếp theo của client rồi so sánh với các snapshot khác.
• Nếu không có snapshot hợp lệ, nó dùng "snapshot giả" để tạo bản cập nhật đầy đủ.
• Khi client xác nhận đã nhận được bản cập nhật trước đó, chỉ bản cập nhật một phần mới được gửi đi.
• Ngay cả khi gói tin bị mất, quy trình vẫn giống như vậy: thông tin chưa từng được nhận trước đó và thông tin mới sẽ được gửi trong một thông điệp duy nhất.

Khả năng chịu đựng trong bộ nhớ và C

• Quake3 so sánh các snapshot mà không cần introspection; vị trí của từng trường được cấu hình trước thông qua mảng và chỉ thị tiền xử lý.
• Sử dụng cấu trúc netField_t để định nghĩa vị trí và kích thước của các trường, từ đó truyền các khác biệt qua mạng.

Chia nhỏ trước

• Mô-đun NetChannel chia thông điệp thành các khối 1400 byte để gửi, giúp tránh việc router phải phân mảnh gói.
• Việc router phân mảnh rất tốn kém vì ở đầu vào mạng, gói có thể bị chặn, còn ở đầu ra mạng thì phải chờ đủ mọi mảnh.

Thông điệp tin cậy và không tin cậy

• Hệ thống snapshot bù đắp cho các datagram UDP bị mất trên mạng, nhưng một số thông điệp và lệnh vẫn bắt buộc phải được chuyển tới nơi.
• Sự đảm bảo này được trừu tượng hóa thông qua NetChannel.

[GN⁺]

Ý kiến trên Hacker News

• Bài viết này rất thú vị, các bài trước đó cũng vậy. Nhưng công việc hiện tại quá nhàm chán nên không còn năng lượng cho các dự án làm vì sở thích.
• Tôi lần đầu nghe thuật ngữ "Isochronous" khi FireWire ra mắt, và nó được nhắc đến như cơ sở biện minh cho việc dùng UDP. Đây hiện là phần quan trọng trong các đặc tả USB/Thunderbolt.
• Liên kết đến bài đầu tiên trong loạt bài: https://fabiensanglard.net/quake3/index.php
• Tính năng dự đoán và hiệu chỉnh độ trễ rất thú vị, và không dùng operational transform (OT) phức tạp. Cách này đơn giản hơn, đồng thời trạng thái dùng chung cần một nguồn chân lý độc lập thay vì là tài liệu chỉnh sửa cộng tác, nên việc phát triển nhanh hơn và hiệu năng tốt hơn.
• Mã mạng của client Q3A gốc hoạt động tốt trên LAN, nhưng khi chơi từ xa thì nhạy với độ trễ. Một trong những thay đổi thú vị của Quake Live là mã mạng được cập nhật cho việc chơi từ xa. Kết nối Internet nói chung cũng đã được cải thiện theo thời gian.
• Có vẻ như trang web đang bị HN Hug of Death: <kết nối bị hết thời gian chờ>
• Đây là bài rất hợp để đọc vào sáng thứ Bảy, vừa nhâm nhi chậm rãi một tách mate. Một niềm vui nhỏ của cuộc sống.
• Hỏi: Có tài liệu nào để tìm hiểu các cách tiếp cận hiện đại đối với giao thức game thời gian thực không?
• Chắc là số ID của snapshot cũng được gửi tới client để xác nhận?
• Liệu vẫn còn middleware mã nguồn mở chống đạn nào không?