Mỗi dữ liệu trao đổi được dựa trên các phiên làm việc ngắn giữa các cặp của các peer, một bộ khởi tạo sẽ khởi tạo các phiên làm việc đó. Với một gói yêu cầu, một node đáp trả sẽ trả về một hoặc nhiêu hơn các gói đáp trả. Các phiên làm việc đó có cũng có thể bị bỏ qua bởi timeout nếu các đáp trả được mong muốn không được trả về sau một vài giây. Từ quan điểm của mỗi peer, một phiên làm việc được xác nhận đơn lẻ bởi bộ ba <flavour, IP_address, port_number> của peer (Session ID); giao thức đó không giống với SSRC của RTP trong việc hỗ trợ nhận dạng các gói tin thuộc cùng phiên làm việc. Bằng việc tích hợp thêm thông tin của node khởi tạo phiên vào Session ID khiến cho giữa mỗi cặp peer có thể có tồn tại phiên làm việc độc lập cùng lúc. Ví dụ tiêu biểu là sự chồng lấp trong eMuleKAD giữa một KADEMLIA_FIREWALLED_REQ và một KADEMLIA_BOOTSTRAP_REQ được khởi tạo bởi các peer trao đổi thông tin trước khi hoàn thành phiên làm việc đầu tiên.
Hình 3.2.1.1: Phiên làm việc trong eMuleKAD
KADEMLIA_FIREWALLED_REQ (tran=1)
KADEMLIA_FIREWALLED_RES (tran=1)
KADEMLIA_BOOTSTRAP_REQ (tran=2)
KADEMLIA_FIREWALLED_ACK (tran=1)
KADEMLIA_BOOTSTRAP_RES (tran=2) open TCP connection; if OK:
Node
Trong Overnet thì hơi khác:
Hình 3.2.1.2: Phiên làm việc trong Overnet
Để lấy được logic của giao thức trên, trong P2PKad, ta sử dụng các đối tượng session để lưu vết trạng thái phiên làm việc. Một đối tượng session (SO) được tạo ra khi bắt đầu một phiên làm việcm, và được hủy khi kết thúc phiên làm việc, và chứa các trường như:
- Kademlia flavour, địa chỉ IP của peer và cổng UDP, và cờ isServerSession (tập hợp các thành phần lại tạo nên “Session ID”). - Một con trỏ trỏ tới một danh sách hàng đợi FIFO.
- Một Pthreads để quản lý các thành phần sửa đổi trong SO. - Một đối tượng pthread_t.
- Một con trỏ trỏ tới một tệp thi hành phiên dịch vụ. Các đối tượng session gồm 2 loại:
1. Client Session Objects (CSO’s). 2. Server Session Objects (SSO’s).
Cờ isServerSession được dùng để phân biệt 2 loại đối tượng session trên. CSO’s được tạo ra bởi các ứng dụng triệu gọi để bắt đầu một phiên làm việc ở phía client. Máy client triệu gọi hàm newSession(KF, peerIP, peerport), hàm này sẽ trả về một con trỏ trỏ tới một đối tượng SO mới, và cho phép một hàm đợi FIFO
OVERNET_IP_QUERY (REQ) (tran=1)
OVERNET _IP_QUERY_ANSWER (tran=1)
OVERNET _IDENTIFY (REQ) (tran=2)
OVERNET_IDENTIFY_REPLY (tran=2)
OVERNET_IP_QUERY_END (tran=1) open TCP connection; if OK, NOT always: Node
A Node B
của node triệu gọi có thể đọc các gói tin UDP đến có liên quan tới phiên làm việc đó. Các đáp trả sẽ được gửi về bằng việc gọi một tệp thực thi thực hiện gửi trả trên cùng socket UDP trên (sendbuf() và các dẫn xuất của nó). Đối tượng pthread_t và con trỏ trỏ tới tệp thực thi phiên dịch vụ đó không được sử dụng thường xuyên trong các phiên làm việc phía client.
Mặt khác, SSO’s tự động được tạo ra khi P2PKad nhận các gói UDP về. Với bộ ba <flavour, IP_address, port_number> không tương ứng với một phiên làm việc phía server đang tồn tại. Nếu flavour đó được hỗ trợ, và nếu opcode đó phù hợp với một trong các nhóm REQuest, một SO được đưa ra và một luồng được bắt đầu để chạy tệp thực thi phiên làm việc phía server (SSR-Session Server Routine); gói tin đến cũng được đưa vào hàng đợi FIFO để SSR sử dụng cho đầu vào UDP
Nếu bộ ba <flavour, IP_address, port_number> nhận về tương ứng với một SSO đang tồn tại thì UDP nhận trả được đưa vào hàng đợi của SSO. Các gói tin không nằm trong nhóm REQuest và nhận về mà phiên làm việc phía client không mở đều được bỏ qua.
Lưồng triệu gọi (cho các phiên làm việc phía client) hay SSP (cho các phiên làm việc phía server) được đưa ra để nhận biết các điều kiện kết thúc của phiên làm việc (đã hoàn thành hoặc timeout trên đầu vào) và phân chia định vị đối tượng session.