boost :: asio :: ip :: tcp :: socket được kết nối?

Question

Tôi muốn xác minh trạng thái kết nối trước khi nhận ra các hoạt động của mình (đọc/ghi).

Có cách nào để tạo phương thức isConnect() không?

Tôi thấy this, nhưng có vẻ như "xấu xí".

Tôi đã thử nghiệm chức năng is_open(), nhưng không có hành vi mong muốn.

Answer 1

TCP có nghĩa là để được mạnh mẽ khi đối mặt với một mạng lưới khắc nghiệt; mặc dù TCP cung cấp những gì trông giống như một kết nối end-to-end liên tục, tất cả chỉ là một lời nói dối, mỗi gói thực sự chỉ là một datagram duy nhất, không đáng tin cậy.

Các kết nối thực sự chỉ là ống dẫn ảo được tạo với trạng thái nhỏ được theo dõi ở mỗi đầu của kết nối (cổng nguồn và đích và địa chỉ và ổ cắm cục bộ). Ngăn xếp mạng sử dụng trạng thái này để biết quy trình nào cung cấp cho mỗi gói đến và trạng thái nào được đặt trong tiêu đề của mỗi gói gửi đi.

Do tiềm ẩn — vốn phi kết nối và không đáng tin cậy — bản chất của mạng, ngăn xếp sẽ chỉ báo cáo một kết nối bị cắt đứt khi kết thúc từ xa gửi một gói tin FIN để đóng kết nối, hoặc nếu nó doesn' t nhận được một phản ứng ACK cho một gói tin gửi đi (sau một thời gian chờ và một vài lần thử lại).

Do tính chất không đồng bộ của asio, cách dễ nhất để được thông báo về ngắt kết nối duyên dáng là có số async_read nổi bật sẽ trả lại error::eof ngay lập tức khi kết nối bị đóng. Nhưng điều này một mình vẫn còn khả năng của các vấn đề khác như kết nối một nửa mở và các vấn đề mạng sẽ không bị phát hiện.

Cách hiệu quả nhất để làm việc xung quanh gián đoạn kết nối không mong muốn là sử dụng một số loại giữ nguyên hoặc ping. Điều này thường xuyên cố gắng để chuyển dữ liệu qua kết nối sẽ cho phép phát hiện đúng đắn của một kết nối vô tình bị cắt đứt.

Giao thức TCP thực sự có tích hợp keep-alive mechanism có thể được định cấu hình bằng asio sử dụng asio::tcp::socket::keep_alive. Điều tuyệt vời về TCP keep-alive là nó trong suốt đối với ứng dụng chế độ người dùng, và chỉ những đồng nghiệp quan tâm đến việc giữ cho nó luôn cần cấu hình nó. Nhược điểm là bạn cần truy cập/kiến ​​thức ở mức hệ điều hành để cấu hình các tham số thời gian chờ, chúng không được tiếp xúc thông qua tùy chọn socket đơn giản và thường có giá trị timeout mặc định khá lớn (7200 giây trên Linux).

Có lẽ phương pháp phổ biến nhất để giữ sống là triển khai nó ở lớp ứng dụng, trong đó ứng dụng có thông báo ping hoặc ping đặc biệt và không làm gì ngoài phản hồi khi bị cù. Phương pháp này mang đến cho bạn sự linh hoạt nhất trong việc thực hiện chiến lược tiếp tục sống.

Answer 2

bạn có thể gửi byte giả trên ổ cắm và xem nó có trả về lỗi hay không.

Answer 3

TCP hứa hẹn sẽ xem các gói bị xóa - thử lại khi thích hợp - để cung cấp cho bạn kết nối đáng tin cậy, đối với một số định nghĩa đáng tin cậy. Tất nhiên TCP không thể xử lý các trường hợp xảy ra sự cố máy chủ hoặc cáp Ethernet của bạn bị trục trặc hoặc xảy ra sự cố tương tự. Ngoài ra, biết rằng kết nối TCP của bạn không nhất thiết có nghĩa là một giao thức sẽ đi qua kết nối TCP đã sẵn sàng (ví dụ, máy chủ web HTTP của bạn hoặc máy chủ FTP của bạn có thể ở trạng thái bị hỏng).

Nếu bạn biết giao thức được gửi qua TCP sau đó có lẽ là một cách trong giao thức đó để cho bạn biết nếu điều này là trong tình trạng tốt (cho HTTP nó sẽ là một HEAD request)