Thiết kế giao thức

M t s khía c nh chung c a vi c thi t k ộ ố ạ ủ ệ ế ế Định nghĩa rõ ràng các điểm truy cập dịch vụ SAPs  Có xu hướng che dấu hoàn toàn các tầng dưới với các tầng trên  Phá vỡ sự trừu t

Thi t k giao th c ế ế ứ

Giảng viên: Nguyễn Hoài Sơn

Bộ môn Mạng và Truyền thông máy tính Khoa Công nghệ thông tin

T i sao chúng ta c n thi t k giao th c ạ ầ ế ế ứ

Quy trình thi t k giao th c ế ế ứ

Các yêu c u khi thi t k giao th c ầ ế ế ứ

 Hiểu mục đích, yêu cầu

 Yêu cầu về chức năng: features, security,…

 Các yêu cầu khác: scale, time-to-market, cost, …

 Hiểu về những giới hạn

 Giới hạn về chức năng: Môi trường thực hiện

 Các giới hạn khác: giá thành, cân nặng, năng

lượng tiêu thụ, memory, CPU, …

 Hiểu về những thỏa hiệp có thể chấp nhận được

 Must vs nice-to-have

M t s khía c nh chung c a vi c thi t k ộ ố ạ ủ ệ ế ế

giao th c (1) ứ

 Quy mô thiết kế

 Chỉ là một phần trong thiết kế ứng dụng nào đó

 Nhằm tạo ra platform cho một môi trường cạnh tranh

 Mục đích thiết kế

 Giải pháp hoàn chỉnh cho một ứng dụng

 Tạo ra các gói đế sử dụng lại một cách mềm dẻo

 Sử dụng các gói có sẵn để tạo ra giải pháp cụ thể nào đó

 Tạo ra hay Sử dụng lại

 Sử dụng lại các công nghệ đã có

 Hưởng lợi từ kinh nghiệm, code, etc ít rủi ro

 Nhưng: Có thực sự đáp ứng mục đích, yêu cầu, chi phí, …

 Tạo ra công nghệ mới từ zero

Có thể tối ưu hóa phù hợp với quy mô, mục đích, yêu cầu sử dụng

M t s khía c nh chung c a vi c thi t k ộ ố ạ ủ ệ ế ế

giao th c (2) ứ

 Học từ những giải pháp liên quan

 Mượn các khái niệm và giải pháp

 nhưng chỉ ở chỗ nào có thể áp dụng được

 Tránh lỗi Xem xét các triến khai trên thực tế trước khi mượn

 Tránh “second system syndrome”

 Bám sát các yêu cầu trong quá trình thiết kế

 Một số cách thức đơn giản hóa

 Tối ưu hóa cho trường hợp chung

 Không phức tạp hóa vấn đề – Keep it simple stupid (KISS)

 Tránh các tùy chọn và tham số

 Nhớ rằng cuối cùng chúng ta sẽ phải thực thi thiết kế

M t s khía c nh chung c a vi c thi t k ộ ố ạ ủ ệ ế ế

 Định nghĩa rõ ràng các điểm truy cập dịch vụ (SAPs)

 Có xu hướng che dấu hoàn toàn các tầng dưới với các tầng trên

 Phá vỡ sự trừu tượng hóa- Leaky abstraction

 Phân tầng chặt chẽ không phải lúc nào cũng tốt

 Không nhất thiết phải che dấu bằng mọi giá

 Áp dụng cho thiết kế giao thức, lập trình và một số công việc khác

 By Joel Spolsky http://www.joelonsoftware.com/articles/LeakyAbstractions.html

 Tối ưu hóa bằng thông tầng (Cross-layer)

 Xử lý các vấn đề phụ thuộc vào các tầng dưới ở tầng trên và ngược lại

Thi t k giao th c có tính Trade-Offs… ế ế ứ

…giữa các yêu cầu và các hạn chế của môi trường

 Chức năng vs băng thông

 Khả năng mở rộng vs hiệu quả

 Chức năng vs đơn giản

 Một thiết kế để thực hiện một mục tiêu nào đó sẽ tác động ngược lại vào một mục tiêu khác

 Cần tìm kiếm sự thỏa hiệp hợp lý để thực hiện được chức năng yêu cầu với giá thành có thể chấp nhận được

Các bên truy n tin và vai trò ề

 Truyền tin điểm-điểm vs nhiều điểm

 Có bao nhiêu bên tham gia vào quá trình truyền tìn?

 Unicasting vs group-overlays vs multicasting

 Kiểu trao đổi thông tin nào được giả thiết?

 Truyền tin Client-server vs truyền tin ngang hàng

 Các bên có cùng vai trò hay có vai trò khác nhau?

 Truyền tin cuối-cuối vs trung gian vs hỗ trợ của

router

 Những thực thể nào có thể, có hoặc phải tham gia

vào quá trình truyền tin? Chúng có “thấy được” hay không?

Đ nh danh bên truy n tin ị ề

 Tên

 Định danh có thể đọc được để con người dễ nhớ (e.g., DNS

name, URI, URN)

 Hoặc được chọn ngẫu nhiên trong môi trường ad-hoc

 Các định danh này cần được chuyển đổi lẫn nhau

 Address books, dữ liệu phân tán(e.g., DNS, DHTs), giao thức

trao đổi, caching, cấu hình (thủ công), …

Đ ph c t p ộ ứ ạ

 Độ phức tạp giao thức

 Số lượng của giao thức, số lượng của tùy chọn

 Độ phức tạp trạng thái

 E.g., Số trạng thái và chuyển trạng thái, yêu cầu đồng bộ hóa

 Số chuyển trạng thái (tương tác) để đạt được kết quả

 Độ phức tạp tính toán

 Ví dụ: Mã hóa, định tuyến, tìm kiếm

 Vấn đề về tính tương thích

 Cần làm tương thích với các phiên bản cũ

 Khó khăn trong việc đưa ra chức năng mới, dễ dẫn đến sự phức tạp

Đ ph c t p đi u khi n ộ ứ ạ ề ể

 Để chạy hệ thống

 Có bao nhiêu tham số phải cấu hình?

 Cần bao nhiêu sự phối hợp (ví dụ giữa các tổ chức)?

 Có thể phát hiện được cấu hình sai không và cấu hình như thế nào?

 Xử lý tự động vs xử lý thủ công

 Theo dõi

 Những tham số nào? Như thế nào? Chu kỳ bao lâu?

 Xứ lý lỗi

 Giảm dần vs ngừng hoàn toàn hoạt động của hệ thống

 Làm thế nào để theo dõi và phát hiện lỗi?

 Làm thế nào để khôi phục lại hệ thống?

Tính kinh tế

 Truyền dữ liệu gắn với chi phí

 Rate, volume, packets, QoS, …

 Độ phức tạp thực thi gắn liền với chi phí

 Nhân công để thiết kế, thực thi và kiểm tra hệ thống

 Các thiết bị cần thiết

 Lợi nhuận gắn liền với độ phức tạp giao thức

 Định luật Metcalfe

 giá trị của một mạng truyền thông tỷ lệ với bình phương của số

người tham gia

M t s v n đ v thi t k giao th c ộ ố ấ ề ề ế ế ứ

 Hoạt động có trạng thái vs không trạng thái

 Số lượng thông tin cần duy trì khi trao đổi thông tin

 Khái niệm về “liên kết” hay “kết nối”

 Trạng thái này được lưu giữ tại đâu? (Tại một hay cả hai bên trong trường hợp giao tiếp điểm-điểm)?

 Nút cố định vs nút di động

 ảnh hưởng đến định tuyến, khả năng truy cập, …

 Truyền tin dựa vào hạ tầng mạng vs truyền tin kiểu ad-hoc/tự động

 Kiểu hạ tầng này được giả thiết?

 Bảo mật trong giao thức vs bảo mật dựa vào nơi khác

 Yêu cầu nào? (e.g., hạ tầng yêu cầu như PKI)

Đánh giá thi t k giao th c (1) ế ế ứ

 Khả năng thích ứng

 Khả năng thích ứng với các điều kiện môi trường khác nhau

(thay đổi chất lượng dịch vụ ở mức có thể chấp nhận được)

 Ví dụ: sự thích ứng về độ trễ playout và codec với truyền thông đa phương tiện

 Khả năng mở rộng

 Có thể làm việc trong các khoảng rộng của các tham số môi

trường

 Ví dụ điển hình: Số lương nodes

 Tốc độ truyền dữ liệu, tốc độ lỗi, độ dài đường truyền, độ trễ

 Số lượng và kích thước dữ liệu

 Hiệu quả

 Duy trì một mức độ overhead hợp lý

 Ví du: tiêu đề giao thức, mã hóa giao thức

 Số lượng tương tác giao thức, packets, bits, xử lý

Đánh giá thi t k giao th c (2) ế ế ứ

 Bảo mật

 Khả năng triển khai

 robustness (chống DoS, điểm lỗi duy nhất, etc.)

 Khả năng đưa ra thực tế theo từng bước

 Khả năng tương thích

 Tương thích với các phiên bản cũ và mới

 Khả năng điều khiển và quản lý

Kh năng m r ng ả ở ộ

Một câu đánh giá thiết kế điển :

“Thiết kế này không co dãn (scale) …”

 Tại sao?

 Câu này nói về điều gì?

 Tại sao lại phải như vậy?

Kh năng m r ng nói chung ả ở ộ

Thường dùng (không chỉ) trong truyền tin, là

 Khả năng của hệ thống hoạt động với nhiều điều kiện môi

trường khác nhau

 ngược lại là chỉ hạn chế với một điều kiện môi trường duy nhất

 Đánh giá trên một hay nhiều tham số đầu vào

 Khả năng sử dụng với khoảng tham số đầu vào có thể chấp

nhận được

 Gần như gắn liền với mức độ( và tính công bằng) sử dụng tài nguyên

 Liên quan đến học thuyết về độ phức tạp

 Phân chia mức độ sử dụng tài nguyên dựa trên đầu vào

Các cấp độ phức tạp: O(1), O(n), O(log n), O(nk), O(en)

Kh năng m r ng nh là m t th ả ở ộ ư ộ ướ c đo (1)

Khả năng mở rộng: Phía mạng

 Độ dài đường truyền (Số lượng hop, độ trễ, biến thiên độ trễ)

 Độ trễ do khoảng cách phụ thuộc tốc độ truyền ánh sáng + độ trễ xử lý/xếp hàng tài mỗi nút mạng

 Trên một host vs cùng mạng cục bộ vs cách 30 hops trên mạng

Internet

 < 1ms trên đường LAN vs vài giây qua GPRS hay truyền thông vệ tinh

 vs vài phút, vài giờ với trạm vũ trụ

 Độ trễ không đổi trên mạng cục bộ vs độ trễ chênh lệch vài giây với truyền tin vệ tinh

 do giao thức truy cập trung gian

Khả năng mở rộng: Phía ứng dụng

 Tốc độ cập nhật hay gửi yêu cầu

 Đo bởi số hoạt động trong 1 giây vs 1 giờ vs 1 ngày

 Thời gian giữa 2 cập nhật

 Kích cỡ dữ liệu

 Kích thước dữ liệu từ vài chục bytes đến10 GB

 Số lượng các bên tham gia (người dùng, mạng, hệ thống)

 Bao nhiêu bên thực hiện gửi

 Số luợng mỗi bên tham gia

 Ví dụ: vấn đề C10K: xử lý 10,000(s) máy khách với một máy

Kh năng m r ng: th c thi ả ở ộ ự

 Vấn đề C10K:

 Sự tương tác thường xuyên

 Các hoạt động chi phí cao như chấp nhận và đóng kết nối, bảo mật, …

 Multiplexing và xử lý xuất nhập dữ liệu

 Xử lý đa tiến trình vs đa luồng vs đơn luồng

 Vấn đề với hiệu quả cuộc gọi hệ thống (e.g., poll (), select ())

 Xử lý nhiều sự kiện sẽ tiêu tốn thời gian

 Truy cập dữ liệu

 Tìm kiếm dữ liệu trong ổ cứng khi truy cập file

 Ổ cứng là “nhanh” nếu không truy cập dồn

 Ví dụ: video-on-demand streaming

 Băng thông bus của hệ thống

 Tương tác với các tiến trình khác trên cùng một máy tính

Kh năng m r ng: th c thi(2) ả ở ộ ự

 Cân bằng tải

 Sử dụng chuỗi máy chủ để cân bằng tải

 Cân bằng tải sử dụng DNS, proxies

 Có thể xử lý phân tán để tăng khả năng truy cập

 Và giảm độ trễ truyền thông

 Vấn đề: cần phải đồng bộ dữ liệu giữa các máy chủ

 Khả năng mở rộng với các platform

 Thiết bị chạy bằng pin

Ví d : DNS ụ

 Tính chất then chốt

 Mô hình phân tán: sự hợp tác giữa các máy chủ

 Máy chủ dự trữ: tránh “single point of failure”

 Một máy chính và một hay nhiều hơn một máy phụ

 Cấu trúc phân tầng của tên miền

 Để có thể quản lý và hoạt động phân tán

 Giao phó trách nhiệm một cách dễ dàng

 Mục đích chung: không chỉ dùng với địa chi IP

 Có thể ánh xạ tới bất cứ thông tin gì

 Khả năng mở rộng được thực hiện như thế nào?

 Tìm kiếm từ dưới lên: khai thác tính cục bộ của các yêu

cầu

Đạt hiệu quả nhờ caching

Ví d : DNS (2) ụ

 Phân tán, ủy thác

 Dynamic Delegation Discovery System

(DDDS): Ánh xạ chuỗi ký tự vào dữ liệu

Kh năng thích ng ả ứ

 Tính chất của mạng có thể thay đổi nhiều và nhanh

 Phục thuộc vào hoạt động của các bên tham gia

 Phụ thuộc vào tải do các máy khác

 Phụ thuộc vào sự thay đổi định tuyến mạng (e.g., để đáp ứng với sự hỏng hóc)

 Tính chất của ứng dụng có thể thay đổi nhiều

 Kích thước dữ liệu

 Số lượng các bên tham gia

 Sự thay đổi thường không thể dự đoán trước được

Bài t p 2 ậ

 Tự thiết kế một giao thức mạng và trình bày thiết kế

theo các mục sau:

 Mục đích, yêu cầu của giao thức

 Chi tiết về giao thức thiết kế

 Ưu/nhược điểm của giao thức thiết kế với các giao

thức khác

 Thời hạn nộp bài: Thứ 2 ngày 15 tháng 10 năm2007

 Địa chỉ nộp bài: hoaison@gmail.com and

sonnh@coltech.vnu.vn

 Tiêu đề mail: [Network programming K49-MMT][2] Your name