Xử lý thiết lập là một xử lý đơn được sử dụng để thêm dữ liệu vào DHT; ngược lại, tìm kiếm là xử lý thu hồi những dữ liệu đó từ DHT. Một bản ghi logic để thiết lập được tạo ra từ 2 phần, thứ tự được lưu trữ kề nhau trong bộ nhớ (tạm gọi là “k-object”): một khóa 16 byte và 16 byte dữ liệu nằm theo sau dữ liệu tổng hợp danh sách các thẻ meta. Đặc thù khóa và dữ liệu 16 byte đó là các hàm băm MD4 của một vài thông tin (ví dụ như: tên người sở hữu file,…).
Danh sách các thẻ meta là tập hợp của các thẻ meta, mỗi một thành phần là một cặp <tên, giá trị>. Tên có thể là một nstring tùy ý hoặc 3 byte nstring. Giá trị của một thẻ meta có thể là một nstring hoặc trong một vài trường hợp (filesize, bitrate, availability) thì là 4-byte unsigned long. k-object là một mã hóa nhị phân
của danh sách được tạo ra bởi 2 hàm băm và một biến số của dictionaries và intergers (dictionaries và intergers là 2 kiểu cơ bản trong BitTorrent).
Chú ý: “nstring” ở đây được định nghĩa như thứ tự của các byte trong bảng mã ASCII, tiền tố là một unsigned short int trong định dạng little-endian để mô tả chiều dài của chuỗi.
Ví dụ: chuỗi “abc” được mã hóa sang dạng nstring như sau. 0x03, 0x00, ‘a’, ‘b’, ‘c’
Danh sách của các thẻ meta được thêm vào trước một số unsigned long int trong định dạng little-endian cho biết số lượng thẻ meta trong danh sách. Tóm lại, cấu trúc của một k-object là: key-hash[16], related-hash[16], số lượng thẻ meta [4], meta1, meta2, …, metaN.
Peer nhận một yêu cầu thiết lập (PUBLISH) được hỗ trợ để thực hiện theo và lưu trữ k-object vào một cơ sở dữ liệu nội bộ được đánh chỉ định bởi key-hash của nó (hàm băm đầu tiên trong 2 hàm băm); việc đánh chỉ định giúp cho việc tìm kiếm dễ dàng hơn. Thủ tục đệ quy được dùng để tìm kiếm dựa trên tìm kiếm node của Kademlia. Trong Overnet, tìm kiếm được thực thi theo thứ tự của các phiên làm việc “OVERNET_SEARCH / OVERNET_SEARCH_NEXT”.
Chú ý: từ tính chất của các client cho thấy lưu trữ nội bộ điều khiển tái thiết lập theo cách: tái tạo các khóa (ví dụ như với các bản ghi khác nhau có cùng hàm băm thứ nhất) được phép, miễn là hàm băm thứ hai khác nhau. Nếu hàm băm thứ hai cũng giống nhau thì bản ghi được lưu trữ trước sẽ bị xóa đi trước khi thêm một bản ghi mới. Danh sách các thẻ meta không ảnh hưởng gì trong trường hợp này.
3.2.3. Xử lý thiết lập
Overnet không phải là mục đích tổng quan của Kademlia overlay network mà chỉ là một thiết kế đặc biệt để thiết lập thông tin về định vị để tải các file được xác định bởi các thông tin các nhân (hàm băm của nội dung file, tên file, kích cỡ của file, kiểu file, định dạng file, …). Để thực hiện yêu cầu đó, thiết lập được cấu trúc hóa theo 2 bước xử lý sau:
Đầu tiên, các từ khóa thu được từ tên file bằng việc chuyển nó thành chữ thường, thay tất cả các ký tự không phải chữ cái, con số thành các ô trống và cắt chuỗi thành các chuỗi con sao cho không còn ô trống. Sau đó, lấy hàm băm MD4 của một vài từ khóa đầu tiên và mỗi một hàm băm như vậy được sử dụng làm các khóa, k-object lưu trữ hàm băm khóa. Hàm băm MD4 của nội dung file và thiết lập của các thẻ meta mô tả tên file, kiểu, định dạng, kích cỡ,.. được lưu trữ trong thư mục phân tán thông qua giao thức đệ quy OVERNET_SEARCH (chính xác là tìm kiếm node) theo sau các yêu cầu OVERNET_PUBLISH. Như đã nói ở trên, các từ khóa không được lưu trữ trong các thẻ meta hoặc bất cứ đâu trong k-object mà chúng được gửi đi với các OVERNET_PUBLISH_REQUEST, chỉ có các hàm băm của chúng được sử dụng như các khóa (một sao chép của các khóa được đặt ở đầu k-object). Các thẻ meta đã sử dụng trong bước này chỉ bao gồm các thành phần của file (tên file, độ dài của file, định dạng file, kiểu file,…).
3.2.3.2. Tìm kiếm nguồn
Sử dụng hàm băm của nội dung file như là khóa. Hàm băm của peer đang lưu giữ file đó (thông thường giống như peer gửi yêu cầu OVERNET_PUBLISH), và cùng với một thẻ meta có tên là “loc” được lưu trữ trong thư mục phân tán. Giá trị của thẻ “loc” là một URI. Có 2 định dạng URI:
• http://ip_addr:port: ip_addr là địa chỉ của máy lưu trữ file, port là cổng TCP để kết nối tới và tải file đó về.
• http://hash:ip_addr:port: hash là node ID của máy lưu trữ file, ip_addr là địa chỉ của máy lưu trữ file, port không phải là cổng của TCP bởi vì máy bị firewall/NAT nên cổng TCP không truy nhập được. Ở đây, port là cổng của Overnet UDP của nó. Thực hiện tải dữ liệu vẫn được xử lý nếu peer tải dữ liệu không bị firewall. Trong trường hợp đó, nó phải gửi tới ip_addr:port một gói OVERNET_FIREWALL_CONNECTION có chứa cổng TCP của nó; sau đó máy lưu trữ sẽ thử gọi trả lại bằng việc mở một kết nối TCP với peer tải file. Nếu thành công, nó sẽ gửi lại một gói OVERNET_FIREWALL_CONNECTION_ACK để chỉ thị cho peer tải file gửi yêu cầu thông qua kết nối mới được thiết lập. Ngược lại, nó sẽ gửi mọt
gói OVERNET_FIREWALL_CONNECTION_NACK để đónh phiên làm việc. Chú ý răng: hàm băm trong URI giống như hàm băm thứ hai trong yêu cầu OVERNET_PUBLISH.
Trong bất cứ trường hợp nào, mục đích của “loc” URI là để trỏ tới node lưu trữ file được chia sẻ và đưa ra chỉ dẫn làm thế nào để kết nối tới node đó để khởi tạo tiến trình tải dữ liệu.
Sau đây là hai ví dụ về k-object:
unsigned char kob1[] = {
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, /* hàm băm chỉ số */ 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, /* hàm băm quan hệ */ 3,0,0,0, /* số lượng thẻ meta trong danh sách thẻ meta */
EDONKEY_MTAG_STRING, /* = 0x02: một thẻ string-valued theo sau*/ 1,0, /* tên của nó có độ dài bằng 1 */
EDONKEY_STAG_NAME, /* = 0x01: thẻ "filename" */
10,0, /* giá trị của nó có độ dài bằng 10 */ 'M','y',' ','l','o','v','e','.','b','y', /* tên file */
EDONKEY_MTAG_DWORD, /* = 0x03: thẻ tiếp theo có kiểu DWORD (unsigned long int) */
1,0, /* tên của nó có độ dài bằng 1 */ EDONKEY_STAG_SIZE, /* = 0x02: thẻ "filesize" */
0x80,0x0d,0,0, /* kích cỡ của file: 0x0d80 = 3456 bytes */ EDONKEY_MTAG_STRING, /* = 0x02: một thẻ string-valued theo sau*/ 1,0, /* tên của nó có độ dài bằng 1 */
EDONKEY_STAG_TYPE, /* = 0x03: thẻ "type" */ 5,0,
'a','u','d','i','o' /* kiểu file */ };
unsigned char kob2[] = {
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27,
0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, /* hàm băm chỉ số */ 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, /* hàm băm quan hệ */ 4,0,0,0, /* number of metatags in following list */
EDONKEY_MTAG_DWORD, /* = 0x03: thẻ tiếp theo có kiểu DWORD (unsigned long int) */
1,0, /* tên của nó có độ dài bằng 1 */ EDONKEY_STAG_SIZE, /* = 0x02: thẻ "filesize" */
0x00,0x08, 0x00, 0x00, /*kích cỡ của file: 0x800 = 2048 bytes */ EDONKEY_MTAG_STRING, /* = 0x02: một thẻ string-valued theo sau*/ 1,0, /* tên của nó có độ dài bằng 1 */
12,0, /* tên của nó có độ dài bằng 12 */ 'f','i','l','e','n','a','m','e','.','t','x','t', /* tên file */
EDONKEY_MTAG_STRING, /* = 0x02: một thẻ string-valued theo sau*/ 1,0, /* tên của nó có độ dài bằng 1 */
EDONKEY_STAG_TYPE, /* = 0x03: thẻ "type" */ 3,0, /* gí trị của nó có độ dài 3 */ 'd','o','c', /* kiểu giá trị */
EDONKEY_MTAG_STRING, /* = 0x02: một thẻ string-valued theo sau*/ 1,0, /* tên của nó có độ dài bằng 1 */
EDONKEY_STAG_FORMAT, /* = 0x04: thẻ "format" */ 3,0, 't','x','t' /* định dạng */ }; 3.2.4. Xử lý tìm kiếm 3.2.4.1. Tìm kiếm từ khóa
Từ khóa là một chuỗi gồm các ký tự chữ thường và số được trích ra từ một giá trị thẻ của kiểu EDONKEY_MTAG_STRING như mô tả trong phiên thiết lập (nhưng đối với thiết lập, chỉ những từ khóa được trích ra từ tiêu đề là được láy hàm băm và được sử dụng như các chỉ số). Trong các ứng dụng chia sẻ, các từ khóa được lấy hàm băm và được sử dụng như các chỉ số của thẻ metadata, vì vậy một tìm kiếm sẽ phải đưa ra ít nhất một từ khóa.
Giả sử tìm kiếm chuỗi “hoang tuan anh”, kết quả trong OvernetClc đưa ra các OVERNET_SEARCH của kiểu 2 (OVERNET_FIND_VALUE) cho các giá trị hàm bằm tương ứng:
“hoang”: 61feaf994cecbd1ae76fe7ed7c587824 “tuan”: 6281416f948662670921bcc70e3524f9 “anh”: 59ac2dd34a335b61540eaaec4ef28362
Mỗi peer luôn luôn trả lời với “OVERNET_SEARCH_NEXT” chứa danh sách các peer tốt hơn (mức độ tìm kiếm sát hơn). Khi danh sách đó chứa bản thân peer chứa nó, bộ khởi tạo đưa ra cho nó một “OVERNET_SEARCH_INFO” của kiểu 0 (không có cây tìm kiếm, chỉ giống như hàm băm của chuỗi) hoặc “OVERNET_SEARCH_INFO” của kiểu 1 (với cây tìm kiếm để giới hạn tìm kiếm). Peer lưu trữ sau đó sẽ gửi lại một hoặc nhiều OVERNET_SEARCH_RESULT có chứa:
- chuỗi hàm băm - hàm băm của tên file
- một danh sách thẻ meta xác định các tính chất của file: tên, kích cỡ, nội dung, định dạng, tác giả, album,…
Cuối cùng, nó gửi một “OVERNET_SEARCH_END” với cùng hàm băm để thông báo rằng không còn OVERNET_SEARCH_RESUTL trả về nữa (thông báo này sẽ đóng phiên làm việc do yêu cầu OVERNET_SEARCH_INFO mở ra).
Hai unsigned short cuối cùng của gói tin (nằm sau hàm băm) tương ứng với số lượng gói tin “OVERNET_SEARCH_RESUTL” được gửi đi và có thể một trong số đó có giá trị nếu tham số MAX trong OVERNET_SEARCH_INFO không giới hạn chúng tới MAX-1.