Hệ thống dò tìm đại diện tự động (DDDS) là một thành phần cơ bản quan trọng của ENUM. Nó được đưa vào ENUM để giải quyết các vấn đề gặp phải khi thể hiện các tài nguyên gắn kết với số ENUM một cách tối ưu nhất và hỗ trợ các giải pháp chuyển đổi chuỗi số thành dữ liệu động tốt nhất.
DDDS được sinh ra như kết quả của một hướng nghiên cứu mới của nhóm làm
việc chuyên trách của IETF về "tên tài nguyên thống nhất" Uniform Resource
Names (URN) để giải quyết vấn đề: làm thế nào có thể tìm kiếm được thông tin về một URN nếu trong URN không chứa các thông tin định vị dịch vụ mạng (chẳng hạn không chứa tên hoặc địa chỉ máy chủ truy vấn). Một hệ thống được đưa ra có thể sử dụng một cơ sở dữ liệu luật dùng để áp đặt lên URN nhằm tìm ra thông tin trên từng đoạn của URN. Đầu tiên, hệ thống này được gọi là dịch vụ
dò tìm thiết bị truy vấn RDS (Resolver Discovery Service), chỉ dùng được với các URN. Sau này, phương pháp tương tự được áp dụng trên các chuỗi không phải URN và trở thành DDDS.
DDDS được mô tả bởi một hệ thống các tài liệu chuẩn của IETF, gồm 5 phần với các RFC số 3401, 3402, 3403, 3404, 3405. DDDS được định nghĩa đơn giản là một thuật toán tổng quát nhằm áp dụng một luật chuyển đổi chuỗi thu nhận được một cách động lên một chuỗi đơn của ứng dụng. Nói cách khác, DDDS là phương pháp dùng để chuyển đổi chuỗi thành dữ liệu một cách động, sử dụng để hỗ trợ cấu hình động cho các hệ thống uỷ quyền (delegation).
Để làm được việc này, DDDS sử dụng các luật chuyển đổi chuỗi áp đặt tuần tự và lặp lại lên các chuỗi đầu vào cho tới khi điều kiện kết thúc đạt được và ánh xạ kết quả vào các dữ liệu chứa trong cơ sở dữ liệu DDDS.
Việc thực hiện DDDS được mô tả qua thuật toán sau:
Luật bắt đầu (First well known rule)
Tìm khóa trong CSDL DDDS
Áp dụng các luật lên các chuỗi duy nhất cho tới khi kết quả không rỗng nhận được thỏa mãn yêu cầu của ứng dụng
Đầu ra của luật cuối cùng chính là kết quả cần tìm của ứng dụng
Kết thúc luật cuối cùng chưa ?
Chuỗi đầu vào duy nhất của ứng dụng
Khóa đầu tiên Khóa Tập hợp luật Tập hợp luật Khóa Sai Đúng CSDL DDDS luôn nhận 1 khóa và trả về 1 luật
Đầu vào là luật và chuỗi ứng dụng Đầu ra là khóa hoặc kết quả
Nếu luật chưa kết thúc thì đầu ra của nó là khóa mới để áp dụng
tiếp tìm các tập hợp luật khác
Đầu tiên, chuỗi đơn đầu vào của ứng dụng được áp đặt một luật gọi là luật bắt đầu (First Well Known 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, hoặc 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ừ MIME3 "Content-Ids" như sau:
urn:cid:199606121851.1@bar.example.com
Để 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 hai 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 "!").
3
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.
Chi tiết thêm về thuật toán DDDS tham khảo RFC34024.
Việc 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]5. 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 khóa sẽ có dạng một truy vấn tên miền thông thường, 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 cần được đặc biệt quan tâm khi áp dụng ở Việt Nam do các trường NAPTR được sử dụng có chứa mã tiếng Việt. Tuy nhiên trong khuôn khổ thời gian có hạn, luận văn 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
4
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.
Để 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.
Cấu trúc định dạng, khai báo các bản ghi NAPTR trong hệ thống DNS
Như đã đề cập ở phần trên, cấu trúc khai báo các bản ghi NAPTR trong hệ thống DNS khi được thể hiện một cách đầy đủ có dạng như sau:
ENUM-Domain IN NAPTR order preference flag service regexp replacement
Tên miền IN NAPTR thứ tự mức ưu tiên(lựa chọn) cờ dịch vụ biểu thức thay thế.
Với cấu trúc này, định dạng gói tin NAPTR sẽ bao gồm:
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 12. Định dạng gói tin NAPTR
Ở đây các chuỗi ký tự và tên miền được định nghĩa trong RFC1035.
THỨ TỰ là một số nguyên không dấu 16 bit biểu thị thứ tự mà bản ghi cần được xử lý được sắp xếp từ nhỏ đến lớn để có thể phản ánh đúng thứ tự các luật. THỨ TỰ được bắt buộc sử dụng khi có nhiều bản ghi NAPTR được trả về trong cùng một dữ liệu phản hồi, khi đó bản ghi NAPTR có thứ thự nhỏ hơn sẽ được sử dụng. 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 phương thức viết lại các trường trong bản ghi, do ứng dụng xác định. CỜ được thể hiện dưới dạng một chuỗi ký tự, chứa tham số ảnh hưởng tới lần truy vấn tiếp theo, thường được dùng để tối ưu hoá quá trình truy vấn. Cờ "u" được hiểu là luật này là luật áp dụng để kết thúc chu trình và dữ
liệu trả về là một chuỗi theo chuẩn nhận dạng tài nguyên thống nhất (URI6
). 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. DỊCH VỤ được thể hiện, khai báo trong bản ghi NAPTR dưới dạng một chuỗi ký tự, nó chỉ ra thủ tục phân giải và dịch vụ phân giải sẽ sẵn sàng khi việc viết lại được thực hiện thông qua các trường "biểu thức" và "thay thế".
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.
Trong bản ghi NAPTR, trường "thay thế" (replacement) có thể là một tên miền
mới để truy vấn tùy theo các giá trị có thể của trường "cờ". Trường này được sử dụng khi trường "biểu thức" là một phép thay thế đơn giản. Bất kỳ giá trị nào của trường này cũng phải là một tên miền đầy đủ (full qualified domain name). Trường "biểu thức" (regexp - regular expression) chứa một chuỗi biểu thức
thay thế mà khi áp dụng vào chuỗi nguyên thuỷ sẽ tìm ra được tên miền nào sẽ được truy vấn tiếp theo.
Ngoài ra, trong các bản ghi NAPTR còn có sử dụng trường "độ ưu tiên" (preference) là một số nguyên không dấu 16 bit, thường được dùng khi có nhiều bản ghi NAPTR được trả về, trong đó có cả các thứ tự giống nhau. Trường này tương tự như trường độ ưu tiên trong bản ghi MX của DNS và được các nhà quản trị sử dụng để lái dịch vụ tới các máy chủ khác có khả năng xử lý tốt hơn.
Một lưu ý là tất cả các quá trình xử lý thay thế và truy vấn đều được ứng dụng thực hiện, bản thân hệ thống DNS không thực hiện tính toán xử lý nào.
Ở đâ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à đương nhiên 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, hoặc 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...
+ 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ử dụng từ lâu trong rất nhiều môi trường phát triển, như trong các thư viện lập trình C, các ứng dụng unix như sed, awk, grep... hay trong cả các hệ thống phát triển mới như Microsoft Visual C++, .NET...
Các mẫu sử dụng trong RE được biên dịch thành các mã bytecode thực thi nên tốc độ của nó thường rất nhanh, khả năng tùy biến cao và hay được ứng dụng trong các ngôn ngữ lập trình cần tác động lên chuỗi ký tự.
RE tương đối nhỏ và giới hạn. Không phải tất cả các thao tác chuỗi dữ liệu đều có thể xử lý được với RE. Chỉ có một số giới hạn các thao tác được RE hỗ trợ, nhưng tập hợp lại thường các biểu thức RE lại trở nên hết sức phức tạp. Để diễn giải cú pháp RE, trước hết ta xem xét các mẫu tìm kiếm.
+ Ký tự "ứng hợp" (matching character):
Đa phần các ký tự được sử dụng để ứng với việc tìm kiếm chính bản thân chúng. Ví dụ các ký tự "test" dùng để tạo nên mẫu tìm kiếm cho chuỗi "test". Tuy nhiên, có một số ngoại lệ ở các ký tự đặc biệt. Các ký tự này có các ý nghĩa nhất định trong mẫu tìm kiếm.
^ chỉ ra vị trí đầu chuỗi. Ví dụ "^abc" hợp với các chuỗi bắt đầu bởi chuỗi con "abc".
$ chỉ ra vị trí cuối chuỗi. Ví dụ "abc$" hợp với các chuỗi kết thúc với chuỗi con "abc".
. ứng với mọi ký tự trừ ký tự xuống dòng. Ví dụ "acb.d" hợp với "abced", "abcfd", "abcgd"...
"[" và "]" : 2 ký tự này dùng để tạo ra một phân lớp ký tự, tức là tập hợp các ký tự mà ta muốn tìm kiếm. Các ký tự có thể được liệt kê lần lượt, hoặc liệt kê trong 1 dải ký tự bằng cách đưa ra ký tự bắt đầu và kết thúc phân cách bằng dấu
trong cặp [ ] các ký tự đặc biệt khác như $ bị mất ý nghĩa và trở thành các ký tự thông thường. Tuy nhiên ký tự "^" sử dụng trong cặp [ ] có nghĩa là phủ định của tập ký tự. Ví dụ "[^5]" dùng để tìm các ký tự khác "5".
Ký tự "\" được coi là ký tự escape, các ký tự đi kèm với nó sẽ tạo ra các mã đặc biệt. Nó cũng được sử dụng để tạo ra các mã thông thường của các ký tự đặc biệt, ví dụ "\\" để chỉ mã ký tự "\", hay \[ để chỉ ra ký tự "[".
\d ứng với các số thập phân, hay thuộc lớp [0-9].
\D ứng với các ký tự không phải số thập phân, hay [^0-9].
\s ứng với mọi loại khoảng cách trắng, tức là [ \t\n\r\f\v].
\S ứng với các ký tự không phải khoảng cách trắng, hay [^ \t\n\r\f\v].
\w ứng với mọi ký tự chữ và số, tương đương với [a-zA-Z0-9_].
\W ứng với mọi ký tự không phải chữ và số, hay [^a-zA-Z0-9_].
\< và \> ứng với bắt đầu và kết thúc một từ (word).
\( và \) sẽ đặt các biểu thức ở giữa vào một nhóm tham chiếu, đồng thời lưu
tạm các ký tự tìm được trong phạm vi nhóm này vào bộ nhớ (có thể chứa 9 nhóm trong cùng 1 RE) và có thể được sử dụng với tham chiếu là \1 đến \9.
| ứng với mã "hoặc" (OR). + Các mã lặp:
* là mã đặc biệt chỉ ra tổ hợp lặp lại 0 hay nhiều hơn lần của ký tự đi cùng.
+ chỉ ra tổ hợp lặp 1 hay nhiều hơn lần của ký tự đi cùng.
? chỉ ra tổ hợp 1 hay 0 lần của ký tự đi cùng.
{m,n} chỉ ra tổ hợp của ít nhất m lần, nhiều nhất n lần lặp của ký tự đi cùng.
Với các cơ sở này, ta hãy xem xét lại ví dụ về cách khai báo bản ghi NAPTR đã nêu ở trên.
$ORIGIN 5.1.1.6.2.2.8.4.4.8.e164.arpa.
IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:tantm@vnnic.net.vn!". IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:tantm@vnnic.net.vn!".
IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+8448226115!".
IN NAPTR 100 10 "u" "http+E2U" "!^.*$!http://www.vnnic.net.vn!".
Trong ví dụ này, việc khai báo bản ghi NAPTR chỉ dùng cờ "u" để chỉ ra kết quả