LẬP TRÌNH MẠNG VỚI SOCKET
2.5.2. Giao thức cho ứng dụng Client/Server
- Giao thức ở đây là bộ các khuôn dạng bản tin, tập trạng thái và các quy tắc, quy ước trong truyền thông giữa client và server.
- Khi tạo ra một ứng dụng client/server, việc đầu tiên là phải thiết kế giao thức. May mắn cho chúng ta là các giao thức phổ biến như FTP, HTTP, SMTP, RPC... đều đã đươc IETF (nằm trong Internet Architecture Board-IAB) chuẩn hóa thành các giao thức chuẩn. Các chuẩn này được được đưa trong khuyến nghị của IAB gọi là RFC (Request for Comment). Mỗi một chuẩn hoặc một giao thức cho Internet đều được đánh số trong RFC.
- Khi lập trình database theo mô hình client/server, giao thức trao đổi các câu truy vấn và tập các bản ghi đã được quy định và hỗ trợ bởi hệ quản trị Database DBMS và các thư viện lập trình. Do đó, ta cũng không phải quan tâm thiết kế giao thức truyền thông trong ứng dụng database. Khi lập trình sẽ có sẵn các giao diện giúp ta thực thi việc tương tác giữa Client và Database server. Trong môi trường 3 lớp, thì lớp Middleware ở giữa cũng sẽ cung cấp giao diện để thực thi việc gọi hàm từ xa (Remote Procedure Call-RPC). Đây là một kĩ thuật cho phép các ứng dụng client server tương tác với nhau bằng phương pháp gọi hàm thông thường. Nó cung cấp giao diện gọi hàm mà che đi công tác truyền thông client server và việc truyền thông là trong suốt đối với người lập trình. Kĩ thuật này sẽ được trình bày trong phần sau.
- Nói chung là ta nên theo các giao thức chuẩn có sẵn cho mỗi ứng dụng phổ biến. Tuy nhiên, khi xây dựng một ứng dụng riêng chưa có giao thức chuẩn thì ta phải thiết kế giao thức.
Phân loại giao thức:Có thể chia giao thức thành 2 dạng cơ bản : - Giao thức đồng bộ (Synchronous Protocol)
o Trong dạng giao thức này, quá trình truyền thông giữa client và server diễn ra theo hai chiều nhưng không đồng thời mà được thực hiện lần lượt. Mỗi bên sau khi truyền dữ liệu hoặc thông báo cho bên kia sẽ ngừng lại để chờ bên kia gửi sang
o Ví dụ về các giao thức kiểu này là : HTTP, POP, SMTP... - Giao thức không đồng bộ (Asynchronous Protocol)
o Đối với giao thức dạng không đồng bộ, client và server có thể đồng thời gửi thông tin cho nhau mà không cần phải chờ đợi phản hồi của bên kia
o Các giao thức này thường là các giao thức stateless như TELNET, RLOGIN...
- Ngoài ra có thể có dạng giao thức hybrid là sự kết hợp của hai dạng giao thức đồng bộ và không đồng bộ
Các yêu cầu đối với giao thức
Việc thiết kế được một giao thức tốt là rất khó khăn và phải đáp ứng các yêu cầu cơ bản sau:
- Rõ ràng (well-defined)
o Trong mỗi dạng bản tin được truyền đi, mọi trường dữ liệu phải được định nghĩa trong giao thức - rõ ràng về kích thước, ý nghĩa, các trường hợp liên quan đến từng bit.
o Giao thức chính là ngôn ngữ, do đó đòi hỏi phải chính xác, không có sự nhập nhằng
o Sử dụng các phương pháp diễn tả mang tính hình thức (common formal decscription) như dạng BNF (trong automata)
o Nếu sử dụng các ngôn ngữ mô tả thì dạng ngôn ngữ đó cũng phải được trình bày trong tài liệu giao thức (để người đọc có thể hiểu được)
o Nên sử dụng các ví dụ minh họa cho giao thức
- Đầy đủ (bao hết mọi khả năng có thể), là các vấn đề sau:
o Dữ liệu hỏng, không hợp lệ (khuôn dạng, kích thước, tránh tràn bộ đệm) Các phiên bản cũ (tương thích). Ví dụ, một client phiên bản proto là 1.0 kết nối với server phiên bản 1.2
o Các yêu cầu không hợp lệ. Lệnh sai hoặc tham số sai hoặc trình tự yêu cầu không đúng quy tắc, hoặc lệnh không được phép...
o Các điều kiện giới hạn. Kiểm tra một số điều kiện nào đó trước khi tiến hành bước tiếp theo. Ví dụ, kiểm tra tính xác thực, kiểm tra điều kiện cho phép...
o Có thể phân tích cú pháp trong các bản tin.
- Một số vấn đề khác khi thiết kế và triển khai giao thức o Khả năng mở rộng và tương thích giữa các version o Thứ tự byte
o Tính hiệu quả : Đồng bộ và không đồng bộ Thông tin điều khiển, header Thời gian trễ round trip
o Trạng thái :Ai đọc, ai ghi (ai truyền, ai nhận)
o Timeout : Đây là vấn đề không thể thiếu đối với ứng dụng mạng do tính biến động và không biết trước của trạng thái mạng.
CHƯƠNG III