Download miễn phí Đề tài Nghiên cứu các vấn đề kỹ thuật công nghệ bản chất của ENUM - Hệ thống đánh số điện tử
Trường ĐH Kỹ thuật Công nghệ Tp.HCM, 2011
Sơ lược:
Tập trung vào nghiên cứu các vấn đề kỹ thuật công nghệ bản chất của ENUM - Hệ thống đánh số điện tử.
Chương 1. Tổng quan về ENUM: Giới thiệu các khái niệm chung về ENUM, các mô hình áp dụng ENUM, sự phát triển ENUM trên thế giới.
Chương 2. Cơ sở kỹ thuật công nghệ của ENUM, các mô hình kiến trúc thủ tục ENUM.
Chương 3. Các vấn đề chính sách đối với ENUM. Tập trung nghiên cứu các vấn đề nảy sinh đối với ENUM và các khung chính sách cần xây dựng
Chương 4. Cơ sở áp dụng thực tế của ENUM. Mô hình triển khai thử nghiệm và kết quả.
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
t đầu (First WellKnown Rule). Luật này do ứng dụng định ra, chứ không phải lấy từ cơ sở dữ liệu. Luật này
nhằm tìm ra khoá đầu tiên dùng để truy vấn cơ sở dữ liệu DDDS.
Với khoá tìm được, truy vấn cơ sở dữ liệu DDDS sẽ tìm được luật áp dụng tiếp theo. Luật này
áp dụng lên chuỗi đầu vào sẽ cho khoá mới, hay cuối cùng là kết quả đầu ra mong muốn.
Để thấy được sự phức tạp của các biểu thức áp dụng trong DDDS, ta xem xét ví dụ sau:
Xem xét 1 URN có định dạng lấy từ MIME17 "Content-Ids" như sau:
urn:cid:[email protected]
Để truy vấn thông tin về URN này, ứng dụng thực hiện theo quy ước, ở đây việc đầu tiên là
tìm thông tin về dạng dữ liệu MIME, bằng cách tìm chuỗi dữ liệu giữa 2 dấu ":" đầu tiên. Kết
quả thu được là "cid"
Ứng dụng cũng được quy ước trước là với chuỗi thu được, nó phải thêm vào một đuôi
"urn.arpa" để có được một khoá tìm kiếm đầy đủ. Khoá ở đây là "cid.urn.arpa"
Với truy vấn tên miền "cid.urn.arpa", ứng dụng thu được một bản ghi NAPTR như sau:
cid.urn.arpa.
;; order pref flags service regexp replacement
IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
Do ở đây chỉ có 1 trường NAPTR trả về nên không có vấn đề sắp xếp thứ tự ưu tiên. Áp dụng
luật thu được trên chuỗi URN ban đầu ta thu được chuỗi "example.com" (thành phần thứ 2
theo như biểu thức thay thế chỉ ra, giữa 2 dấu "!")
Truy vấn tiếp tên miền "example.com" ta thu được:
example.com.
;; order pref flags service regexp replacement
IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com.
17 Multimedia Internet Mail Extension
E164 - ENUM GVHD: Ths.Nguyễn Đức Quang
Nguyễn Minh Hưng - 106102046 Trang 33
Chi tiết thêm về thuật toán DDDS tham khảo [RFC3402]18.
II.3.2. Phân bố các luật DDDS qua DNS
Để có thể phân bố các luật DDDS một cách hiệu quả và đơn giản, DDDS sử dụng cơ sở dữ
liệu DNS như một cơ sở dữ liệu phân bố luật, định nghĩa theo [RFC3403]19. Các khoá ở đây là
các tên miền, và các luật được mã hoá bằng các trường NAPTR. Một truy vấn khoá sẽ có dạng
một truy vấn tên miền thông thường, và kết quả trả về sẽ là một loạt các bản ghi NAPTR chứa
các luật cần truy vấn. RFC3403 cũng đồng thời thay thế cho RFC2915, và được coi là định
nghĩa chính thức của NAPTR. Các mô tả chính như sau:
Bộ mã được sử dụng trong các trường của NAPTR là UTF-8. Do đó nếu đầu vào/ đầu ra của
các biểu thức có chứa các mã nằm ngoài bộ mã UTF-8 thì phải được biểu diễn bằng các tham
chiếu theo kiểu một chuỗi byte để có thể thoả mãn được. Điều này là do các biểu thức thường
được sử dụng là dạng mở rộng của biểu thức dùng trong hệ POSIX. Điều này cần được đặc
biệt quan tâm khi áp dụng ở Việt Nam khi các trường NAPTR được sử dụng có chứa mã tiếng
Việt. Tuy nhiên trong khuôn khổ tài liệu này sẽ không bàn đến vấn đề mã đa ngữ trong các bản
ghi NAPTR.
Tất cả các bản ghi DNS đều được gán một thời gian sống (time-to-live) tính bằng giây. Sau khi
bản ghi được lấy về thì nó chỉ có giá trị trong khoảng thời gian bằng time-to-live. Sau thời gian
đó bản ghi coi như không còn giá trị, và phải được truy vấn lại. Điều này cũng ảnh hưởng tới
việc lưu trữ các luật DDDS, vì ứng dụng phải đảm bảo là chỉ áp dụng các luật chưa bị quá hạn
time-to-live. Nếu luật được áp dụng bị quá hạn, ứng dụng phải bắt đầu lại từ đầu việc áp dụng
toàn bộ thuật toán.
Cấu trúc của khóa: Khóa phải là một tên miền được cấu tạo đúng cú pháp chuẩn
Để tìm kiếm 1 tập hợp luật, ứng dụng phải sử dụng một truy vấn DNS tiêu chuẩn để tìm bản
ghi NAPTR ứng với tên miền đã cho.
18 DDDS Part two - The Algorithm
19 DDDS Part Three: The Domain Name System (DNS) Database
E164 - ENUM GVHD: Ths.Nguyễn Đức Quang
Nguyễn Minh Hưng - 106102046 Trang 34
Định dạng gói tin NAPTR như sau:
1 15
THỨ TỰ (ORDER)
LỰA CHỌN (PREFERENCE)
CỜ (FLAGS)
DỊCH VỤ (SERVICES)
BIỂU THỨC (REGEXP)
THAY THẾ (REPLACEMENT)
Hình 142. Định dạng gói tin NAPTR
Ở đây chuỗi ký tự và tên miền được định nghĩa trong RFC1035
THỨ TỰ là một số 16 bit biểu thị thứ tự mà bản ghi cần được xử lý để có thể phản ánh đúng
thứ tự các luật. Thứ tự được sắp xếp từ nhỏ đến lớn. Các bản ghi có cùng thứ tự được coi là
cùng luật, và việc xử lý sẽ phụ thuộc vào các trường LỰA CHỌN và DỊCH VỤ
LỰA CHỌN cũng biểu thị thứ tự ưu tiên trong việc xử lý DDDS, nó chỉ ra thứ tự thực hiện
trong trường hợp các trường THỨ TỰ là giống nhau. Ứng dụng có thể tìm các bản ghi có giá
trị LỰA CHỌN cao hơn nếu nó muốn (ví dụ trường hợp nó không hỗ trợ tốt dịch vụ hay thủ
tục nào đó)
Ứng dụng chỉ được xác định 1 THỨ TỰ để xử lý, trong khi nó có thể thay đổi các bản ghi để
có LỰA CHỌN tốt hơn
CỜ là chuỗi dùng để xác định cách viết lại các trường trong bản ghi, do ứng dụng xác
định.
DỊCH VỤ là chuỗi xác định các tham số dịch vụ phù hợp cho hướng chuyển giao này, cũng do
ứng dụng xác định
BIỂU THỨC REGEXP chứa chuỗi thay thế được áp dụng cho chuỗi đầu vào để có được tên
miền tiếp theo để truy vấn tiếp. Biểu thức chỉ được áp dụng cho chuỗi đầu vào, chứ không áp
dụng cho các chuỗi trung gian trong quá trình xử lý bản ghi.
THAY THẾ là chuỗi sử dụng để thay thế chuỗi trong trường hợp thay thế đơn giản. Cùng với
BIỂU THỨC để tạo nên một biểu thức thay thế đầy đủ sử dụng trong DDDS
E164 - ENUM GVHD: Ths.Nguyễn Đức Quang
Nguyễn Minh Hưng - 106102046 Trang 35
Ở đây xuất hiện vấn đề xung đột trong các bản ghi NAPTR. Vì các bản ghi NAPTR trong
cùng 1 khoá (một tên miền) có thể được sử dụng cho nhiều dạng ứng dụng khác nhau (ví dụ
ENUM và URI có thể cùng truy vấn 1 tên miền nào đó), do đó luật trả về trong các NAPTR có
thể sẽ chỉ thích hợp với 1 ứng dụng nào đó, và không thích hợp với các ứng dụng còn lại. Cơ
chế xử lý là một trong các cách:
• Sử dụng các tên miền khác nhau cho các ứng dụng khác nhau
• Biểu thức phải được viết để có thể nhận dạng được ứng dụng truy vấn. Chẳng hạn biểu
thức dùng cho ENUM có thể được viết để nhận biết được dấu + trước chuỗi số đầu vào
• Sử dụng các trường "cờ" khác nhau, hay các trường "dịch vụ" khác nhau.
Một vấn đề khác cần chú ý là các dữ liệu luật ghi trong các bản ghi DNS phải được thể hiện
đúng dạng chuẩn DNS quy định trong [RFC1305], do đó với các biểu thức chứa các ký tự đặc
biệt như "\" thì trong các file chứa dữ liệu DNS, nó phải được biến đổi thành "\\" v.v.
II.4. Biểu thức (Regular Expression)
Biểu thức Regular Expression, gọi tắt là RE có thể coi là một ngôn ngữ lập trình chuyên biệt
nhỏ gọn, chuyên sử dụng để xử lý các chuỗi ký tự thông qua việc định ra các "luật xử lý". Với
RE, ta có thể chỉ ra các mẫu (pattern) mà ta muốn tìm kiếm, và các hành động áp dụng lên
chuỗi trong trường hợp phát hiện đúng (match) các mẫu đó trong chuỗi, với các hành động
như thay thế (replace), hay phân chia chuỗi (split).
RE được s...